Re: goops and memoization

[Mikael Djurfeldt]

Tom Lord <address@hidden> writes:

>        > 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.

Yes.

> 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.

Hmm... could you please clarify this suggestion.  What is the core
idea?  To specify O in a custom language and compile it?  To optimize
the composition of M O and U?  Something else that I have missed?

Best regards,
Mikael Djurfeldt