Re: goops and memoization

[Mikael Djurfeldt]

Mikael Djurfeldt <address@hidden> writes:

> Mixing different stages as it is currently done introduces a lot of
> dependencies between different parts of guile.  This makes
> maintaining guile quite hard - our current discussion is already an
> example of the problem.

Just to clarify my points:

Working on the output of procedure-source does not introduce
dependencies.  On the contrary: Since the output of procedure-source
is required to be Scheme code, we have a completely clean separation
of different parts of Guile.  Regardless of how the evaluator changes,
this representation will remain valid and method compilation will
continue working.

However, working on the memoized representation *would* introduce a
dependency between Goops code and the current version of the
evaluator.  (I have the view, though, that that is acceptable.)

The current problem arises not because of how compile-method retrieves
its input, but because of how the result of the work of compile-method
is "returned" to the rest of the system.  Previously, it was OK to
regard the compile-method output as an executable representation, now
it is not.

The core of the problem is that while there exists a well-defined
interface for retrieving the representation of the method,
procedure-source, there doesn't exist a well-defined interface for
giving a compiled method back to the evaluator.

A standardized way would be to pass Scheme code in the form of a
lambda expression to "eval", but it is simply not possible to use that
standard interface, because methods need to preserve their local
environment.

So, again, if you want to preserve separation of parts of Guile, you
should provide the interface for giving compiled method source (output
of compile-method) back to Guile.

If you are prepared to sacrifice separation for efficiency, you should
implement compile-method in C and let it operate on the memoized
representation.

Best regards,
Mikael