On Thu, Jul 25, 2013 at 10:19 AM, Jonathan S. Shapiro <[email protected]>wrote:
> 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. > That is definitely not what I'm trying to say. If we're lexically scoped, such as in C#, the author of sortR is making a choice between (a) a lexically scoped/bound function, (b) an instance polymorphic virtual method, or (c) an explicitly passed ord-evaluation function parameter to sortR. My phrase above is referring to option "c", which certainly not making any choice about inlining strategy. The JIT can inline to it's hearts content in a,b, or c. If we're talking about non-JIT, then there is no way to inline a non-lexical comparator into a DLL's sortR anyhow, because it would break the DLL abstraction. In C#, (a) could be an extension method, but since extension methods they are lexically scoped, this is really just a bit of syntax sugar for binding a static ord-comparator into the sortR. ---- Phrased differently, my point was that I don't see how a, b, and c above are in any way insufficient to represent the all possibilities, and in turn, I don't see the need for non-lexically scoped binding of extension-methods/categories/type-classes/mixins what have you. Systems which allow them to be non-lexically scoped are effectively allowing you to "patch an existing implementation", which sounds fun and all, but lands us smack into the instance resolution problem you're pointing out. Wheras the "c" method above eliminates any such confusion, since implementing sortR can be done with an explicit comparator-handler. That comparator can effectively set arbitrary policy about which ord is used, and the JIT can still inline it.
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
