#12240: Common Sense for Type Classes -------------------------------------+------------------------------------- Reporter: Mathnerd314 | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Mathnerd314):
This is only "common sense" if you discard the open world assumption
I have not seen hide nor hair of this fabled "open world assumption", except a small section in Real World Haskell:
We can add new instances anywhere; they are not confined to the module where we define a typeclass. This feature of the typeclass system is referred to as its open world assumption.
This refers to the ''declaration'' of instances, not instance resolution. If the proposal was to remove orphan instances, I would see the merit of bringing this up, but it does not seem relevant here.
(or accept incoherence),
Consider this: {{{#!hs -- in A.hs class A a where f :: a -> Int -- in B.hs instance A Int where f _ = 1 foo = f (0 :: Int) -- in C.hs instance A Int where f _ = 2 bar = f (0 :: Int) -- in Main.hs main = print (foo,bar) -- (1,2) }}} It is a blatant violation of the Haskell Report ("A type may not be declared as an instance of a particular class more than once in the program."), yet it compiles in GHC with no extensions. Meanwhile, all I want to do is relax instantiation from "a single instance matches and no other instance unifies" to "a single instance unifies and no other instance unifies". This is only interesting in limited situations, such as the example in comment:4, and leaves all Haskell 98 instances unchanged. I do not see how it adds any incoherence, because in both rules only a single instance is allowed.
I don't claim to have any say in whether an implementation will or will not be accepted, but bear in mind that new features have an ongoing cost, even if guarded by language flags. Feel free to work on it if you like, but seeking wider input first might be a good idea to avoid working on something that is ultimately not merged.
I have posted on Reddit, IRC, and this bugtracker; what's left besides Phabricator? -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/12240#comment:7 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler