On Fri, Jul 26, 2013 at 11:13 AM, David Jeske <[email protected]> wrote:
> 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. > Or dynamically instantiated code that inlines the instance. My point is only that the choice of which procedure gets invoked is not a reflection of importance or value. > 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. > The use case for non-lexically-scoped resolution is the one where we have A.Trait, B.Type, and C.TraitInstance developed by non-cooperating developers in different organizations. I gave an example of a novel stream trait in an earlier email. The alternative to non-lexically-scoped resolution in this situation is to require all instances to be bound at module import. That's essentially how ML solves this, and Bob Harper has pointed out that it's expressively equivalent to type classes. It's just not very attractive. > 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. > Nobody is arguing in opposition to explicitly named and passed instances. That is orthogonal to the issue at hand, which is automatically resolved * implicit* instances. The two serve different purposes and roles in the language. Jonathan
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
