David: Either I'm missing your point or you're missing mine (or both). In spite of what Keaane just asserted over on LtU, type classes cannot be implemented using C++ classes.... Oh. I see the disconnect now.
There is a Haskell restriction that TC instances must appear either (a) in the compilation unit where the TC is defined or (b) in the compilation unit where the type is defined. This is an <em>ad hoc</em> restriction, and it's actually kind of ugly, but I agree that if we assume this restriction then the type class pattern can mostly be done in C++, and that your parametric instantiation approach is interesting. One of the real beauties of type classes is that a third party (i.e. someone unable to change either of those compilation units) can instantiate a relation that neither the TC author nor the type author considered. The <em>ad hoc</em> rule defeats this. In short, as we've discussed here before, the Haskell rules for instance resolution are incompatible with programming at scale. Things get truly unpleasant when you admit the requirement for multivariable classes and overlapping instances. But an awful lot of this can be made to go away completely if type class instances are named in the same way that every other definition in the world is given a name. We could then use a construct like: using <instance name> do with the intended meaning that the named instance is brought into the instance resolution environment, overriding any other resolution at that type relation. I've been noodling on this for quite a while, and I think I need to go back and re-read the Oliveira paper (Type Classes as Objects and Implicits). I'm wondering if I haven't just re-invented what he did in a way that (finally) makes sense to me. shap
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
