Because of the way I work this is likely to be a very rambling series of posts, some of my initial thoughts on topics are the polymorphic aspects (including compile and runtime polymorphism), AST macro based design and the work I’ve done on getting a very bare-bones REPL using LLVM and a custom lexer and parser.
First though I should describe the top level design thoughts behind the language, these are very much open to change as you’ll see from where they were in the original design through to now.
Ancient historyI first started thinking about YASL around the beginning of the year, according to GitHub Jan 16 was when I committed the first version of my design doc, then Jan 17 I committed some example code to work towards. At this point the main goal of the language was for bare-metal embedded development, a nicer language to use for my home automation projects. This meant that initially one of the aims was to make the language entirely stack-based, when you’re working with a massive 128 bytes of SRAM then you really can’t afford to spend any on heap management. One of the main decisions from this time to survive till now is using LLVM as the backend code generation.
NowSince then the goal of the language has definitely changed. There were quite a few reasons behind this; I realised I’m almost certainly not skilled enough in language development to come up with a language that’s nice to write while still being highly optimised for a stack based architecture, I have nowhere near enough experience with LLVM to try to bypass its built in stack management and try to roll my own and LLVM doesn’t yet have good support for any embedded devices instruction set.
Instead modern YASL is more focused on just being an exploration into a better general purpose language. Hopefully through what I learn doing this I can make another attempt at a beautiful, svelte language specifically optimised for the special challenges of ultra low power embedded development.
Probably the overriding goal for YASL is to create a language that can support as many nice features as languages such as Ruby, while being as performant in the general case as languages such as C/C#. This will involve ensuring that 90%+ of the language commonly used can be fully reconciled and optimised at compile time, whilst making it possible to easily optimise the remaining 10% at runtime. Unfortunately this will probably mean a big runtime size issue, similar to the pain felt when opening the first .NET application since a restart, hopefully it will be possible to come up with some solutions for this as well.