2 ms·

Microsoft's Roslyn [1] design (now called .NET Compiler Platform) is what I think any language should strive for, turning the classical black box of the compile

Microsoft's Roslyn [1] design (now called .NET Compiler Platform) is what I think any language should strive for, turning the classical black box of the compiler into an incremental pipeline where each stage is annotated/augmented/refined by different mechanisms such as type checkers. If each step is incremental, it follows that it's easier to also let each step "integrate" deltas; for example, adding a comment shouldn't need to recompile anything at all, merely modify the AST, because it doesn't lead to any actual code artifacts. The second benefit is that all the information needed to inspect the program — from syntax highlighting to type information — is already there. If you can keep the entire high-level compilation state in memory, then it's easy to query it for all sorts of IDE features. This same design was used for the TypeScript compiler. Anders Heljsberg has a great little lecture [2] about it. [1] https://github.com/dotnet/roslyn/wiki/Roslyn-Overview https://github.com/dotnet/roslyn/wiki/Roslyn-Overview [2] https://www.youtube.com/watch?v=wSdV1M7n4gQ https://www.youtube.com/watch?v=wSdV1M7n4gQ

gmueckl 7y ago
I"m not too familiar with either Roslyn or the Eclipse Java Compiler (ecj), but since ecj was developed specifically for deep integration into Eclipse JDK, I'd assume that it ended up being really similar (and it would have preceded Roslyn by a couple of years).
- atombender 7y ago
  I don't know the internal architecture of the Eclipse compiler, but one of the points of the Roslyn architecture is to turn the compiler into an API, allowing things like inserting plugins — custom linter rules, for example — at each point in the pipeline. Eclipse is interesting in that it grew out of IBM's VisualAge for Java, which was written in Smalltalk as an extension of the original VisualAge IDE/compiler, which goes back all the way to the mid-1980s. I wonder if any of the inspiration for this design came out of Smalltalk's runtime state being persistent. If all your state is derived from earlier state, then there's no need to always start processing from scratch, since you can just continue from where you were before.
rictic 7y ago
That Anders Heljsberg video is great. Watched it last night and I'm still thinking through the implications of pull vs push. Thanks!

gmueckl 7y ago

I"m not too familiar with either Roslyn or the Eclipse Java Compiler (ecj), but since ecj was developed specifically for deep integration into Eclipse JDK, I'd assume that it ended up being really similar (and it would have preceded Roslyn by a couple of years).

atombender 7y ago
I don't know the internal architecture of the Eclipse compiler, but one of the points of the Roslyn architecture is to turn the compiler into an API, allowing things like inserting plugins — custom linter rules, for example — at each point in the pipeline. Eclipse is interesting in that it grew out of IBM's VisualAge for Java, which was written in Smalltalk as an extension of the original VisualAge IDE/compiler, which goes back all the way to the mid-1980s. I wonder if any of the inspiration for this design came out of Smalltalk's runtime state being persistent. If all your state is derived from earlier state, then there's no need to always start processing from scratch, since you can just continue from where you were before.

rictic 7y ago

That Anders Heljsberg video is great. Watched it last night and I'm still thinking through the implications of pull vs push. Thanks!