This is the mail archive of the
guile@sourceware.cygnus.com
mailing list for the Guile project.
Re: Trouble understanding define (!)
Eric Moore <moore@chem.cmu.edu> writes:
> 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 :)
Only about locations, sorry. I don't know why I wrote "names" in this
case. Possibly because I wanted to look up a word in my german-english
dictionary ("what's the name of...").
> What's the difference? I'm not talking about method names, but the
> actual things located at the location...
The (new) module system handles this perfectly. Just take a look at
environment update protocol and about feature renaming.
> there is a one to one and onto mapping of locations and the things
> in those locations...
Exactly. And that's why we can always merge two modules (or two GF).
BTW: When I say "merging two modules" I mean that a client module C
imports all features from n other modules and re-exports these
features.
It may be that one symbol name shadows another one, but that case
can be handled later.
> Jost> Yes. Names conflict, locations don't.
>
> So?
You can merge GFs.
> I have no clue what you mean by "pseudo specializer" or "module
> back-pointer", and haven't seen anyone else use that terminology.
How else should I call it. The GF dispatches on its argument types.
We extend this mechanism by requireing that it not only dispatches
on its argument types but also takes its module context into account.
> 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....
Exactly.
> 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).
No. What we have are data modules which map symbols to values
and GF modules which map (lists of) specializers to methods.
> 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).
Yes. But you can't put the GF into the data module itself.
Jost