Paul Dietz <email@example.com> wrote:
| Lists (not vectors) are the usual data structures for
| returning or passing sequences.
| One can imagine a lisp in which this emphasis was reversed.
| Programs would be trees of vectors.
Back when I was playing with writing my own Scheme (before switching
to CL), I actually did that, half-compiling IFs into 4-word vector-like
structures (a type marker plus 3 sub-form values), etc. But I found I
had a problem with the BEGIN form (PROGN in CL, also the bodies of
lambdas, do loops, etc.), namely, when a form in a BEGIN (a vector
of nforms+1 elements) had to save a continuation (e.g., when calling
a function or processing a sub-form) it had to save *both* the pointer
to the BEGIN vector and the index (a fixnum) to the next element (the
continuation). Whereas had I used a list-based representation for BEGIN
blocks, only the CDR of the current element would have needed to be saved.
It was worse than just that, though, since without thinking it through
all the way I yielded to the temptation to re-use the continuation object
by simply incrementing the index as execution progressed through the
BEGIN body. Big mistake. If one of the earlier sub-forms had captured
the current continuation and later called it, the index would have been
already advanced too far.
Finally, in order to pass all of "pathological continuation capture"
tests (especially a couple I got from Queinnec's "Lisp in Small Pieces",
but also see thw recent thread in c.l.scheme for some of them) I had to
back out of the vector representation and make BEGINs be a series of
linked vectors #3(BEGIN this next). [I would have just used cons cells,
but the code vectors were a distinct type.]
Note that some of the problem could have been avoided if I'd implemented
locatives (specifically, allowing pointers to the interiors of objects),
but that had GC implications I wasn't ready to deal with.
Rob Warnock <firstname.lastname@example.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607