Runtime macroexpansion is evil, indeed

By bgeron

I’m trying to implement an Arc-like Lisp dialect, and my code currently runs in an interpreter run within an interpreter (only made to bootstrap the Parrot code). I just finished implementing cond (I’m not implementing if in terms of cond as PG may do, the other way around makes the code simpler), and all the code that used cond was getting rather slow. Not strange, really, as I had been expanding macros at runtime. (It’s the easiest way, they are first-class objects like in Arc.) So, I made some assumptions for the bootstrapping code to allow for a simple ‘compile-time’ (well, it’s between read-time and eval-time) macroexpander. Running it on a part of the macroexpander itself took some time and memory:

code screenshot with timing

Next thing to do: make the interpreters cons less.

Leave a Reply