Federico asked me to post about this so I am. I am working on a kotlin multiplatform library for llvm. Right now, this only works (as an internal DSL) with globals, but I have successfully been able to expand on that by allowing the creation of functions and local code blocks (including local variables). But there is much to improve. Unfortunately JNI isn’t so good with native exceptions so I have fish them out myself and design the library’s architecture around not throwing native exceptions. Cause then we would be presented with blatantly unreadable native stack traces, memory addresses, etc all because of something simple. I’m suffering so you don’t have to lol!
I just integrated Kolasu with the test language which is going to be a toy language (perhaps there will be multiple toy langs to test different paradigms and styles) that is using ANTLR to generate the lexer and grammar, which I am then feeding into Kolasu, which will then feed into llvm. I was able to successfully generate a simple Kolasu parse tree of this.
I’ll be expanding on the toy language as I develop the library. For now it’s on JVM until I get a feel for the architecture, then I’ll move on to design the overall architecture. I’m not sure I’ll do UML models or flowcharts but I’ll definitely have a wiki for it at some point.
This is a vital part of Beagle’s development lifecycle, as I am actually considering forking Kolasu for multiplatforming, since Beagle is on Kotlin/Native, I would love to have Kolasu on K/N before I get kotlinx-llvm to be multiplatform. I would also love to see antlr-kotlin to be multiplatform too!!
There are several other miscellaneous modules I have to make the Beagle compiler, including creating an external debugging mechanism, which I will write about. It takes the idea of stepping through a debugger out of a program’s runtime by generating debug data on the disk in a simple byte format, and allowing external programs to deserialize them. I hope to make a neat visual program that presents you with graphical analysis of your debug data. It’ll be a vital part of Beagle that I will be trying out. It in theory should be much better than stepping through a debugger at runtime. After I get all of these modules done, it should be smooth sailing from here!
I also need to create the pipeline architecture and the exact parsing passes the parser will go through. I have a general idea of how I want it to go down, I will be sure to post here about it once I’ve made up my mind.
I hope to have a working demo of Beagle by the end of the year!