-
-
system_r
system_r is a simply-typed lambda calculus with parametric polymorphism, written in Rust with minimal dependencies; Originally forked from lazear/types-and-programming-languages, it hosts further enhancements to make it suitable for wider use
-
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.
I've stared at that paper before and I still don't understand it even though I think I've done pretty much exactly what it talks about doing: https://github.com/bablr-lang/language-cstml/blob/trunk/lib/...
I work on an open source system-f level lambda calculus named System R (https://github.com/olsonjeffery/system_r).
I’m interested in this because I’m writing this LC dialect as a deliberate, extensible IR with a targeted “bottom-dialect” (a System F, if you will) that can be translated to any number of lower representations.
My goal is use it as an extensible dialect that can be built up to any arbitrarily complex dialect of LC (Calculus of Constructions, Algebraic Effects, etc). Those “higher dialects” themselves can be targets for some “front end” language that’s palatable to end-programmers.
There’s a lot of thoughtful insights here in this paper, namely the idea of “combining steps” to optimize/remove IRs. This also corresponds to the same practices in eg Koka (which goes straight to C or wasm/js; heck maybe they cite this paper?)
I personally reflect on this because I think an extensible IR is just a stop-gap to an optimized process, allowing you to “grow” the language semantics you want, but ultimately you’ll have to rewrite bc of perf. This happened with rustc, as well.
Thanks for sharing!