| ▲ | DHaldane 3 days ago |
| It's ok to build a compiler sometimes -- it's just very important to make that choice intentionally |
|
| ▲ | mattgreenrocks 3 days ago | parent | next [-] |
| Indeed, the safer thing is to actually build a few toy compilers on the side so you can get a sense for what they are good for, and what level of effort is required to build and maintain it. Keeping them locked up in the "scary CS" closet only ends up stunting your growth. |
| |
| ▲ | SAI_Peregrinus 3 days ago | parent [-] | | I like to write toy compilers or interpreters as an exercise when learning a new language. Usually for a Forth or Lisp or one of Turing Tarpit languages. It requires some of the most common bits of programming: I/O, lexing, parsing (both of source and of arguments to the compiler), file handling, and some common algorithms & data structures (can't have an AST without a tree). |
|
|
| ▲ | lmm 3 days ago | parent | prev [-] |
| I'd say the opposite. Building a compiler incrementally, driven by clear needs at each step, as described in the article, tends to work out better than trying to build a compiler from day 1. |
| |
| ▲ | titzer 2 days ago | parent | next [-] | | I've written 7 compilers. If you don't know you're writing a compiler from the beginning and you've never written before, it is basically guaranteed to be a hot mess in the end, unless you accidentally make exactly the right call at every one of a dozen critical steps. It's extremely unlikely to just stumble on all the good architectural ideas from a field that is 70+ years old without any planning. Granted, if you've got a really simple language then maybe there's an upper bound on how bad it can be. But in practice people tend to also want to grow the language as they go. Don't get me wrong; there's a lot than can wrong if you over-engineer the compiler from the beginning, including ending up with a hot mess anyway. BTW if you can't write down, even in three sentences, the requirements for said compiler from the beginning, congratulations, you have no idea what you are doing. | |
| ▲ | wbl 3 days ago | parent | prev | next [-] | | Oh no. What the article describes ends up with a real mess. If you set out to support a certain language you'll have a global view of how things should fit together, and what the implementation should do. | |
| ▲ | pizza 3 days ago | parent | prev [-] | | Is there a meta-library someone somewhere has already written for when I just want to write 20% of a compiler, and it more or less takes care for me 80% of the common compiler-building-related things I’m likely to need to do? | | |
| ▲ | coryrc 3 days ago | parent | next [-] | | You should read the book Lisp In Small Pieces. It's basically a book about doing that multiple times with every-increasing percentages. | |
| ▲ | peterkelly 3 days ago | parent | prev | next [-] | | https://llvm.org/ https://docs.racket-lang.org/guide/languages.html | | |
| ▲ | PittleyDunkin 3 days ago | parent [-] | | LLVM doesn't prevent you from shooting yourself in the foot via a dozen different language details completely divorced from backend implementation. It's only a small, but very important and difficult, aspect of compiler writing. I think languages like go have demonstrated well that this is of limited benefit to the success of the language. Racket at least provides most of the tooling required (eg dealing with details of namespacing, syntax, runtime/compile-time/evaluate-time distinction, continuations and garbage collection), but if you've ever tried to introduce it into an organization of significant size this very same result of yak-shaving will be considered a liability. | | |
| ▲ | burnt-resistor 2 days ago | parent [-] | | You're criticism is an apples vs. oranges strawman. LLVM IR and libraries provide powerful plumbing. It's not meant to be a turn-key or cookie-cutter solution, or inherently memory-safe VM or compiler generator. It's also not formally verified and written in C++, which adds project configuration complexity and C++ pitfalls. It's possible to plug in a custom GC using their strategy model their way, or manage GC yourself like Pony does because it's built around ORCA. |
|
| |
| ▲ | psittacus 3 days ago | parent | prev | next [-] | | Depending on the domain, a language workbench might be a good fit. https://spoofax.dev/ https://www.rascal-mpl.org/ | |
| ▲ | lmm 3 days ago | parent | prev [-] | | You could try Truffle (for Graal), then you can leave a lot to the framework. | | |
| ▲ | crustycoder 3 days ago | parent [-] | | Was just going to say the same. The integration of JavaScript into the Oracle RDBMS is done using a mix of C, Java/Truffle and JavaScript - https://docs.oracle.com/en/database/oracle/oracle-database/2... And you can step up a level above in the same ecosystem as well, my current project is written in Scala and directly shares its data structures with the Graal Python interprer that I've embedded inside it, so other people can write the stuff they want in Python. |
|
|
|
