goops compilation under vm: not quite.

[Andy Wingo]

Hi,

I've been looking at how to compile goops, and to use it from compiled
code.

I have converted all macros to be defmacros instead of `mmacro's, so
that they produce effects via their expanded code instead of as a side
effect. (For example, a define-class might require define-method, which
might require a define-generic.) So far so good.

The problem comes in that a method procedure is assumed to be
interpreted and not compiled, so that you can call procedure-source on
the method procedure. This is needed so that when you call the method on
a set of concrete types, GOOPS can lazily generate the `next-method'
procedure, with respect to the types being dispatched, and then
"compile" the "effective method procedure".

(I say "compile" because goops does do nasty tricks with SCM_IM_LAMBDA,
etc.)

This has a couple of problems. One, the source is not available for the
canonical method procedure; but that's OK, given that we can store the
/source/ of the method in addition to its default procedure, and do lazy
compilation with the source.

But this has a second problem, in that lazy compilation /just based on
the source/ loses information about the lexical environment in place
when the method was defined.

For example, I understand that the following is a legal method
definition:

    (define-generic foo)
    (let ((x 10))
      (define-method (foo)
        x))

In Common Lisp, there is a representation of the compile-time
environment given to `make-method-lambda':

    
http://www.ai.sri.com/~delacaze/alu-site/alu/mop/dictionary.html#make-method-lambda

In Swindle, PLT's version of CLOS, they pass `call-next-method' as a
functional argument of the effective method:

    http://svn.plt-scheme.org/view/trunk/collects/swindle/clos.ss?annotate=8523
    (line 151; #,cnm is call-next-method)
    
This is not so nice though, as it removes the possibility for some
low-level compilation.

I don't think I can use `eval' to make methods and preserve the current
behaviour, because the procedure-environment would be the toplevel
environment.

I suppose that I could introduce a new syntax,
(compile-time-environment), that would return the <ghil-env> active for
that compilation block. By the time a dynamic compiler would come around
to use it, the indices would be finalized (e.g. that `x' would be
determined to be #0 among the heap-allocated ("external") variables,
etc.).

I really would like to preserve this dynamic compilation thing, because
compiling a method body with a set of known concrete types would be
fascinating.

Any thoughts on this strategy? Perhaps I'll look at implementing this
tomorrow morning or so.

Cheers,

Andy
-- 
http://wingolog.org/