Re:Compilers: Incrementally and Extensibly
by remexre on Saturday April 05, 2025 @02:59PM
(#43595906)
Making the _compiler itself_ provide an API enables things like LSP, which don't want to generate machine code at all. A traditional single-pass compiler usually can't accommodate this without re-plumbing.
[ Parent
| on HN ]
Re:Compilers: Incrementally and Extensibly
by halffullbrain on Saturday April 05, 2025 @04:13PM
(#43596467)
The Eclipse Compiler for Java [1] is a notable exception, architected around incremental compilation, an API for “live” AST manipulation, and a layered non-batch approach to when to invoke various analysis steps.
The LSP for Java [2] used in eg. VSCode’s Java plugins, builds on this API.
But, no, I haven’t seen a generalized approach to this architecture discussed in literature.
1: https://github.com/eclipse-jdt/eclipse.jdt.core 2: https://github.com/eclipse-jdtls/eclipse.jdt.ls
Re:Compilers: Incrementally and Extensibly
by tester756 on Sunday April 06, 2025 @05:31PM
(#43605124)
I'm aware, I've used C#/.NET Compiler ecosystem and their Compiler as a Service approach
But it seems like you're just creating libs that everyone and embedd / use and that's it
e.g `auto ast = Compiler.GenerateAST(code);`