On Wed, Jul 24, 2013 at 2:57 PM, David Jeske <[email protected]> wrote:
> On Wed, Jul 24, 2013 at 1:48 PM, Jonathan S. Shapiro <[email protected]>wrote: > >> what I'm saying is that *because the selected instance is an orphan*, we >> should instead give this function type as: >> >> sortR :: Ord R ~ TheOrphanedOrdRInstance => R[] -> R[] >> > > That is: this is a procedure that sorts something of type R[] *provided* the >> caller agrees with the choice we made about the orphaned instance >> resolution. We've documented that choice in the interface, and it's up to >> you whether to use it or not. >> > > Why this is necessary or even valuable? > It is necessary to ensure that the caller is getting the overload that they are expecting. Concrete example: if the resolution of Ord in my environment sorts bottom-to-top, but the resolution of Ord in your environment sorts top-to-bottom, that's a significant discrepancy in our assumptions that should be captured at the interface signature. SortR has quite a different * meaning* depending on whether our assumptions are in agreement. If it was valuable to agree on the Ord implementation, presumably we would > be using a version of sort which parameterized the ord-comparator itself. > You are arguing, in effect, that the choice of inlining strategy determines whether something is valuable. If so, that's complete nonsense. Parameterizing the ord-comparator makes sense only if we want to be able to sort in different ways at different times. Knowing what the standard ordering *is* is a matter of understanding the reference behavior of the procedure being called. I had a discussion with Mark Jones about multiple instances at one point. As it happens, Ord was the case I raised. Mark is of the opinion that type class instances are supposed to capture something fundamental about the type, so if you have multiple instantiations at a type you're probably doing something wrong. The problem with this, of course, is that Ord is an excellent counter-example. > > This runs smack into a major common problem in language and runtime >>> design, which is that we overwhelmingly favor the pattern of >>> named-impementation-factory when in most cases >>> conforming-implementation-factory is not only sufficient, but superior. >>> >> >> I haven't heard those two terms before. Would you be kind enough to >> educate me about them? >> > > It turns out my made-up terms were too succinct to be clear. > > I'm referring to the prevalence with which we encourage/allow types and > allocations to be specified by specific instance names, when in most cases > using interface (or type-class) and some form of factory would be superior. > That is, the common way to author a sort function will return a list > implementation decided by the sort function, not by the caller. > Thanks for clarifying. There are many application patterns in which this implementation strategy makes sense, but they come at a significant runtime cost in the form of indirections. For Java or C# that may (or may not) be tolerable and accepted. But that's why those languages aren't viable as systems languages. Jonathan
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
