This is the mail archive of the guile@sourceware.cygnus.com mailing list for the Guile project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: Trouble understanding define (!)


>>>>> "Jost" == Jost Boekemeier <jostobfe@calvados.zrz.TU-Berlin.DE> writes:

Jost> Eric Moore <moore@chem.cmu.edu> writes:
>> Well, I would say that merging two generic functions means creating
>> a generic function with a set of methods that is the union of the
>> methods of the two generics that are being merged.

Jost> Is it the union of methods or the union of all locations (of
Jost> these methods)?  I think it's the union of all locations.

What's the difference?  I'm not talking about method names, but the
actual things located at the location...  there is a one to one and
onto mapping of locations and the things in those locations...

>> It is useful in the case where you want to use the same name in
>> your code (like 'size', 'length', or the now-canonical example
>> 'draw') to access the methods in both of the GF's that you're
>> merging, rather than the more cumbersome graphic-draw vs deck-draw.

Jost> Yes.  Names conflict, locations don't.

So?

>> Can in every case two GF's be merged?  no, of course not, it's only
>> posible where the GF's have the same arity

Jost> Excuse me but what is the arity of a GF?

Oops, my error, must have been mis-remembering something :)

>> Yes, the module system binds names to locations.  So?  How does
>> this solve the problem that some of us would like to bind the name
>> 'draw' (or 'size') to the union of the locations of the tuples
>> [cards draw deck] and [graphics draw triangle]?

Jost> [cards draw deck] and [graphics draw triangle] are different
Jost> because they have

Jost> a) a different specializer (triangle vs. deck).  GOOPS already
Jost> handles this case.

Jost> b) belong to two different modules (cards vs. graphics).  Goops
Jost> can handle this case if you introduce the module as some kind of
Jost> "pseudo specializer" (I referred to it as a "module
Jost> back-pointer" in my other message).

I have no clue what you mean by "pseudo specializer" or "module
back-pointer", and haven't seen anyone else use that terminology.

Ok, I think there's a terminology problem going on here...  

We have generics.  Generics have some set of methods.  when a generic
is applied to some set of arguments, it choses the method that is
"most specialized" to that case....  So what we have is in module M1,
there is a generic G1, at some location, bound to name N1, with
methods m1, m2, m3 (each having their own specializer list, and yes,
location), and in module M2, we have generic G2 (some other location),
bound to N1, with methods m4, m5, m6.  (This is my undserstanding of
how goops currently works, and experimentation seems to agree with
this interpretation, someone correct me if I'm wrong).

We want to be able to write code of the form (N1 ....) where N1 is
bound to a generic function (G3?) with methods (m1-m6).

Jost> Now what about [cards draw line] and [graphics draw line]?  They
Jost> have different locations because they belong to two different
Jost> modules.  The module system only cares about names.  

Only about names, or only about locations, make up your mind :)

Jost> It detects two different locations and if you rename one of them
Jost> to a new name (and/or re-order the import-list), you can access
Jost> both.

Or, what we (or some of us) may want in some cases, involving
generics, is to bind the name to a new generic function whose methods
are the union of the two sets.  

  -Eric

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]