flpc

ough. There's tcc (and more recently chibicc that I haven't had a chance to check out yet) that you're probably already aware of. Is the generated output still pretty bad. I'll also throw my own attempt in the ring - High level https://github.com/asrp/flpc/blob/master/lib/stage0.flpc - Low level (up to line 45) https://github.com/asrp/flpc/blob/master/precompiled/self.f even though it's not quite optimized for this purpose and the code itself is still a bit unclean. If there was a syntax highlighter for the low level language, I'd probably highlight "[", "]" and "bind:" as a start. I can try to clarify any obscure syntax or primitive. Some more general ideas to get aroud the issue. - Invoke optimization only when asked specifically (and apply the optimization locally). That is, optimization would need at least additional syntax in the language. - Explicitly track correspondance between source and target (at the character or token level) and also do this in each optimization pass. Maybe even keep the intermediate values of each pass so you can browse through it like a stack trace. > In my mind there's an idea maze where there are 3 major possibilities for improving the future of software: I guess I'm trying another route even though I don't know if it fits the definition of improving the future of software. d) Have programmers make their own compiler/interpreter and language by giving them the tools and knowledge to do that (more) easily. This would (hopefully) avoid the black box/magic issue since the programmer would know the details of the inner workings by virtue of having written it. Though I'm most definitely very far from the goal and the questions can be asked about how to improve their target language.

rything is an expression). It gets parsed into a prefix-oriented Lisp-like syntax tree. The interpreter is a "machine" based on Lisp's eval, with lambda, macro, tail-call optimization, etc. So, basically, the language is just syntactic sugar that compiles down to whatever the machine expects. I plan to implement another (much simpler) parser for a Lisp-flavor of the same language. In the case of FLPContinuum, I see that the interpreter is a stack-based loop (https://github.com/asrp/flpc/blob/f47de76fcab6d2d2b1840e5376...). The actual implementation of the "machine" almost doesn't matter for the language(s) though, as long as the interface stays the same.