Our great sponsors
-
nanopass-framework-scheme
The new nanopass framework; an embedded DSL for writing compilers in Scheme
-
-
SurveyJS
Open-Source JSON Form Builder to Create Dynamic Forms Right in Your App. With SurveyJS form UI libraries, you can build and style forms in a fully-integrated drag & drop form builder, render them in your JS app, and store form submission data in any backend, inc. PHP, ASP.NET Core, and Node.js.
-
-
-
salsa
A generic framework for on-demand, incrementalized computation. Inspired by adapton, glimmer, and rustc's query system.
-
WorkOS
The modern identity platform for B2B SaaS. The APIs are flexible and easy-to-use, supporting authentication, user identity, and complex enterprise features like SSO and SCIM provisioning.
Some serious level Conway's Law. I mean multipass isn't bad. It composes well, it minimizes coupling, etc etc. It doesn't necessarily have to hit disk, any store could be used. I myself like multipass taken to an extreme in nanopass, but at the same time, I absolutely adore the single pass nature of Wirthian languages.
Why text as the input? Humans like text. Scratch/Blockly might be said not to have a parser. Simple LISPs' parsers can be trivial to the point of feeling more like deserialization than parsing.
Bonus: Portability is desirable: It's nice to be able to swap out just the codegen stage and be able to re-use everything else to generate executables for many platforms. After investing in many codegen implementations for wide portability and nice optimizer(s), it becomes enticing to have multiple lexparse implementations as well, compiling multiple languages to the same IR and re-using the nice optimizer(s) and the many codegens for the many platforms: GCC also compiles Fortran, Ada, and Go; many languages run atop JVM; MS CLR followed and doubled-down on this, and LLVM is eating the world. All this fits very well into the [ LexParse > Optimize > Codegen ] paradigm, and also follows entirely from the type signatures of those components.
Why text as the input? Humans like text. Scratch/Blockly might be said not to have a parser. Simple LISPs' parsers can be trivial to the point of feeling more like deserialization than parsing.
This, and as pointed Salsa.