[GHC] #14288: ScopedTypeVariables with nested foralls broken since 8.0.2
GHC
ghc-devs at haskell.org
Mon Oct 2 12:54:23 UTC 2017
#14288: ScopedTypeVariables with nested foralls broken since 8.0.2
-------------------------------------+-------------------------------------
Reporter: MikolajKonarski | Owner: (none)
Type: bug | Status: new
Priority: normal | Milestone:
Component: Compiler (Type | Version: 8.2.1
checker) |
Resolution: | Keywords:
Operating System: Linux | Architecture: x86_64
Type of failure: GHC rejects | (amd64)
valid program | Test Case:
Blocked By: | Blocking:
Related Tickets: | Differential Rev(s):
Wiki Page: |
-------------------------------------+-------------------------------------
Comment (by RyanGlScott):
That being said, I'm sympathetic to the desire to have a consistent,
predictable way to determine when exactly a `forall`'d variable from a
type signature is brought into scope, so I don't want to hammer too hard
on this point unless goldfire is on board too.
I'm sure goldfire has a convincing example in comment:8, but I'm having
trouble understanding what makes it convincing. I'm grasping at straws
here, but is the concern that something like this (with invisible patterns
written out explicitly) should "intuitively" typecheck:
{{{#!hs
f1 :: forall a. a -> Int -> forall b. (a, b)
f1 @a x i @b = const (x, undefined :: b) i
}}}
But in the eta-reduced version:
{{{#!hs
f2 :: forall a. a -> Int -> forall b. (a, b)
f2 @a x = const (x, undefined :: b {-?-})
}}}
`b` isn't bound by an invisible pattern? Or is there some other reason why
this should be considered "strange"?
--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14288#comment:13>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
More information about the ghc-tickets
mailing list