>>> I've seen `elisp.test' trigger a stack overflow with the interpreter
>>> more often than any other test.  Don't know why.
>>
>> I hacked around this -- see what I've pushed to vm for more info.
>
> I plan to take a look at this after the srfi-18.test hang.  (Not that
> that should stop anyone else, of course.)

Not the stack overflow yet, but see attached for fixing the elisp apply error.

It's not rocket science, and you probably guessed at that solution
already - but I think it really is the _right_ fix, because

- the principle of the elisp integration is that there is a new value
#nil, which acts as EOL in list contexts, and as #f in boolean
contexts

- as one example of this, the non-VM apply accepts and handles a list
whose tail is #nil

- therefore the VM apply should too.

What do you think?  Let me know if you'd like me to commit.  (Note I
haven't checked in detail if any of the other places that use
PUSH_LIST should definitely NOT allow a list whose tail is #nil.  If
yes, I guess we'll need two variants of PUSH_LIST.)

Regards,
       Neil