Re: goops and memoization

[Lynn Winebarger]

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.

> Note that for method optimization to work, unmemoization *must* be
> faithful to the semantics of the procedure.  The optimizer must be
> able to lookup the true binding of every identifier.

      The memoizer is not an optimizer.  It merely expands macros
into a constant core representation.  I fail to understand the problem.
The internal constants are precisely what you want - a representation
of core scheme (plus some things like "and" and "or" that are
syntactic sugar but implemented for speed).   They're not pointers
into a run-time symbol table, but so what?  It's easy to translate
them to symbols for printing purposes.

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

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

Lynn