The discussion about type classes has wandered off the rails a little bit,
and it's partly my fault. At a high level, there are two issues on the
table:
1. The instance coherence problem
2. The mechanics of instantiation and its interaction with late type
binding
The first one is the one that is important, because it's the one that
reveals flaws in the conceptual model. The second one is mainly a problem
because it pushes us into building a whole new compile tool chain that we
would much prefer not to build. The visibly novel aspect of this tool chain
is its support for continuous compilation.
The reason that the mechanics issues call out for attention is something I
said before: in C++, 5% of the source code is template code [and therefore
in need of instantiation]. In BitC, probably 95% of the code is parametric
[and therefore in need of instantiation]. So a thing that in C++ is merely
very annoying becomes a big deal in a language like BitC. It becomes
supercritical when we start talking about *ad hoc* polymorphism at ground
types.
But here's an unpleasant observation (because it means we are missing
something obvious):
*C++ Templates Work, Type Classes Don't. Why?*
*
*
All of the instantiation issues that I have raised for type classes have a
dual in the template world. The difference is that in the world of C++
templates, we see two differences:
1. All of the code needed to perform instantiation must be lexically
visible at the point of association.
2. We are not doing instantiation at ground operators and types - these
are built in to the language.
I've given all the necessary hints, but I've never actually come out and
said it: BitC actually imposes the second property as well. This is true
because (1) Arith('a) and friends are defined in the preamble, and (2) the
instantiations of Arith('a) over ground types is defined in the preamble.
Similarly for Ord('a) and Eq('a), which covers most of the very low-level
issues that concern us. So the "fix" is embedded in the definition of the
preamble rather than in the specification of the language.
So I'm sneakier than most of you give me credit for. :-)
So the real problem in BitC is tied up in [1]. In C++, all visibility is
regulated by lexical contour. In BitC, it isn't. Something along the lines
of named instance arguments is clearly the answer, but all of the proposals
that I have seen to date retain anonymous instances, so they don't
ultimately solve the instance coherence problem.
Please note that in [1] I wrote "code" rather than "source code". In C++,
the requirement is for source code, but C# clearly demonstrates that a
high-level intermediate form can be used. I personally prefer the
high-level intermediate form approach.
There is a third, somewhat more subtle issue: C++ requires fewer
specializations, because certain important conversions are implicit. In
particular, all integer ops silently convert up/down to "int". On the one
hand this introduces complexity: the rules about template expansion vs
reuse are confusing. On the other, it reduces the total number of
expansions that need to be done, thereby reducing library sizes.
shap
_______________________________________________
bitc-dev mailing list
[email protected]
http://www.coyotos.org/mailman/listinfo/bitc-dev
