0.2.0 development branch

[dfellis]

This will be a long-standing branch that 0.2.0 development work will go under.

Tasks for 0.2.0

• Implement CLI argument parsing for the features to be in 0.2.0 (compile, install, and maybe an interpreter mode)
• A nom-based parser for the Alan language syntax
• Write primitive proof-of-concept Alan to Rust transpiler that supports a few features of Alan
• Determine if/how to embed rustc into alan to compile without an external Rust toolchain
• Hook up the old test suite to the new compiler, getting some things to pass but obviously not everything
• Drop all of the old code besides the compiler and test suite

Tasks after 0.2.0

Once the above is implemented, this branch will be merged. Other goals that will follow 0.2.0 include:

• Reach feature parity with 0.1.0 (for features that are actually being carried over)
• Add new language features like built-in mocking support
• Write primitive proof-of-concept Alan to "WGSL" transpiler that supports a few features of Alan (some things like stdout can only be bridged between wgpu and Rust proper, so it will be WGSL + a Rust harness)
• Determine an intermediate representation that works well for both targets and implement it. It might make sense to have statement dependencies in this intermediate representation.
• Rewrite the transpilers on this intermediate representation
• Add logic to determine when to use which representation, and merge the two compile paths into a unified path
• Other interesting things, like a language server, linter/formatter, etc

[dfellis]

To answer this:

Determine if/how to embed rustc into alan to compile without an external Rust toolchain

First, it is possible to write a Rust program that embeds the Rust compiler in it, with the rustc_driver crate

Unfortunately, using it this way has an unstable API, while the CLI interface is stable. It appears that rustc, cargo, etc are all actually a single binary that chooses its behavior based off of the name it has been invoked with:

damocles@elack:~/.cargo/bin$ sha256sum cargo
0b2f6c8f85a3d02fde2efc0ced4657869d73fccfce59defb4e8d29233116e6db  cargo
damocles@elack:~/.cargo/bin$ sha256sum cargo-fmt
0b2f6c8f85a3d02fde2efc0ced4657869d73fccfce59defb4e8d29233116e6db  cargo-fmt
damocles@elack:~/.cargo/bin$ sha256sum rustc
0b2f6c8f85a3d02fde2efc0ced4657869d73fccfce59defb4e8d29233116e6db  rustc
damocles@elack:~/.cargo/bin$ sha256sum rustfmt
0b2f6c8f85a3d02fde2efc0ced4657869d73fccfce59defb4e8d29233116e6db  rustfmt
damocles@elack:~/.cargo/bin$

So, embedding rustc as a binary variable within alan that is extracted to a temp file with the desired name and invoked should work, and even provide useful functionality like being able to format the output code or install rust dependencies with cargo, just by changing how the temp file is named.

The binary appears to include everything it needs (there's only a bin directory, no lib), so at least for now, that appears to be the more stable way to embed a Rust compiler within Alan.

[dfellis]

Hmm... So that was very wrong. The actual path to the binaries is elsewhere, on my machine at ~/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/bin, the sizes of these binaries are very different from each other, and there is a whole lib directory with a bunch of shared libraries in there. I don't know what the binaries in the ~/.cargo/bin are completely for, except at 14MB if they're just invoking the command they're named after they're quite inefficient at it.

I suspect using the rustc_driver crate won't help me, much, though, as it will probably still rely on dynamically-bound shared libraries, defeating my single binary compiler intentions.

For now I will mark the task as complete and simply rely on rustc being in the $PATH, and come back to this later.

[dfellis]

Before merging this, I'm going to update the various markdown files, but that can wait for tomorrow.