Re: goops and memoization

From: Mikael Djurfeldt <mdj@kvast.blakulla.net>
Cc: djurfeldt@nada.kth.se,
	 Dirk Herrmann <dirk@sallust.ida.ing.tu-bs.de>,
	Neil Jerram <neil@ossau.uklinux.net>,
	 guile-devel@gnu.org
Subject: Re: goops and memoization
Date: Tue, 03 Dec 2002 08:59:48 +0100	[thread overview]
Message-ID: <xy7lm37y1l7.fsf@linnaeus.i-did-not-set--mail-host-address--so-tickle-me> (raw)
In-Reply-To: <02120219132603.12810@locke.free-expression.org> (Lynn Winebarger's message of "Mon, 2 Dec 2002 19:13:26 -0500")

Lynn Winebarger <owinebar@free-expression.org> writes:

> On Monday 02 December 2002 03:45, Mikael Djurfeldt wrote:
>> procedure-source.  I actually think working on the memoized
>> representation is more of a hack, but that might be motivated anyway
>> for reasons of efficiency.
>
>        The problem with "unmemoizing" is that you don't have any
> guarantee that 'lambda is bound to the constant system lambda
> macro when you unmemoize.  The real justification for memoizing
> is that you're evaluating the variables 'lambda,'if,etc to system 
> constants.  

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.

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.

Thus, we have the requirement that memoization is semantically 100%
reversible.  Then one might of course argue that that is a too strict
requirement.

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.

Then it happens that it is cleaner and more modular since the
procedure-source interface separates goops code from the particular
details of the current evaluator.  (True with regard to this question.
However, the code unfortunately contains dependencies on the
evaluator's representation of the environment.  *That* is a hack.)

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.

Best regards,
Mikael

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