Re: Trouble understanding define (!)

[Mikael Djurfeldt <mdj at mdj dot nada dot kth dot se>]

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

> My gut reaction is to dislike Mikael's magic module proposal for
> generics,

Me too, actually.  :)

> but on the other hand I quite like the way that it provides
> a home for problems like "draw", where one big, vague concept
> incorporates a collection of more precise subconcepts, such that it's
> reasonable, but at the same time confusing, for them all to have the
> same name!

It's actually not vague, but the fact the people perceive it in that
way is a bad sign anyway.  My description was technical, but the
behaviour is simply:

1. As long as you're using different names, each GF behaves as any
   other name-object binding handled by the module system.

2. But, when using the same name, assume that it was *intentional* and
   share methods.  (But I proposed that errors should automatically be
   generated when merging GFs in a way that would alter behaviour.)

The additional exception that GF objects are unique for each module
was introduced in order to preserve the connection method-module so
that the right group of metods can be removed easily again when
unusing other modules.

> If we go with this, then I also think we should have Michael's
> proposal, that (define NAME (make-generic ...)) creates a generic that
> is local and does not belong to the magic module.

Yes, but as Marius, I think

  (define-generic NAME OPTION ...)

should mean

  (define NAME (make-generic #:name NAME OPTION ...))

Generally, I'm very sensitive to the kind of criticism (or view) that
Marius provided.

> 2. You want application-defined methods for the generic to directly
>    affect the imported generic in its own module context, so that
>    things like the MOP work.
> 
> 3. You want to use the methods of the imported generic and add
>    application-defined methods to it, but without affecting the
>    internal behaviour of the imported module.

[...]

> A problem arises, however, when more than one application runs in the
> same Guile process, and different applications mix behaviours 2 and 3
> for the same generic function.  What can then happen is that
> application A's behaviour is unexpectedly modified because application
> B added a method to a generic using behaviour 2.
> 
> To my mind, this is the main problem, but I have a strong feeling that
> I'm out of sync with everyone else on this!  What other key problems
> are there?

This problem is actually solved by adhering to the principles in
Kiczales' paper, and doesn't need any new functionality in the module
system.  (We might be able to add support for automatic assertion that
some of his rules are followed.)

My main problem is that I'd like to use simple names for ordinary GFs
and accessors without having to bother about renaming them.

For example, it's very common to want to have a GF/accessor `length'.
It may be provided by both the list module and the vector module.  In
this case, `length' actually refers to the same concept, and one could
argue that <list> and <vector> should inherit the common base class
<sequence> and that it's the job of the sequence module to export
`length', so, in this case there is a natural solution.

But imagine now that the two `length' is only vaguely related (like in
the graphics module (length of a line) and the list module (length of
a list)).

I dislike having to name `length' `graphics:length' and `list:length'
when I know that these two bundles of methods could work well together
in a GF `length'.

This problem especially often arises for accessors.


Actually, now it strikes me, maybe this could simply be solved by
changing `make-accessor' so that it always returns a unique object
when given a unique name.

With this solution, the renaming problem would go away for accessors,
since it doesn't matter when one accessor name shadows another on the
module use-list...  :-)

But, considering earlier parts of this discussion, we still want to be
able to have local accessors, which means that the new behaviour
should only be implemented by `make-public-accessor' which is invoked
when using the slot option #:public-accessor.

(Note the quirk, though: When accessor `a' is exported from module A
to module B, and a "different" accessor `a' is exported from module C
to module D, `a' will in fact be the same object in all four modules
although this was not indicated by the module import specs...)

With this change, I'd be happy with the current behaviour, except that
we should maybe introduce `define-extended-generic' also, for use when
people are emulating other object systems.

OK folks, does this seem OK?