Re: goops and memoization

[Mikael Djurfeldt]

First a disclaimer:

I added GOOPS to Guile because I needed an object system in my neural
simulator.  I did not have infinite time to code, but I tried to focus
on at least getting the user-level definition reasonable so that we
would not build ourselves into a corner.  I looked at many different
kinds of object systems when arriving at the current GOOPS.

That said, quite a lot of the code was developed during a few days a
certain Christmas, and parts of compile.scm was written on Arlanda
airport while waiting for boarding an aircraft.  I urgently needed
someting working and planned to rewrite it later.

Well, later I judged it would serve people better to add the code to
the Guile source tree than letting people wait infinitely until my
rewrite would get high enough priority.  I then tried to get
volunteers to rewrite the code in C.

While there are "dark corners" in GOOPS I still dare to claim that it
works on sound principles, works reliably and is probably one of the
most efficient Scheme object systems.  Benchmarks show that GOOPS
method dispatch is negligible and a GOOPS generic function nearly as
efficient as an ordinary closure.

Dirk Herrmann <address@hidden> writes:

> This conflicts with goops:  goops unmemoizes the function code, using
> 'procedure-source' (look into oop/goops/compile.scm).  This will re-create
> the original code, including all the symbols that refer to local
> variables.  This un-memoized code is then optimized in some way, and
> re-written into the closure object.  Then, if the closure is evaluated, it
> is not run through the memoizer again (since it is already a closure).
  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Just a note: This is something which holds *after* your change, not previously.

> Now, if the executor runs over a symbol corresponding to a local variable,
> it will treat is as a symbol belonging to a global variable and try to
> find it within the module.

I'm sure Neil would find his way in the code, but since the answer
seems obvious to me because of my previous knowledge, I'll give some
hints:

A few notes on GOOPS method dispatch:

As in most CLOS-like systems, GOOPS method dispatch is quite advanced.
For example, a generic function application involves sorting the
applicable methods after specificity.  We might in fact like to make
it even more advanced (adding support for singletons and type coercion
for example).

To get GOOPS fast, we cache the results of this involved process in a
"method cache" in the generic function.  Next time a GF is applied to
the same set of argument types, the evaluator just makes a quick
lookup in the cache and can start to evaluate the method body without
delay.  The format of the method cache is described in
oop/goops/dispatch.scm.

The procedure compile-method in oop/goops/compile.scm takes the sorted
list of applicable methods and a list of the argument types in the GF
application and returns a "cmethod", which is the tail of a method
cache entry:

  CMETHOD ::= (CLOSURE-ENVIRONMENT FORMALS BODY-FORM1 ...)

Currently, compile-method only makes sure the method has a local
next-method binding (specific to this method cache entry) if that is
needed.  However, there are plans to let it make powerful
optimizations of the code, with great potential of reducing overhead.

It seems to me that what you need to do is to run the tail of the
cmethod (BODY-FORM1 ...) through your memoizer.  That should fix it.
In fact, as you see above, a cmethod contains the same information as
a closure.

Mikael