<div dir="ltr"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>Lisp is the simplest language to bootstrap for sure.</div></div></blockquote><div><br></div><div>i think stack languages are even simpler to bootstrap than lisps, and modern stack languages are not that much less comfortable.</div><div><br></div><div>a friend of mine is actually exploring that here: <a href="https://github.com/nagydani/seedling/">https://github.com/nagydani/seedling/</a></div><div><br></div><div>and by simple i mean that he's doing it using a ZX spectrum emulator as an artificial size/speed constraint.</div><div><br></div><div>we are exchanging ideas as we make progress, and when seedling will be ready i'll also bootstrap Maru off of that low-level stack machine.</div><div><br></div><div>you can think of (the bottom language of) seedling as the new C in the sense that it can function as the first layer, or the lowest common denominator on top of the hw to build upon, and can trivially reproduce itself onto a new hw.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>out of the bootstrapper that isn't the core Lisp language. Of course, it's probably worth</div><div>having handcrafted LLVM code for the primitives that greatly affect performance.</div></div></blockquote><div><br></div><div>i've admittedly haven't spent much time optimizing stuff, but i also haven't found myself needing to write LLVM/asm code to optimize anything. i'm much more progressing towards handling everything from lisp, from the handling of tagged immediate values to the nifty details of the GC. and that code hardly ever needs more than pointer dereference and arithmetic operations, and are already mapped pretty directly to LLVM/asm instructions. i have macros after all that can expand to the low-level primitives.</div><div><br></div><div>a big question of mine currently is hygienic macros and modules, and their interaction. more specifically: whether modules should have separate symbol tables, or only separate bindings together with a global symbol table. i'm leaning towards the latter because it makes many things simpler and independent (e.g. the reader doesn't need to know about modules)... and i think the implementation of hygienic macros should be a user library anyway that doesn't rely on isolated symbol packages, but rather on parsing the code templates and implementing the isolation on the AST level (as opposed to the lower level of symbol equality).</div><div><br></div><div>my implementation of modules is informed by this paper:</div><div><br></div><div>Submodules in Racket - You Want it When, Again? by Matthew Flatt<br><a href="https://www.cs.utah.edu/plt/publications/gpce13-f-color.pdf">https://www.cs.utah.edu/plt/publications/gpce13-f-color.pdf</a><br></div></div></div>