Re: goops and memoization

[Mikael Djurfeldt <mdj@kvast.blakulla.net>]

Lynn Winebarger <owinebar@free-expression.org> 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


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel