Re: goops and memoization

[Tom Lord]

       > But, as said earlier, being a efficiency freak, I'd like a
       > solution which works on the memoized code.  In order to
       > maintain a reasonably clean separation of goops code and the
       > details of memoizing, it might then be a good idea to provide
       > some kind of code traverser which goops can plug into and
       > operate with minimal knowledge of memoized representation and
       > environment.


Abstractly, you're computing something like:

        (M (O (U (M <source>))))

where M is the memoizer, O the optimizer, and U the unmemoizer.

Your ideal is to have O be a clean, perhaps even portable,
source->source transform that knows nothing about memoization, yet for
the whole composition to be fast.

Have you considered the approach of writing a custom optimizer (not O,
but another optimizer) that can do a good job of "compiling" (scheme
to scheme):


        (lambda (ms) (M (O (U ms))))

?

If O is very clean/high-level, you can do all kinds of tricks by
transforming it (e.g. automatic conversion to demand-driven
execution).  Writing O is just writing (with nothing extraneous) the
transforms that describe the possible optimizations, and then tools
that compile O and compositions of O with M and U can work out when to
apply those transformations and short-cut the compositions.


-t