[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: goops and memoization
From: |
Mikael Djurfeldt |
Subject: |
Re: goops and memoization |
Date: |
Thu, 21 Nov 2002 20:08:01 -0500 |
User-agent: |
Gnus/5.090008 (Oort Gnus v0.08) Emacs/21.2 (i386-pc-linux-gnu) |
Neil Jerram <address@hidden> writes:
>>>>>> "Mikael" == Mikael Djurfeldt <address@hidden> writes:
>
> Mikael> (An alternative solution is to implement compile-method in
> Mikael> C, memoizing the source code while walking through it. In
> Mikael> fact, that could mean that we don't need to call
> Mikael> procedure-source => no need to unmemoize code.)
>
> A further possibility occurs to me - transforming the method
> definition at define-method time something like this:
>
> (define-macro (make-method gf specializers formals . body)
> `(letrec ((m (lambda ,formals
> (define (next-method)
> (call-next-method ,gf
> ,specializers
> m
> ,@formals))
> ,@body)))
> m))
>
> Given the gf and specializers, call-next-method works out a list of
> applicable methods (probably cached) in the same way as for a normal
> gf application, then it looks through this list for m and applies the
> method after m to the supplied arguments (formals).
>
> Would this kind of approach work?
It would "work", but gee... then you are talking about a totally
different speed regime than what holds now.
Are you saying that you'd want to compute the list of applicable
methods at every call to (next-method)? That way overhead per call
would become O(NM) where N is the number of applicable methods and M
the maximum length of argument lists.
Well, then I'd start avoiding to use next-method in certain code, and
I'd really hate that.
Call me a speed maniac, but I want to be able to write my programs in
a form that is similar to how I think of the problem without worrying
that it would be too slow. Basic language mechanisms *must* be
efficient. You may say (well, *you*, Neil, wouldn't) that "well, then
you shouldn't use scheme", but my point is that I'd like to use these
nice ways of expressing programs in as great extent as possible.
[For those who still think I'm being silly: My programs currently run
for *days* just analyzing one data set...]
Mikael
- goops and memoization, Dirk Herrmann, 2002/11/16
- Re: goops and memoization, Neil Jerram, 2002/11/17
- 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 <=
- 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, 2002/11/29
- 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