Self-hosting

[anttih]

This is a tracking issue for running purescm on purescm. Self-hosting purescm is useful because it's a nice use case for purescm and provides a better user experience. We don't have to shell out to scheme anymore and can leverage native threads for compilation among other things.

The steps to accomplish this are:

• [ ] Add support for incremental compilation. Working on purescm-on-purescm will otherwise be very painful, as running the test suite would do a full rebuild twice. Once for purescm itself and then once for the test suite. Incremental compilation should be possible by still using backend-optimizer's API, we just lose ALL the inlining and have to implement some of those by hand.
• [ ] Replace Aff usage with Effect. We don't rely on parallelism so this should be quite straight forward.
• [ ] *Remove all `Node.` dependencies**. This is basically just reading and writing files and doing file globbing. All non-portable stuff should now be in FFI.
• [ ] Add backend-optimizer to the purescm package-set. backend-optimizer itself probably works, but there are a few dependencies that need FFI definitions, like ansi.
• [ ] Implement all FFI in scheme. After this we support both node and purescm backends in purescm.
• [ ] Replace scheme shell calls with function calls. This is basically just the bundling phase and we can actually compile each scheme file individually to catch more bugs at compile time (Chez has it's own checks when compiling AoT). Currently we only compile scheme files as part of bundling.
• [ ] Refactor FFI stuff to ChezLib

[f-f]

I had a shot at implementing IO in the last months. It's all sync so it blocks all the time, and that is not desirable, which transforms it into a thread-coordination problem, and I don't like where that is going.

Currently sitting on it pondering options, I think our best shots are either using Swish (which gives us erlang-style async, and includes nice things like an http server), or directly binding to libuv

[anttih]

I had a shot at implementing IO in the last months. It's all sync so it blocks all the time, and that is not desirable, which transforms it into a thread-coordination problem, and I don't like where that is going.

Do you think we need to tackle async IO before self-hosting? I don't see it blocking this.

[f-f]

Do you think we need to tackle async IO before self-hosting? I don't see it blocking this.

Yeah I hope it's not a big block. Just noting that the builtin IO facilities are underwhelming and I didn't get them to work reliably yet, hence why I started looking for something easier to integrate.