John Peterson writes:
OK - let's get operational!
My man! You know, I *like* formal methods and equational reasoning; I
just can't get my mind to "do the right thing" in all cases. When
reasoning about correctness, I do OK; however, type checking and the
like inevitably find me descending in to a mass of operational, even
anthropomorphic arguments. Ah, well.
With visions of Olivia Newton-John dancing through my head.....
Dave's choices are:
1) Build the resolution dictionary using the context of Module Two
(the point of declaration)
2) Build the resolution dictionary using the context of Module Three
(the point of use).
While Dave is on the right track, neither of these choices really
distinguishes the act of building a dictionary from referring to a
dictionary.
Accepted, and this is a useful distinction to make. (skipping....)
With the type signature added, module Two instantiates the overloaded
argument to trouble and the dictionary available in module Two is
used. Th this case trouble does NOT carry a dictionary parameter to
be instantiated by the call in Three.
Understood; however, without the type signature, there is still the
question of the dictionary contents. Under choice (1), the dictionary
contents reflect the instance in module two; under choice 2), that of
module three. One interesting thing about choice (1) is that a
sufficiently smart compiler (there goes that anthropomorphic reasoning
again) might optimize the parameter away based upon an analysis that
states there is only one instance visible at the site of the
declaration of trouble. This is, of course, impossible with choice
(2). Another implication of choice (1) is that more information must
be passed across module boundries; not just the type of the inherited
functions, but their "instance context" (if I may butcher the English
language) as well.
We are cetainly at the point that Phil feared, with the following
change: the point at which the dictionary context is used to build the
dictionary changes the meaning of the program. I don't know if this
is any more paletable to anyone else; I have little problem with it,
and do not think of it as a disaster. Certainly the impliciation that
adding an extra type information to the program changes its meaning
seems not to hold under choice (1); I agree that *this* would be a
disaster. Adding a type declaration that hides another one *does*
change the meaning of a program; however, this is just an implication
of the hiding semantics in general that we must live with in a scoped
name space. We do get other nastinesses, such as the seemingly
paradoxical type error I mentioned in my last message.
Dave Barton
[EMAIL PROTECTED]
