This post is about one of my favorite aspects of the Acadia compiler, symbolic evaluation.
The compiler evaluates queries as much as possible at compile-time, so it is able to reduce case expressions, let expressions, etc. One neat outcome of this is that large expressions can sometimes be fully evaluated at compile-time, so they end up having no runtime cost at all!
I like this feature because it also only works because the query language is not Turing Complete. The design choices described here that avoids 1+N patterns, also guarantees that queries terminate. This means they terminate whether you run them at runtime or at compile-time!
Anyway, the post also has an example app that uses elm-simple-server to run Elm code on the server, so maybe that is interesting as well.
This is awesome! I’ve been tempted to write a post called “Only 698 Programming Languages to Go,” but I restrained myself. The idea being that Elm and Acadia feel like two of Peter Landin’s “next 700 programming languages”.
I just love how you’ve taken the lambda calculus as the core and then methodically selected the best, most relevant ideas from programming language theory to craft elegant solutions to practical problems. I’m in awe. Great work!
In the context of Elm, I would expect more traditional approaches (like inlining) to produce better results. After inlining you would look for some typical simplifications, so you could end up skipping code that way.
The trouble is that JS VMs are already doing this, so if Elm did it too, we’d likely end up having larger assets but not necessarily faster code. So I think this kind of stuff is only plausible if the compilation target is something different.
