Aml/System Plans

A side note: I indefinitely postponed any development of the Aml# and Aml#/System "dialects". It does not make much sense to create these at the moment, and once Aml Core is a viable SDK, then maybe, maybe.

The current plan for Aml/System is as follows:

1. Write a Rust program that would be the stage 0 Aml/System compiler. It does not have to do much, it does not need to compile all of Aml/System features and libraries, just the most basic things needed for a stage 1 compiler to compile. For that, decide what is this minimal subset of Aml/System. Probably the only way to do that is to simultaneously write a stage 1 compiler. (This is where we’re at now.)
2. Write a stage 1 compiler, using a subset of Aml/System. This compiler will have to be able to compile every Aml/System feature, including any possible libraries, and including itself. 
3. Write a stage 2 compiler, using the full feature set of Aml/System. This compiler will then be completely self-hosted, being able to compile itself (while the first build will be compiled by a stage 1 compiler). It’s questionable whether this step is necessary, or if there will have to be more stages to incrementally get to a stage N compiler, where N is the final compiler stage written in the same language that it compiles. 

It is possible that in between writing a stage 1 compiler and a stage 2 compiler, there will be a switch in technology, regarding what the intermediary output would be. Compilers up to stage 1 will very likely just transpile to C or C++ (not sure yet), depending on the ways of the clang and msvc, while stage 2 may drop the C/C++ intermediary form and go right for Aml/System IR to LLVM IR transformation, which is something that can happen while already happily building runtime for Aml/Core using a stage 1 compiler, because the runtime does not care if its compiler is a self-hosted one or nah. 

The dependency on cc, gcc or link.exe is something Aml/System is not likely to get rid of while targeting any of the currently serving Operating Systems (until plan-89 comes to life). 

Note that switching from a clang/msvc backed program building and moving to LLVM IR code generation presents more challenges than it may seem: 

• Learn LLVM IR, while LLVM itself is in active development and may change in BC-breaking manner anytime. The solution is obviously to fork it and only merge changes when ready. 
• Learn how to interoperate with the libc etc. from within LLVM IR. 
• Learn code optimizations, since clang/msvc will no longer do that for us. 
• Learn archive packaging (heard some rumours that the Windows archive tool has some troubles with non-object members of archive files). Might need to use llvm-ar for that instead. 
• Also, true not just for this switch, but – support debugging interfaces. Aml/Core will have a very much different runtime from Aml/System, and we can design debugging interface for Aml/Core ourselves, since probably nobody would ever use an existing one for the job – also, remember that the runtime is also very much different from the regular stack-based runtimes of other high-level languages. Unlike the runtime of Aml/System, unfortunately. Maybe plan-89 will allow fancier code to be written in Aml/System, we’ll see. 

P.S.: Aml/System, as well as Aml/Core and all of its docs are written as open source under the MIT license, so you can use it however you wish to, but – it would be really appreciated if you could just join the efforts and help out with the job. 

Future plans

While Aml is still undergoing much development, this blog did not get the same amount of attention. So to make amends, here are some news. Aml basically split into a few sub-projects, specifically a family of languages:

• Aml Core, which is the former Aml as it was designed.
• Aml#, a dialect of Aml that may or may not come to live, but it’s intended to be an even more ML-like language. 
• Aml S, another Aml dialect, more likely to come alive – intended to be to Aml what Clojure is to Java, simply put. Also as a powerful DSL for configs on steroids. 
• Aml System, almost the same language as Aml Core, limited, different runtime – intended to be something like what C is to C++. 
• Aml# System, the same, but with the more ML-like appearance. 

Work has started on Aml Core runtime, using the C++ and Rust languages (separate projects, to see which one would work the best for the cause). This now seems like a major bad decision. The new intention is to write Aml Core runtime, using Aml System language, so it can feel more self-hosted, although with two separate runtimes. 

To build Aml System though, one has to make a long journey. That is, we can’t really write Aml System in Aml System yet, since we don’t have any Aml System compiler at hand. The process will likely look something like this:

1. Write an initial Aml System compiler in Rust or D (probably Rust though). The key requirement is that the host language has to have nice support for unit testing, so that we can safely rely on Aml System compiler’s results. And imho, Rust fulfills that better. Another option could be OCaml (heard that Rust used that for its own initial compiler). 
2. Since we have now an Aml System compiler, we can rewrite Aml System compiler using the previously built version of itself. 
3. Now Aml System compiler became self-hosting. 
4. Write Aml Core runtime in Aml System. Native functions in Aml Core can be also written using Aml System, and since the general syntax of the two languages is the same, the native source code may be embedded in Aml Core source files directly. 
5. There is no need to write Aml Core runtime in Aml Core, because the language is interpreted. 
6. Now that the MVP of Aml is finished, we can focus efforts on Aml S, whose runtime can in fact be written using both Aml System and Aml Core, maybe intelligent combination of both. 

There are also some phases and challenges in implementation of Aml System that might be worth mentioning. The main question is: what would be the output of the initial Aml System compiler. 

• C source code, or some other low-level language source code. 
• Could leverage existing clang and LLVM optimizations. 
• LLVM IR. 
• More freedom in implementation, more work. 

Another thing is how the resulting binaries compiled by Aml System compiler would work in the host system. It could link to some libc, libm, like Rust does, or it could use its own version of that and interface the OS directly. So many questions. The most likely path is that the initial version would simply compile to C code, and link to a libc. Then, since the output will still be a bunch of native code object files (maybe in archives, dynamic libraries etc.), the compiler can later switch on to LLVM IR and skip the C part, use only the system’s SDK linker, that would be nice (and is kind of what Rust does, so I believe that would be the final phase with Aml/System to get to).