Re: goops and memoization

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

Neil Jerram <neil@ossau.uklinux.net> writes:

>>>>>> "Mikael" == Mikael Djurfeldt <mdj@kvast.blakulla.net> 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


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