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
