Re: full moon, vm status update

[Andy Wingo]

Hi Neil,

On Tue 28 Oct 2008 00:51, "Neil Jerram" <address@hidden> writes:

> 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?

So, I'm really happy that you're hacking on this!

I think there are better ways of supporting multiple languages than the
approach taken historically by Guile, and that taken by this patch.

I do not think the interpreter / subr division is appropriate for a
multilingual system. To me, the division should be:

 * The evaluator / interpreter, that deals in Scheme;
 * A layered compiler, with different top-level layers for e.g. Guile,
   R6RS, Elisp, etc
 * A VM, with generic opcodes and opcodes specific to the languages that
   target the VM
 * A library of procedures written in C, where each procedure is related
   to /one/ language, Scheme in the case of most procedures.

So, the best option would be to have /a separate elisp compiler/. You
already have this, sortof. But in the specific context of apply, I would
have "apply" be a different operator in the elisp case, supported by an
elisp-specific opcode that deals with nil.

(Alternately, you could redefine `apply' in Scheme, for the elisp case:
 (define (elisp-apply f . lists)
   (apply apply f (frobate lists))))

Granted, we have ideals, and we have tradeoffs, and writing an elisp
compiler. (Then again, maybe not that bad.) If I have to add what I
consider to be a hack to the `apply' case in order to keep you hacking
on the VM, then the tradeoff is worth it to me.

But at some point I think you should indulge your secret desire of
writing a compiler! ;-)

What do you think of all this?

Cheers,

Andy
-- 
http://wingolog.org/