4 ms·

Many suggest resources for compiler implementations, i personally would start prototyping the language itself, think about it's type system and its runtime prop

Many suggest resources for compiler implementations, i personally would start prototyping the language itself, think about it's type system and its runtime properties. There are many possibilities in terms of type systems, from static to dynamic and everything in between, concepts like linear types, algebraic types, etc. Runtime properties are things like it's memory model (garbage collection, yes or no). All of this depends on the purpose of your language. The second part would be choosing a platform to run on (so you only have to write a compiler frontend). There are many great technologies to host a language, but i'd advocate two specific ones here: * https://github.com/zetavm/zetavm https://github.com/zetavm/zetavm (shoutout to @love2code) * https://llvm.org/ https://llvm.org/ ZetaVM is a great target for dynamicly typed and/or jit compiled languages like python or javascript. LLVM is used in many low level / near metal languages like C, C++, rust and so on. None of both must be your final targets, your compiler frontend can be moved to target another platform like the JVM later. As a last part, implement your compiler frontend. This involves lexing/parsing source code, type checking if needed and generating your target's intermediate representation. I personally prefer hand-written recursive descent parsers using a parser combinator framework (like https://github.com/Geal/nom https://github.com/Geal/nom) over parser generators. For further processing like type checking, there is the common monolith aproach and the nanopass framework/approach https://www.youtube.com/watch?v=Os7FE3J-U5Q https://www.youtube.com/watch?v=Os7FE3J-U5Q Also there's a great series on compiler frontends by Alex Aiken: https://www.youtube.com/watch?v=sm0QQO-WZlM&list=PLFB9EC7B8FE963EB8 https://www.youtube.com/watch?v=sm0QQO-WZlM&list=PLFB9EC7B8F... Hope this gives an overview. :)

unboxed_type 9y ago
>I personally prefer hand-written recursive descent parsers >using a parser combinator framework (like https://github.com https://github.com >/Geal/nom) over parser generators. Why?
- vidarh 9y ago
  Why handwritten, or why using a parser combinator framework? Handwritten parsers are most commonly used because most tools have problems making things like proper error reporting good enough to be worthwhile. Parser combinators is really just a fancy way of composing a parser from higher order functions instead of writing out a function body. If well done it basically provides a DSL to build the parsers, and the way this works by composing small fragments is pretty much what we do with recursive descent anyway, so it's a good fit.
deleted 9y ago
[deleted]

unboxed_type 9y ago

>I personally prefer hand-written recursive descent parsers >using a parser combinator framework (like https://github.com https://github.com >/Geal/nom) over parser generators. Why?

vidarh 9y ago
Why handwritten, or why using a parser combinator framework? Handwritten parsers are most commonly used because most tools have problems making things like proper error reporting good enough to be worthwhile. Parser combinators is really just a fancy way of composing a parser from higher order functions instead of writing out a function body. If well done it basically provides a DSL to build the parsers, and the way this works by composing small fragments is pretty much what we do with recursive descent anyway, so it's a good fit.

deleted 9y ago

[deleted]