[Top][All Lists]

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

Re: goops and memoization

From: Mikael Djurfeldt
Subject: Re: goops and memoization
Date: Wed, 04 Dec 2002 03:25:51 +0100
User-agent: Gnus/5.090008 (Oort Gnus v0.08) Emacs/21.2 (i386-pc-linux-gnu)

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.


> 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

reply via email to

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