Re: expansion, memoization, and evaluation...

[Mikael Djurfeldt]

klaus schilling <address@hidden> writes:

> Mikael Djurfeldt writes:
>  > If the optimizer does source --> source transformation it's reasonably
>  > easy to use it together with an offline compiler.  It's more difficult
>  > to explain the memoized code to the compiler...
>
> How is code generated at run-time evaluated by eval , eval-string, 
> or local-eval handled by the optimizer?

Clarification: The particular optimizer we're talking about here sits
just before method code is run for the first time, that is as a part
of the application of a generic method.  It is supposed to mainly do
goops-specific optimizations.

Answer: The only way for eval, eval-string or local-eval to get to
code generated by the optimizer is by invoking a generic function.
This GF does type dispatch on its arguments.  If the offline compiler,
through code analysis, has concluded that code will be needed for a
certain combination of arguments, the GF can select precompiled code.
If not, there are different possible alternatives to choose from:

Alt 1: Handle it as in the interpreter.

Alt 2: Same as alt 1, but invoke the compiler dynamically on the
       output of the optimizer.

Alt 3: Invoke an unoptimized version of the method (with all internal
       type dispatch intact).

Alt 3 is the "vanilla" way to do compilation.  You see, I'm not
talking about peculiarities of goops putting constraints on how you
can do compilation.  You can compile things standardly alright.
Rather, it's about novel opportunities.

M