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. 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? One hackage package that would suffer terribly would be the HList one I think. 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? On Oct 1, 2014 10:46 AM, "Tom Ellis" < tom-lists-haskell-cafe-2013@jaguarpaw.co.uk> wrote:
On Wed, Oct 01, 2014 at 05:36:49PM +0300, Gesh hseG wrote:
It seems the first part of your proposal just says "Haskellers can no longer expect class instance coherence." As such, this is a drastic change that would require all Haskell programs to be inspected to see if they crucially rely on coherence No. Coherence is preserved, since you always use the unique in-scope dictionary. What *is* lost, however, is global uniqueness, which means that code that assumes that the same dictionary is used for the same type across calls to functions must be modified. Arguably, that code is semantically incorrect to begin with, but that's neither here nor there.
What sort of code is that exactly? I'm aware there are things like `Data.Set` which crucially rely on global uniquess of instances to maintain invariants. Are there any other sorts of functionality where this is needed?
Tom _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe