Re: Trouble understanding define (!)

[Neil Jerram <neil at ossau dot uklinux dot net>]

My gut reaction is to dislike Mikael's magic module proposal for
generics, 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!

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.

However, I'm worried, even after hiking back through the email trail,
that I may have lost sight of the problems that we are trying to
address.  Here's my attempt at a resume, followed, just to be awkward
:-), by a completely different suggestion for part of the solution.

When working with a generic, whose name might be the same as that of
an imported generic, there seem to be 3 possible behaviours, all of
which are useful in different circumstances.

1. You want the application generic to have nothing whatsoever to do
   with the imported one.  (The names are coincidental.)

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.

It's easy to implement all of these behaviours using the various
define*generic ideas that we've been discussing.  No problem so far.

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?

If this is a significant problem, it isn't specific to generic
functions.  It affects any module that includes some kind of
"registration" interface which allows the internal behaviour of the
module to be changed.  (A non-GOOPS example of this is the Emacs-style
interactive.scm code that I wrote -
http://www.ossau.uklinux.net/interactive.scm, which allows
applications to register I/O handlers for type characters that can
appear in interactive specification strings.)

To address this problem I think we need the module system to support
'shared and 'non-shared importing of other modules, and to implement
copy-on-write semantics for 'non-shared imports.  (Something for the
module wish list?)

Regards,

   Neil (probably way out of sync, but then that's why I'm writing...)