Stargaze Lisp, Part One. (And other things on language design)

I've briefly talked about this in a previous blog post; while Stargaze definitely satisfies the requirement of "somewhere in-between Lispkit Lisp and Scheme with a proper module system", by the end of what I deemed a plausible first public version, the whole code base is like 2000+ lines written over the course of 4 days, which would still take much effort if I were to rewrite it to C and port it to somewhere else.

TRAC is not a failure in terms of design, but Flowmark is. The fate of Flowmark was sealed when I decided that forward-reading should be one of the core features of Flowmark. I never finished it, because the way I defined it was incompatible with the TRAC-like algorithm Flowmark use to parse & evaluate things. The fact that I spent more than half a month to rewrite it in Racket and fuse it with a custom rudimentary document typesetting thing and not having the thing working correctly is just the cherry on top. Things like this is why I don't have a good-looking GitHub portfolio - lots of things I did never came to fruition.

Language One (temporary name) is an experiment of forcing everything to have an arity so that a lot of parentheses are not needed. I'm not sure if this is a good tradeoff. It could be a good candidate for writing b-programs, I suppose.

To make the decision of rewriting Camus in Nim is fatal. This is not how you do it; I should've sticked with JavaScript.

The future plan for Camus would be as follows:

• Implement full Camus 2 in JavaScript;
• Make a LSP server for it (so that I could have the incentive to use it over org-mode);
• Rewrite it to Python/Golang/Rust/Ruby. I suppose these four languages (together with JavaScript) is the most basic languages you have to write a library for if you want to push a new markup language in this day and age.

Back

Last update: 2024.8.24