This was a pain point. I had hacked the "names" of symbols into the
throw/catch representation, never appreciating how badly I was screwing
up my understanding of LiSP. The symbols are supposed to evaluate
to something. When they're self-evaluating expressions (strings and
numbers), those become the keys in the block stack that matter. Getting
SEE's right, whether they're quoted or not, was really signficant.
This is cool. Now, on to rewind/protect!
This is a big refactoring; the parser is now modal, to handle either
complex Node objects that carry around a lot of state with them, or
simpler objects that represent the McCarthy-style IST. I'm still
feeling my way through the subject material. The node construction
is such pure artifice I feel silly keeping it, and may end up revising
it (again).
The nice thing is, everything goes through evaluate. Almost no other
code needs to know anything at all about the shape of the Nodes themselves;
it all makes assumptions based on the return value (or continuation passed)
by evaluate.
I've hit a snag with respect to self-evaluating objects, and the ad-hoc evaluation of
program labels is messed up because of it. I'm going to have to refactor.
Oddly enough, the strategy I hit upon appears to be the same one found
in Wisp, rather than Clojurescript.
This may actually be an internal detail; the version rendered for the user may actually
not care. I hope not; the performance could become hairy pretty quickly.
This file is highly localized for my personal set-up. If you want to
run Jenkins yourself, you *will* have to edit it, or use it as an example
in your own set-up.
This passes all the basic tests provided from Lisp In Small Pieces,
chapter 3. This is a functional LiSP interpreter with limited ability
and very little bug handling, but it's a solid implementation that
matches the specification and passes the tests provided for the CPS
interpreter.
This commit does *not* provide any of the continuation variants
described in the book; it is only the base interpreter.
This also adds a number of accesory functions necessary for rationalizing
the record structure of an object in the lex/parse phase into something
more lisp-like. There's a metadata issue here that I'm not quite wrapping
my head around.
Elf M. Sternberg
Ken Elf Mathieu Sternberg