I've been worrying about implementing compilers and interpreters for a long time. As a platform for hands-on R&D, nothing beats a listener-based implementation, where one enters statements and expressions from the console and files directly into the system, essentially combinding the compile step and the 'go' step. Such things also double as scripters if they can be extended to call arbitrary libraries. My first foray into this world entailed David Betz's XLisp and the Silicon Graphics GL library, a precursor to OpenGL. I used a “Glue“ approach, writing custom wrappers and designing data-structure conversions for over 700 routines and types. I wasn't real happy with the brute-force approach, especially since TONS of exploitable, repetitive pattern emerged as I slavishly performed cut-paste-edit, but I didn't have time to learn the assembler and C-compiler internals necessary to graduate to wrapper generation. By the way, I believe Eric Raible, who was aware of my effort at the time, helped coin the term Superglue with his co-author, J. P. M. Hultquist. I frequently use “Superglue“ to refer to general strategies for generating wrappers automatically as opposed to “Glue,“ which is writing wrappers by hand.
I eventually solved the “Superglue“ problem completely for the Windows platform using Siod, George Carette's marvelously tiny interpreter. I copied my paper about that a few days ago to this blog.
To push Superglue into the CLR world, I started with a copy of Luna Scheme. After a few bug fixes, I got this off the ground and wrote stressful regression tests over the Y-combinator and the usual combinatorially explosive Fibonacci and so on.
Being based on CLR, Luna is an incredibly lucid implementation of a compile-and-go scripter, because vast amounts of infrastructure are already provided by CLR, and the code to implement the compiler is very simple. Every such scripter works by running a “REPL”, or Read-Eval-Print Loop. “Read” reads expressions, “Eval” evaluates them, and “Print” prints them. Reading an expression is converting it from a textual representation to an internal representation. Evaluating an expression is retrieving values of variables, expanding syntactic macros, and applying functions to arguments. Printing an expression is converting it from internal representation to external, ASCII, readable form.
HICCUP -- I was going to paste some code here and give a line-by-line analysis, but that will have to wait for some tools research. My first attempt at just pasting code text here, even under 'verbatim' and 'tt' HTML tags, didn't work at all. Back soon with real meat...