[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

goops compilation under vm: not quite.

From: Andy Wingo
Subject: goops compilation under vm: not quite.
Date: Thu, 23 Oct 2008 22:13:10 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.60 (gnu/linux)


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

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,

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

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

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

In Swindle, PLT's version of CLOS, they pass `call-next-method' as a
functional argument of the effective method:
    (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

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,

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

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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]