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).