
On 10/1/2014 6:02 PM, Carter Schonwald wrote:
This proposal is missing a key ingredient, how to resolve import of two conflicting instances. And I can't imagine any good selection strategy under this scoping scheme. Why should two conflicting in-scope instances be a valid situation? All I'm doing is making instance resolution more similar to other name resolution. Creating a new instance in a scope shadows the instance outside the scope, but multiple instances in the same scope aren't allowed.
Additionally, how this would work in the case of fancier programs that use fundeps and multiparam type classes to construct type level programs is a bit confusing. Would this entail that those programs would have hot swappable parts? What does that mean? You're right, I didn't pay much attention to the fancier stuff we can do. I don't think this will cause trouble, but I'm not qualified to say that with certainty.
One hackage package that would suffer terribly would be the HList one I think. A cursory glance at HList reveals several open type families. I *think* that they can be rewritten to be closed families.
Also I'm not sure what implications this would have for how type inference would work. Having global uniqueness is a wonderful assumption to have, and losing it might result in losing huge swaths of type inference, because suddenly we have 'pick the instance in the nearest scope'.. So how would this notion interact with the instance resolution that happens for overlapping instances? If there's an exact instance that matches the local instance, the local instance shadows it, and overlapping instance inference proceeds as usual.
Some examples:
module Foo where import Bar (Baz) -- With an instance Show (Baz a) instance Show (Baz a) where -- shadows the instance from Bar foo = let instance Show (Baz a) where -- shadows the module instance instance Show (Baz Quz) where -- Does not shadow any instance, OverlappingInstances -- resolution proceeds with the two instances defined in -- the let block
Hope this clarifies things, Gesh