The April Programming Language
A language empowering its author, and really no one else at the moment, to experiment with new ideas.
There isn't much to see here yet, but read on to see why I'm doing this.
Additionally, the source code for the compiler is not yet publicly available. If you're here for that, come back later.
Motivation
For a long time, I've wanted to make my own programming language. I've made a bunch of toy ones, and done a lot of learning, and this time I'm serious.
There are a lot of problems that need solving, and I'm making April as my sandbox for experimenting with solutions. With that in mind, I'm taking on an additional challenge, as I won't want to do it more than once: I'm going to maintain its bootstrap chain, from start to finish, and make the compiler as portable I can manage.
For this reason, the first stage compiler is written in C. In particular, a hopefully compliant subset of C99 and C11.
Additionally, for the sake of easy bootstrapping, the first stage compiler shall be kept buildable inside of only two invocations of a C compiler, plus the execution of one compiled C program.
cc src/gen.c -o gen
./gen
cc src/april.c -o april
The exact way you'll invoke gen.c is not yet set in stone,
but the crucial thing here is that these build steps are manageable to do
manually. This is important, because April is meant to be bootstrappable
from a C compiler, with no other specific dependencies on the environment
in which it is being built.
...other than the execution environment being hosted, not freestanding, C. The April stage 1 compiler does support being used as a library, even in a freestanding C environment, but I haven't settled on a way to do the code generation step of building it in a freestanding environment. Most likely, the code generator will itself be refactored to be usable as a freestanding library.
But What About Weird Machines
I lied. There's one other reason I'm doing this in C{99, 11}.
There are a lot of weird and sometimes kinda broken computers out there, and a lot of weird and sometimes kinda broken operating systems. Things for which many people decide the tradeoff of supporting these machines with their favorite language or application or library is not worth accepting. Those people are perfectly within their right to do this, but I worry that we're often leaving programmers working with such weird systems with no choice but C.
So, April is going to try to support as many of these weird machines as it can. The April compiler is even going to run on these, not just target them. I don't know how achievable this is, but I'm willing to burn my fingers a little on the problem.
With that said, the April compiler itself, and possibly the language as a whole, might insist on living in its own little fantasy land bubble that interacts incredibly little with the outside world. Don't pin your hopes or dreams on this project, at least not yet.
Really, I don't know what the platform support policy for April is going to look like yet. I just know that I'm going to try.
The Syntax
In all the hullabaloo of writing a compiler in C, I haven't spent too much time designing this yet, because my first aim is to have something that runs at all. So, for the time being, you can think of April as being a statically typed Lisp with type inference.
(fn main ()
(println "Hello, world.")
(let ((x 10)
(y (* x 2)))
(println "x * 2 is {}" y)))
Most likely, I'm going to change variable declarations to work like in Rust, where you don't need to write a new block scope around all code that follows and uses a given variable declaration. But this is how Lisps have tended to do it, and my focus has been elsewhere.
Features
Before I get started, let me be very clear: None of these are implemented yet.
With that out of the way, I have a rather long wish list of things I would like to see in a language, and I'm going to try to experiment with each of these at some point.
TODO: write about each of these.