This is the mail archive of the guile@sourceware.cygnus.com mailing list for the Guile project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: Trouble understanding define (!)


Michael Livshin <mlivshin@bigfoot.com> writes:

> Mikael Djurfeldt <mdj@mdj.nada.kth.se> writes:
> 
> > Actually, it seems to me that we can't just make a new generic
> > function for the module using it.  This problem requires some more
> > thinking.  E.g., what if we during interactive development work fix a
> > bug in the original GF.  We would then very much like the method to
> > "propagate" to all GFs derived from it...
> > 
> > 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.
> 
> sounds like much hair.
> 
> note that this problem stems from a CLOS syntactic "convenience
> feature": CLOS (and GOOPS) lets you use `define-method' without
> preceding it with the relevant `define-generic'.  so a user-burdening
> solution would be to revoke this "convenience feature", thus ensuring
> that the generic is defined *once*, and that if it is not then surely
> the user means two different generics which happen to share the same
> name.
> 
> without revoking the "convenience feature" we have basically two
> choices :
> 
> 1) blithely go ahead and ensure that the two (or more) accidental
>    generics are *merged* ("destructively" and retroactively) into one
>    (quite possible with the MOP, I guess).
> 
> 2) bomb out with a name conflict.
> 
> 3) [so I lied about the two choices] do 1) for slot-accessor generics
>    and 2) for the rest (assuming it's possible to cleanly separate the 
>    cases, i.e. the user's intent).
> 
> looks like I'm for 3) if the relevant assumption is true.  though the
> really clean solution would be to ban `define-method' without
> preceding `define-generic', IMHO.

OK, how about this:

1. We fix the apply generic MOP (it isn't yet implemented)

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.

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.

/mdj

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]