Xerox PARC had a wonderful expression: "the moose under the rug",
which is to say: the big issue that nobody wants to talk about.
In BitC, the moose under the rug is method resolution. The problem is
to choose the method instance to use unambiguously. The rule today is
that it is a link-time failure if two type class instances exist for
two [sets of] types where one subsumes the other. That is: we disallow
any possible ambiguity.
There are two problems with this policy:
1. It is unenforceable. Developers acting in non-communicating
organizations cannot
possibly avoid creating conflicting instances.
2. It precludes specialization. For example, an instance over (list
char) might use a different
algorithm than an instance over (list 'a).
So the problem in the large is separate compilation, in the sense of
"separated by an air gap". If we want to support modules written by
truly unrelated development groups, we need a way to survive colliding
instances. The only way that I can really see to do that is by using
lexical scoping, but lexical scoping in the presence of polymorphism
is a very strange thing.
The issue is that you have a call to f() that in turn calls g() in
some other module. Both modules have an instance in scope for (EXAMPLE
(list char)), but they are not the same instance.
The question is: which instance should be used in the compilation of
g()? That is: which lexical environment should be used to decide what
instance to use? There is truly no right answer to this.
Unfortunately, I suspect the answer is "we should use the instance
from the same environment that caused the type variable to be
concretized". This is not always right, but it is clear and
unambiguous. Unfortunately, this answer tends to preclude dynamic
libraries, because the "instance context" doesn't necessarily cross
the import boundary.
I suspect this is one of these cases where the price of separate
compilation is living with occasionally strange (but still safe)
outcomes, but I would be really interested to hear ideas on what to do
and how to specify behavior on this issue.
This, by the way, is the one remaining "define the language" issue in
BitC today that I consider unresolved.
shap
_______________________________________________
bitc-dev mailing list
[email protected]
http://www.coyotos.org/mailman/listinfo/bitc-dev
