[GHC] #12466: Typechecker regression: Inaccessible code in a type expected by the context
GHC
ghc-devs at haskell.org
Thu Aug 25 22:09:48 UTC 2016
#12466: Typechecker regression: Inaccessible code in a type expected by the context
-------------------------------------+-------------------------------------
Reporter: RyanGlScott | Owner:
Type: bug | Status: new
Priority: highest | Milestone: 8.0.2
Component: Compiler (Type | Version: 8.1
checker) |
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 simonpj):
I agree with your reasoning, but it's quite painful to implement the
positive/negative distinction (given the way the constraint solver works).
Anything is possible, but this all seems a bit exotic, so I'm inclined to
look for a simple solution.
I think it would be simple to:
* Not complain about inaccessible code in instance methods
Would that do?
Currently GHC tries to do co/contra checking for subsumption checking. If
we just used equality on the LHS of arrow, I think the negative/positive
problem would disappear. Which is an intesting strike in favour of that
approach. That would mean that this would fail:
{{{
f :: (Int -> Int) -> Int
g :: (forall a. a-> a) -> Int
g = f
}}}
On the other hand, with the same signatures
{{{
g x = f x
}}}
would succeed. The current co/contra subsumption is clever, but tricky...
eg every foray into impredicative polymorphism gives up on it. Maybe we
should give up on it now.
Simon
--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12466#comment:26>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
More information about the ghc-tickets
mailing list