Re: Trouble understanding define (!)

[Michael Livshin <mlivshin at bigfoot dot com>]

Mikael Djurfeldt <mdj@mdj.nada.kth.se> writes:

> > > Maybe the set of methods could be regarded as part of the type of the
> > > generic function and maybe we could look upon the new GF as a subclass
> > > of the original.  If we do this, we get the "propagation" for free
> > > since this is handled by the class update protocol.
> 
> OK, how about this:
> 
> 2. We define a subclass <extended-generic> of <generic> which contains
>    a new slot `generic-functions'.
> 
> 3. We let `define-generic' and `define-method' query the module
>    system for the current value of all definitions of the name being
>    defined in all modules on the use list.  If it turns out that the
>    name being defined is exported from and is a <generic> in one or
>    more used modules, we create a new <extended-generic> with
>    `generic-functions' bound to a list of those functions.
> 
> 4. We turn `generic-function-methods' into a generic function and let
>    the method for <extended-generic> compose its result from the tree
>    of methods rooted at this object.

do extentions propagate back?  i.e.

-----------------------------------------------------------------
; module A
(define-module (A))

(export grumble mumble)

(define-method grumble ((a <A>))
  'grumble)

(define (mumble thing)
  (grumble thing))

-----------------------------------------------------------------
; module B
(define-module (B) :use-module (A))

(define-class <B> ...)

(define-method grumble ((b <B>))
  'return-of-the-grumble)

(define grumble-result (mumble (make <B>)))
-----------------------------------------------------------------

grumble-result should be 'return-of-the-grumble, but from the above
paragraph it seems that it will be 'grumble.  what did I miss?

> What is beautiful about this solution is that
> 
> 1. There is no distinction between accessors and other GFs.
> 
> 2. There are no back-pointers.
> 
> 3. Nevertheless, behaviour will change when a new method is added to
>    some GF imported from another module.
> 
> 4. It behaves as expected in all situations I can think of.
> 
> 5. Efficiency of method dispatch isn't influenced since it is
>    cached.

I'm still uncomfortable with the reliance on names, though...

> /mdj

--mike

-- 
The whole idea of modules is so separatist, anyway.  Can't we all just
get along?                                               -- Jim Blandy