gemini://sunshinegardens.org/~xj9/posts/2019-12-17-prescheme/

> Pre-scheme was quite interesting. Kelsey published a paper[1] on it, as well, I believe. It was Scheme in the sense that you could load it into a Scheme system and run the code. But it was restrictive it required you to write in a fashion that allowed complete Hindley-Milner static type inference, and all higher-order procedures were beta-substituted away at compile time, meaning you could straightforwardly translate a prescheme program into “natural” C code with C-level effiency. That is, you could view prescheme as a really pleasant alternative to C for low-level code. And you could debug your prescheme programs in the interactive Scheme development environment of your choice, before flipping a switch and translating to C code, because prescheme was just a restricted Scheme. The Scheme 48 byte-code interpreter was written in prescheme. Prescheme sort of died – beyond the academic paper he wrote, Kelsey never quite had the time to document it and turn it into a standalone tool that other people could use (Ian Horswill’s group at Northwestern is an exception to that claim they have used prescheme)

apparently prescheme[3] exists in some form at least. i'd like to see if i can get it to work with chicken scheme. if not, well.. i'll go with scheme48[4] because prescheme is exactly what i'm looking for: a low level lisp-like language that fits in C's niche as a systems programming language. and i suppose its fair that i haven't written much of anything in scheme for this tracker project.. in any case i'm excited to dive in. hopefully everything works, if not i'll have some work cut out for myself to get it running. always nice to stand on someone's shoulders every once in a while.

i have some more thinking to do before i can make tracker happen. i think prescheme will be a good way to start building that lisp machine os that i keep dreaming about. i want to prioritize tracker over a new lispy operating system though. an all-scheme compiler toolchain for userspace isn't bad! there's still a giant pile of C underneath and prescheme can hopefully help us replace it.

i'm a little bit conflicted about elm. i love the language, but i'm not sure i actually need to build user interfaces in this way. i still don't know what future-user-programmable-ui[5] is actually supposed to look like, but maybe i don't have to figure that one out right now. getting the low level stuff right is important and maybe i'll find some friends along the way who help me figure out how to make a future-user-programmable-ui[5].

/g/ prescheme!