[GHC] #11376: Inconsistent specified type variables among functions and datatypes/classes when using -XTypeApplications
GHC
ghc-devs at haskell.org
Fri Mar 25 20:42:46 UTC 2016
#11376: Inconsistent specified type variables among functions and datatypes/classes
when using -XTypeApplications
-------------------------------------+-------------------------------------
Reporter: RyanGlScott | Owner: goldfire
Type: bug | Status: new
Priority: normal | Milestone:
Component: Compiler (Type | Version: 8.1
checker) | Keywords:
Resolution: | TypeApplications
Operating System: Unknown/Multiple | Architecture:
| Unknown/Multiple
Type of failure: Other | Test Case:
Blocked By: | Blocking:
Related Tickets: | Differential Rev(s):
Wiki Page: |
-------------------------------------+-------------------------------------
@@ -51,0 +51,3 @@
+
+ EDIT: Most of this is fix, as of March 25. But the data family stuff in
+ comment:12 is still outstanding, and we need a test case.
New description:
Originally reported [https://mail.haskell.org/pipermail/ghc-
devs/2016-January/010915.html here]. When applying types via
`-XTypeApplications`, the type/kind that gets instantiated seems to be
different depending on whether you're using functions, datatypes, or
typeclasses.
Here's an example contrasting functions and datatypes:
{{{
$ /opt/ghc/head/bin/ghci
GHCi, version 8.1.20160106: http://www.haskell.org/ghc/ :? for help
λ> :set -fprint-explicit-kinds -XTypeApplications -XTypeInType
λ> data Prox a = Prox
λ> prox :: Prox a; prox = Prox
λ> :t prox
prox :: forall k (a :: k). Prox k a
λ> :t prox @Int
prox @Int :: Prox * Int
λ> :t Prox
Prox :: forall k (a :: k). Prox k a
λ> :t Prox @Int
Prox @Int :: Prox Int a
}}}
This is the core of the problem: with a function, `Int` seems to be
applied to type variable `a`, whereas with data types, `Int` appears to be
applied to the kind variable `k`. This confuses me, since `k` wasn't
specified anywhere in the definition of `Prox`.
Andres Löh also [https://mail.haskell.org/pipermail/ghc-
devs/2016-January/010916.html observed] a similar discrepancy between
functions and typeclasses:
{{{
λ> :set -XScopedTypeVariables
λ> class C a where c :: ()
λ> d :: forall a. C a => (); d = c @_ @a
λ> :t d
d :: forall k (a :: k). C k a => ()
λ> :t d @Int
d @Int :: C * Int => ()
λ> :t c
c :: forall k (a :: k). C k a => ()
λ> :t c @Int
c @Int :: C Int a => ()
λ> :t c @_ @Int
c @_ @Int :: C * Int => ()
}}}
EDIT: See also documentation infelicity in comment:9.
EDIT: Most of this is fix, as of March 25. But the data family stuff in
comment:12 is still outstanding, and we need a test case.
--
Comment (by goldfire):
Replying to [comment:16 simonpj]:
> I think the fact that the context doesn't go away is a bug in visible
type application. Richard?
Instantiation is lazy. There's (currently) no incentive for GHC to solve
that constraint when you say `datatypeName @blah`.
Consider
{{{
foo :: forall a b. Show a => ...
}}}
and `foo @Int`. What type should this have? `forall b. Show Int => ...`
seems the natural choice. The only way to get, say, `forall b. ...`
(solving the constraint) would be to instantiate and regeneralize, but
then we'd get `forall {b}. ...`, which is quite silly.
We could have some logic that looks to see if no specified type variables
are left at the beginning of the type and then instantiate constraints.
But I'm not sure this is a good idea. Seems a bit arbitrary. Always being
lazy seems simpler.
As for the other problems in this ticket: they're mostly fixed now, except
for the data family bit.
--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11376#comment:17>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
More information about the ghc-tickets
mailing list