It should be possible to create non-nested vector collections; this
will be critical for defining the basic structures for the compiler.
cons(null, ()) should be legal; cons(undefined, ()) should not. This
is now supported in the code.
Not sure how portable this is; it works fine in V8, but that's not
saying much. I like it more, though, and it supports a couple of
features I'm looking for.
This may be a case of designing the language around the compiler,
but it's a pretty interesting step.
This update locks us into a late ECMA-5 implementation (no ECMA-3 for
you!) but it improves the way this representation works and is presented
to users. It also corresponds (unsurprisingly) to the format used by
my experimental LiSP implementation, thus making my life easier.
Also: Included unit tests to ensure that nilp, listp, pairp, and cellp
all detect the correct matrix of... things.
I think this is a mistake, but at the moment I'm not clever enough to
figure out how to properly acknowledge an end-of-list without a special
sentinel, which I'm trying to avoid.
TODO: Revisit this.
Modified Makefile to produce JUnit-compatible error messages.
Style (coffee-lint cleanup)
Updated metacadr's test suite to ensure that re-using a
metacadr-generated function does not lead to crashes. Saw this a lot in
early versions of LISP.
Lists are mutable, even by-reference. When I was popping off the values,
I was destroying the list; metacadr only worked once. That was terrible
functional programming. I should learn to trust myself; by using a
cons-list for my operations index and a lookup table (anti-if!)
for my operations, the code was simplified incredibly.
Also, added a very (!) primitive pretty printer. It'll get better over
time, but for now it's sufficient for debugging.
Elf M. Sternberg
Ken Elf Mathieu Sternberg