Re: goops and memoization

[Neil Jerram]

>>>>> "Mikael" == Mikael Djurfeldt <address@hidden> writes:

    Mikael> I added GOOPS to Guile because I needed an object system
    Mikael> in my neural simulator. ... later I judged it would serve
    Mikael> people better to add the code to the Guile source tree
    Mikael> than letting people wait infinitely until my rewrite would
    Mikael> get high enough priority.

There's no question in my mind that you did the right thing here.

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

Are those benchmarks available?  If I do change the code, it would be
good to check that the changes don't hurt performance.

    Mikael> To get GOOPS fast, we cache the results of this involved
    Mikael> process in a "method cache" in the generic function.  Next
    Mikael> time a GF is applied to the same set of argument types,

... and if no new methods have been added in the meantime ...

    Mikael> the evaluator just makes a quick lookup in the cache and
    Mikael> can start to evaluate the method body without delay.  The
    Mikael> format of the method cache is described in
    Mikael> oop/goops/dispatch.scm.

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

Do you mean IOR ?  If so, couldn't most IOR optimizations be made when
the method is first defined?

Thanks for the explanations.

        Neil