Our great sponsors
-
-
-
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.
-
manifold
Manifold is a Java compiler plugin, its features include Metaprogramming, Properties, Extension Methods, Operator Overloading, Templates, a Preprocessor, and more.
-
-
oil
Oils is our upgrade path from bash to a better language and runtime. It's also for Python and JavaScript users who avoid shell!
-
mir
A lightweight JIT compiler based on MIR (Medium Internal Representation) and C11 JIT compiler and interpreter based on MIR
Check out project manifold[1]. It integrates languages at the type system level using a technique the project labels “type manifold”, which is described as JIT *static* code generation.
This project targets the JVM, but the general model, it appears, could be adopted with any static type system / compiler.
1. https://github.com/manifold-systems/manifold#what-can-you-do...
Not directly related, but this made me think of something I've been interested in recently - structured editors. Instead of tokenizing text and then parsing to an AST, you effectively edit the AST directly.
Since the thrust of the post seems to be about the sum of compilation + run time, it's a potentially more efficient alternative to traditional code editing. Here's an example of one in action:
https://tylr.fun/
Yes, that was my initial reaction to this post. I like the framing a lot, and the references to copy-and-patch, Umbra, and so forth are great.
But my suspicion is that rather than trying to make the hard tradeoff, it may be less effort to implement the slow simple interpreter (I actually like TREE interpreters), and also the compiler which can take a long time.
I'm doing a similar experiment right now, as sort of an offshoot of https://www.oilshell.org/
I don't know how easy it is to develop the interpreter and compiler in lock step, but I think it's worth exploring. I think you can probably reduce the effort with simple code organization, and by making the interpreter slower to run, and the compiler slower to compile.
It's indeed very easy to design a language with an interpreter, and then find out it can't be compiled to fast code. So IMO it's worth some design up front to avoid that fate.
---
I also think OCaml (mentioned in the post) proves the strategy: they had a bytecode compiler first, then a native compiler. (Though TBH I don't know how it plays out in practice for users)
And WASM also proves it -- there are multiple implementations of the same spec with different tradeoffs.
I think it's almost more of a UX / DX issue of how to put these things together. I noticed node.js starts too slowly for my taste, but deno starts faster?
$ time nodejs -e 'console.log("hi");'