Re: Trouble understanding define (!)

[Michael Livshin <mlivshin at bigfoot dot com>]

Mikael Djurfeldt <mdj@mdj.nada.kth.se> writes:

> The problem, as I see it, is that it is uncomfortable for the user to
> manage the question of which GFs of the same name really should be
> represented as one GF.

indeed.

> To summarize: Maybe we actually want to merge GFs which get
> "connected" through the module system, but not in other cases.
> 
> Suggested new solution:
> 
>   GFs in different modules are distinct objects, but GFs whose names
>   "meet" through the module system share methods."

[ description snipped ]

> Essentially, it's a percolation process where the imported bindings
> are holes.  :)
> 
> This suggestion is admittedly a bit weird, but it will both be
> efficient (if the right datastructure is selected) and very
> practical.

three things:

1. this is, essentially, a re-formulation of the "there is one global
   module for all generics" thing.

2. intead of just arranging for such magic module to exist, we make
   the module system deal not only with value visibility, but also
   with values themselves (in case of generics).  so generics are
   magic anyway, but there's more hair in the module system.

3. what happens when you merge two (or more) generics with different
   base arity?

4. what happens when you merge two (or more) generics of different
   metaclasses, with different methods for
   `compute-applicable-methods'?

note that points 3. and 4. are problematic for my approach, too...

did I miss anything?

--mike

-- 
Non-determinism means never having to say you're wrong.