[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:41:27 +0100 |
User-agent: |
Gnus/5.090008 (Oort Gnus v0.08) Emacs/21.2 (i386-pc-linux-gnu) |
Lynn Winebarger <address@hidden> writes:
> On Tuesday 03 December 2002 02:59, Mikael Djurfeldt wrote:
>> Well, actually we have a guarantee that when we re-memoize, 'lambda,
>> 'if etc are bound to exactly the same thing as when the procedure was
>> originally memoized. This is because the lexical environment of the
>> method is used when re-memoizing.
>
> Either define-syntax or define can change the meaning of
> lambda in the global environment. It will use the same binding,
> true, but that's not the same thing.
Since procedure-source operates on a closure, I already know for sure
what kind of "lambda" created it. As for other mentions of lambda,
procedure-environment will tell me what they mean.
> The memoizer is not an optimizer. It merely expands macros
> into a constant core representation. I fail to understand the
> problem.
Problem 1: The optimizer gets dependent upon the memoized
representation.
[The goops dependencies that Dirk mention are really minor (except
for the current lack of an abstraction barrier towards the
environment) and can be adjusted quickly if things changes.]
Problem 2: Working on the memoized representation prevents writing
optimizations in Scheme.
>> Thus, we have the requirement that memoization is semantically 100%
>> reversible. Then one might of course argue that that is a too strict
>> requirement.
>
> Requiring reversibility of arbitrary macro expansions is pretty
> close to nuts.
Reversibility of macro expansions is not required. The optimizer in
fact works better if all macros already are expanded.
>> The original reason for the choice to work on Scheme code instead of
>> on the memoized representation was that it was simpler and could be
>> handled on the Scheme level, and could be made to work quickly.
>
> If you do it at the scheme level, sure. But if you're doing it at the
> C level you have to use some system-specific representation anyway.
> So what's wrong with constants?
Nothing except for problems 1 and 2 above.
(Clarification regarding problem 1: The "system-specific
representation" you talk about is not likely to change and trivial to
modify if a change should occur while large parts of the optimizer
might need to be rewritten if the memoized representation changes.
Consider, for example, that the tree structure of IM_DO is different
from that of "do" and it's quite easy to imagine quite a lot stranger
representations.)
Best regards,
Mikael
Re: goops and memoization, Mikael Djurfeldt, 2002/12/03
Re: goops and memoization, Mikael Djurfeldt, 2002/12/03