[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: goops and memoization
From: |
Neil Jerram |
Subject: |
Re: goops and memoization |
Date: |
29 Nov 2002 22:48:47 +0000 |
User-agent: |
Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 |
>>>>> "Mikael" == Mikael Djurfeldt <address@hidden> writes:
Mikael> Dirk Herrmann <address@hidden> writes:
>> This conflicts with goops: goops unmemoizes the function code, using
>> 'procedure-source' (look into oop/goops/compile.scm). This will
re-create
>> the original code, including all the symbols that refer to local
>> variables. This un-memoized code is then optimized in some way, and
>> re-written into the closure object. Then, if the closure is evaluated,
it
>> is not run through the memoizer again (since it is already a closure).
Mikael>
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Mikael> Just a note: This is something which holds *after* your
Mikael> change, not previously. [...]
Mikael> It seems to me that what you need to do is to run the tail of the
Mikael> cmethod (BODY-FORM1 ...) through your memoizer. That should fix it.
Indeed. If I understand correctly, what happens is that
scm_memoize_method in eval.c returns an unevaluated and unmemoized
lambda form, which the current evaluator handles by calling
scm_m_lambda, which performs the memoization stage.
The problem I presume is that your optimized evaluator doesn't handle
symbols in the CAR, because it shouldn't need to.
If this is correct, the fix is to pass `x' through your memoizer just
before `goto nontoplevel_begin;', like this:
apply_cmethod: /* inputs: z, arg1 */
{
SCM formals = SCM_CMETHOD_FORMALS (z);
env = EXTEND_ENV (formals, arg1, SCM_CMETHOD_ENV (z));
x = SCM_CMETHOD_BODY (z);
x = memoize (x); /* ADDED */
goto nontoplevel_begin;
}
A few notes:
- You could just call eval instead of memoizing and goto
nontoplevel_begin, but that wouldn't be tail-recursive. I wonder if
tail recursion is important here?
- Is the memoization stage sufficient here? What if the method
definition came from a module with a syntax transformer in effect?
If `procedure-source' returns post-transformation code, all is OK.
If it doesn't, there are two possible problems:
- The code returned by scm_memoize_method should be retransformed as
well as rememoized.
- `compile-method's manipulation of the source code might not work
in the pre-transformation language.
- Quite a few places in the GOOPS code use local-eval. Does
local-eval still include memoization (and syntax transformation?) in
your codebase?
I hope this helps; let me know if you would like me to dig or
experiment further.
Neil
- Re: goops and memoization, (continued)
- Re: goops and memoization, Dirk Herrmann, 2002/11/20
- Re: goops and memoization, Mikael Djurfeldt, 2002/11/20
- Re: goops and memoization, Mikael Djurfeldt, 2002/11/20
- Re: goops and memoization, Neil Jerram, 2002/11/21
- Re: goops and memoization, Mikael Djurfeldt, 2002/11/21
- Re: goops and memoization, Mikael Djurfeldt, 2002/11/21
- Re: goops and memoization, Neil Jerram, 2002/11/24
- Re: goops and memoization, Mikael Djurfeldt, 2002/11/24
- Re: goops and memoization, Neil Jerram, 2002/11/21
- Re: goops and memoization, Mikael Djurfeldt, 2002/11/21
- Re: goops and memoization,
Neil Jerram <=
- Re: goops and memoization, Neil Jerram, 2002/11/29
- Re: goops and memoization, Neil Jerram, 2002/11/21
- Re: goops and memoization, Dirk Herrmann, 2002/11/24