Re: goops and memoization

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

Dirk Herrmann <dirk@sallust.ida.ing.tu-bs.de> writes:

> As stated in my previous mail the output of procedure-source is not the
> full scheme code that is necessary to re-memoize the code:
>   guile> (define foo (let ((bar 1)) (lambda () bar)))
>   guile> (procedure-source foo)
>   --> (lambda () bar)
> That is, trying to re-translate this output is not as clean a separation
> as you claim.  You depend on the fact that during execution there is
> sufficient information available to reliably re-compile any code such that
> it fits into the rest of the compiled code around it.  That is a strong
> assumption and it may prove to be expensive to guarantee it.

Could you explain this to me?  Why is it such a strong assumption?

My obvious counter example is:

(define foo2 (local-eval (procedure-source foo) (procedure-environment foo)))
(foo2) --> 1

[There is a need here to treat the first `lambda' specially, but
 that is a trivial problem.]

Which do you think puts the heavier constraint, procedure-source or
procedure-environment?  Note that there is no assumption needed that
procedure-source returns the verbatim source expression from which the
closure was created.  And an environment is simply a mapping of
variables to bindings.

Note that there is nothing "around" the method into which it should
fit.  The method has it's own closed environment.
  
> I had not actually planned to work on goops itself, and I will try
> to avoid doing so if possible - my resources are limited.  If we can
> agree on one way to go, I would prefer if I would not have to modify
> goops myself.

That is fine.  Can you share your current source?

> To get around the current problems (which are only relevant in my private
> copy of guile - none of my changes are yet submitted) I have suggested to
> replace one kind of dependency between goops and the evaluator
> (compile-method relying on the possibility to re-compile the output of
> procedure-source) by another one (compile-method working directly on the
> memoized code).  You are suggesting a different way, namely to add an
> interface to allow memoization of re-compiled scheme code and re-insert
> this code into the rest of the memoized code, which is just another form
> of dependency.  My preferred long-term solution, to have optimization
> functions work on a post-syntax-expansion-pre-memoization intermediate
> format also gets rid of some dependencies and adds a dependency on the
> intermediate format.  Dependencies are acceptable if they are between
> parts of the code which are stable, which I hope the future and yet to be
> defined intermediate format to be.

Well, I may be dense, but

* You have still failed to show to me why the second alternative
  (working on Scheme source) introduces any kind of dependencies (given
  that we fix the "hole").  I'd really want you to try to convince me
  about that.

* I like your suggestion for long-term solution.  And,

* It's perfectly fine with me to re-implement compile-method in C,
  working on the memoized representation.

Best regards,
Mikael


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