Happy New Year!
The current plans for AL and compiler work have not been made explicit on the forums as of yet. We have wonderful posts like Compiler/Interpreter Work Writeup - #4 by murisi which cover the current state of the RISC0 compiler pipeline, but something more general does not exist, so this needs to be done. Therefore, the purpose of this post is to do just that: to cover the plans for not just the compiler pipeline, but how it fits into the broader plans for AL in the short-mid term and how this fits in to the long term, plus prioritisation.
The most well-developed vision I have for AL depends on the conclusions that I determined in Controllers and Solvers in the Abstract. Unfortunately, we do not currently possess a fully-fleshed out abstract machine for AL, so this post can only exist as a kind of a half-baked ‘wishlist’, but the fundamental pieces of long-term work I have identified are
- An event-sourcing kernel for bootstrapping AL (inspired by Git, Arvo, XTDB)
- A monotonic, relational object model based on said kernel (inspired by PROLOG, Logtalk, Pharo)
- A scalable local domain with hot-and-cold storage mechanisms, transaction planning system, scry, solver hookups, live system management in git-style (something only made possible by event-sourcing, for the record), and other functionalities (inspired by Urbit, Git)
- A CALM-compliant event-brokering DSL on top for interactions that don’t require solvers (inspired by BLOOM)
- An implementation of the resource machine on top of AL (a state transition protocol for resources) with the full cryptographic density required
- An implementation of the controller architecture
I’m sure there are more I’ve forgotten here, but in any case doing all of this is unrealistic for the short-term. More realistic is to interpret the abstract machine for AL on top of Elixir and compile down to RISC0 C. As Murisi points out, during the Hacker House, we made a decision to step away from the compilation of Elixir to Scheme, due to redundancy, and having a better idea of what our chief concerns will be. Instead, we’re looking a little deeper down at the Elixir compiler stack. The current expectation for user interaction still looks the same: The user should be provided, in Elixir, with a protocol for turning objects into resources which they can override as their application demands, such that the user ought to be able to specify transparent resource transactions that compile down to RISC0 reliably and correctly.
Before, our pipeline looked like
Elixir → Scheme → Risc0 C
This work can be seen on this branch here GitHub - anoma/anoma-local-domain at jam+murisi/feature/elixir-resource-machine
There are examples in the repo, both for transformation of Elixir to Scheme, and of Scheme to C. These examples should produce C source code which can be fed into GitHub - anoma/risc0-scheme: Scheme-like DSL inside RISC Zero (there is again an example in the repo). Note the use of bindings between Rust and C to supplement for special data types.
Now however, things look more like
Elixir → Beam Bytecode → Risc0 C
So far, the results seem to be quite good, but there are uncertainties under review by Murisi.
On my side, I’ve been spending the winter focusing more on event-sourcing and the specific object model and figuring out exactly how things ought to fit together within the current world of BEAM that we have. For that reason, I’ve been interrogating both Urbit and Pharo for more information on how their operating systems work, as well as Minikanren, since this was something that perhaps offered something promising. I’m not sure how much I want to post publicly yet about the exact programs I’ve been working on, since I already have plans for a post on this, but I have some working examples of event-sourcing for the relational object model.
Finally, we’ve enlisted the help of Jamie to help us more with the general design of AL, and discussions here are early and ongoing.
In summary, many aspects of AL are still in flux and I would love to receive more pushback on the general ideas I’ve laid out here (and the specific post I referenced earlier) since a lot of our design decisions are dependent on this, but the plan for making AL ‘real’ is becoming more-and-more concrete. Therefore, I think now is a critical time to get others within Anoma to interrogate the core plan & principles.