Re: Trouble understanding define (!)

[Michael Livshin <mlivshin at bigfoot dot com>]

Marius Vollmer <mvo@zagadka.ping.de> writes:

> I still don't think generic
> functions should be handled any different by the module system.  Any
> move to put special behaviour into the module system for certain kinds
> of objects must be avoided.  The (imagined) loss of convenience is
> not an argument at all.

I agree in principle, though I disagree that the loss of convenience
is imagined.  generic functions are *not* ordinary objects, they
themselves are namespaces, and this property makes it desirable for
them to have simple, likely-to-conflict names.  ditto slots.

what the above means is that we shouldn't worry about merging generics 
by name, provided that we (the module system/linker/whatever) know
*for sure* that we can.

since any merging is done (and I believe that it needs to be done) by
the module system, it's worthwhile to try to keep the merging
functionality well-defined, while having the module system know as
little as possible about GOOPS or types in general.

one approach (somewhat ugly but relatively simple) would be to let
users declare some exported names to be mergeable.  the module system
will merge the names if the objects they name are eqv?.  the ugliness
of this approach is that it isn't generally checkable at compile time,
only at link time.

this places the corresponding obligation on GOOPS which is:

if
  0. GF0 and GF1 are generic functions.
  1. (eq? (generic-name GF0) (generic-name GF1))
  2. (eq? (class-of GF0) (class-of GF1))
then
  (eq? GF0 GF1)

IMO that's the only possibility to have well-defined merging without
making the module system explicitly aware of GOOPS and without the
need for the module system to have MOP-style extensibility.  not that
MOP-style extensibility would be a bad thing, hmmm...

> - Marius

--mike, being noisy again.

-- 
Paranoid schizophrenics outnumber their enemies at least two to one.