On the soundness issue, I think I now understand it a bit more. I don't think there is a problem with type-families, nor with the way Haskell handles associated types (which is as a type function of the type-class parameters).
It comes down to this, the associated types of instances with the same type parameters must be the same. So the instances must be coherent as far as the type system is concerned, but can have different values (function definitions with the same parametric type signatures) However I think it is a good idea to separate compile time from runtime. Type classes can be entirely inlined at compile time except two cases I am aware of, polymorphic recursion, and existential types. Polymorphic recursion is somewhat problematic, so leaving it to one side, I would like to treat all type-classes like C++ templates, and existentials as virtual functions, where you define a base class for the type-class, and then override for each instance. This means runtime polymorphism is introduced only where intended by the programmer, all types can be unboxed as all polymorphism is static apart from that introduced by an existential, which is equivalent to an abstract base class with one layer of subclasses. Keean. On 7 Jan 2015 23:28, "Jonathan S. Shapiro" <[email protected]> wrote: > On Wed, Jan 7, 2015 at 1:29 PM, Geoffrey Irving <[email protected]> wrote: > >> On Wed, Jan 7, 2015 at 1:04 PM, Jonathan S. Shapiro <[email protected]> >> wrote: >> > The value of instance coherence, from a compilation perspective, isn't >> all >> > that great when taken by itself. The value of witnessed instance >> coherence >> > (that is: (a) the instance is in scope, and (b) any failure of >> coherence can >> > be detected and diagnosed during static unit-at-time compilation) is >> high. >> > Witnessed coherence (at least for defaulted type classes) justifies us >> in >> > inlining the instance methods aggressively, which in turn allows us to >> drop >> > the class constraint. This inlining can be done without having to chase >> a >> > passed procedure pointer through a call chain in the whole-program way. >> >> Right, witnessed instance coherence is important, but doesn't pose any >> of the scale or separate compilation problems that instance coherence >> does. >> > > Not so. Keean is suggesting that the *absence* of coherence leads to type > soundness concerns. I'm not convinced of that, and I'll take it up in a > separate reply. > > What I'm suggesting for now is that in order to be considered as a default > (implicit) resolution, the instance must be a *witnessably* coherent > instance. If the contours don't guarantee that violations of coherence are > witnessed, then the instance is presumptively *not* coherent, and can > only be used in explicit instance resolutions. > > >> > Actually, you can specialize "sort" for any instance of Ord (coherent or >> > otherwise). It's just partial evaluation. You just have to make sure >> that >> > you remember which specialization you did so that you call the intended >> > specialization later. That can be done by encoding any non-default >> > resolutions into the name mangling of the specialized sort function. >> >> Yep, that's saying the same thing: if we don't require instance >> coherence, sortBy doesn't need to exist at all. Fewer functions is >> good. > > > Fewer functions is good, and the sort/sortBy distinction is particularly > distasteful (aesthetically). > > > shap > > _______________________________________________ > bitc-dev mailing list > [email protected] > http://www.coyotos.org/mailman/listinfo/bitc-dev > >
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
