Re: More questions regarding generic methods ...

[Mikael Djurfeldt]

address@hidden writes:

> it seems like all my problems disapear _iff_
> i eval '(define-generic func)' before trying
> to apply define-method or generic-function-methods.

Yes, but that is a different thing: Your call to `define-generic' will
create a new generic function object, whereas `define-method' on a
primitive-generic will add a new method to the already existing
function.

> So, if i understand this right, a primitive procedure can
> be in three states (be a member of three differnt classes):
> 
> #<primitive-procedure +>  pristine state
> #<primitive-generic +>    after a call to define-method 
> #<<generic> + (1)>        after a call to define-generic

No, currently, some primitive-procedure objects can be "upgraded" to a
primitive-generic object, but that is more of a technicality in the
current implementation.

The best way to look at it is to ignore this and simply think that
some primitive procedures are "generic" and can have methods added.

For example,

  (define-method (+ (x <string>) (y <string>)) (string-append x y))

works well because + is such a generic primitive, while

  (define-method (cdr (x <string>)) (substring x 1))

won't work since cdr can't take on new methods.

The effect of

  (define-generic cdr)

is to create a new generic function object, bind the name `cdr' to it
in the surrounding top-level environment and add the old definition of
cdr as a default method.

The result is different from the + case above in that:

1. + is still the same object while cdr is rebound to a new object in
   the module where the expression occurs.  Note also that this
   implies that adding methods to + has a global effect while adding
   methods to cdr has an effect only in the "local" module and the
   modules to which this binding is exported.

2. + will still perform its "standard" duties (adding numbers) at
   maximum efficiency while cdr will do method dispatch also for
   pairs, being less efficient than the original cdr.

This all is kind of messy right now.

The behaviour of define-generic is inherited from STk.  We should
probably modify it so that `define-generic' doesn't have the magic
behaviour to add the old definition as a default method.

We also want to do something about primitive-generics: We would like
*all* primitives to behave like this, and we don't like the global
effect when adding methods.  After some developments of the current
implementation, we might be able to do these things.  I wouldn't have
added this feature now if it wasn't the case that it is so very
desirable to be able to add methods onto primitives without slowing
them down.

Summary:

If you want consistency, always create your own generic function
objects, using `define-generic'.

If you want speed, add methods directly onto the primitives which can
take them.