Re: full moon, vm status update

[Neil Jerram]

On 31/10/2008, Andy Wingo <address@hidden> wrote:

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

That last point seems odd to me.   Surely if Guile gets good multiple
language support,  we don't want to tell developers that they have to
write a different version of each new primitive for each high level
language?

>  So, the best option would be to have /a separate elisp compiler/. You
>  already have this, sortof.

You mean (lang elisp transform) ?  I agree that this is sort of a
compiler.  The problem is that it only handles code; it doesn't
translate data at all.

A key point of the current implementation is to avoid needing to
translate data when it is passed from one language to another; we
decided on that because data translation would be arbitrarily complex
(so potentially very bad for performance) and I think would require
tracking of language boundaries (which we don't need now).

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

That's fine for elisp code calling apply directly, but not for passing
a list of args to a scheme -implemented function which calls apply.

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

(Just the same point again; here shown by the introduction of frobate,
 and the fact that it needs to do conversion to arbitrary depth.)

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

So secret that I don't know about it?  Actually you might be right... :-)

   Neil