On Fri, Jul 26, 2013 at 12:15 PM, Jonathan S. Shapiro <[email protected]>wrote:
> 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. > I see. I couldn't find the stream example, but I can imagine it. My personal term for this is "bottom-up code reuse". That is, repurposing a module by handing it a different set of "bottom level" bindings/operators to talk to. This happens whether the bindings are allegedly bound to an instance (such as a trait), or whether the bindings are simply other DLL imports of that module which you wish to override. > 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. > This sounds the same as lexical scoping and dynamic binding (aka DLL/SO)... and the way C solves this. Any C function is lexically scoped in, but at run-time link you can override any particular (non-inlined) functional binding. The same is true in .NET/JVM, if by no other means than just supplying an alternative implementation of the bound DLL. What makes this unattractive? It this a granularity issue? Convenience? As far as I can see, the suggestion ( sortR :: Ord R = OrphanedInstanceForR => R[] -> R[] ), is effectively trying to admit a more granular per-function module import dependency, as opposed to a per-module import module dependency. However, different parts of the module with sortR may depend on it using the same OrdR, which means it's safer to remind the OrdR import at the module/assembly level --- unless we have a safe way to identify that cross-dependency. Certainly from a convenience standpoint, we could use in-language mechanisms to override module-important dependencies. Last time I did something like this it was clunky OS-dependent muckery.
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
