[GHC] #12976: GHCi displays the kinds of unboxed tuples incorrectly

#12976: GHCi displays the kinds of unboxed tuples incorrectly -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.0.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Other Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- This can be reproduced in GHCi 8.0.2 or HEAD. First, a preamble: {{{ $ inplace/bin/ghc-stage2 --interactive GHCi, version 8.1.20161208: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci λ> :set -fprint-explicit-runtime-reps -fprint-explicit-kinds -fprint- explicit-foralls -XUnboxedTuples -XTemplateHaskell -XMagicHash λ> :m + GHC.Exts Language.Haskell.TH Language.Haskell.TH.Lib Language.Haskell.TH.Syntax }}} The kind of `(#,#)` is reported correctly: {{{ (#,#) :: forall (k0 :: RuntimeRep) (k1 :: RuntimeRep). TYPE k0 -> TYPE k1 -> TYPE 'UnboxedTupleRep }}} But when you give it an argument, it seems to default `TYPE k1` to `*` for some reason! {{{ λ> :k (#,#) Int# (#,#) Int# :: * -> TYPE 'UnboxedTupleRep }}} This is a blatant lie, as this kind-checks: {{{ λ> :k (#,#) Int# Int# (#,#) Int# Int# :: TYPE 'UnboxedTupleRep }}} The effect is even more noticeable when you throw `TemplateHaskell` into the mix: {{{ λ> :k $(unboxedTupleT 2) $(unboxedTupleT 2) :: * -> * -> TYPE 'UnboxedTupleRep λ> :k $(unboxedTupleT 2) Int# $(unboxedTupleT 2) Int# :: * -> TYPE 'UnboxedTupleRep λ> :k $(conT (unboxedTupleTypeName 2)) $(conT (unboxedTupleTypeName 2)) :: * -> * -> TYPE 'UnboxedTupleRep λ> :k $(conT (unboxedTupleTypeName 2)) Int# $(conT (unboxedTupleTypeName 2)) Int# :: * -> TYPE 'UnboxedTupleRep }}} All of these kinds should be reporting the `RuntimeRep`s that GHC is //actually// using under the hood. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/12976 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#12976: GHCi displays the kinds of unboxed tuples incorrectly -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.0.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): This also affects unboxed sums, unsurprisingly: {{{ λ> :set -fprint-explicit-runtime-reps -fprint-explicit-kinds -fprint- explicit-foralls -XUnboxedSums -XTemplateHaskell -XMagicHash λ> :m + GHC.Exts Language.Haskell.TH Language.Haskell.TH.Lib Language.Haskell.TH.Syntax λ> :k $(unboxedSumT 2) $(unboxedSumT 2) :: * -> * -> TYPE 'UnboxedSumRep λ> :k $(unboxedSumT 2) Int# $(unboxedSumT 2) Int# :: * -> TYPE 'UnboxedSumRep }}} -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/12976#comment:1 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#12976: GHCi displays the kinds of unboxed tuples incorrectly -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.0.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): I say that this behavior is correct. As you report, the kind of `(#,#)` is `forall (r1 :: RuntimeRep) (r2 :: RuntimeRep). TYPE r1 -> TYPE r2 -> TYPE 'UnboxedTupleRep`. So once you provide a type argument (`(#,#) Int#`), then GHC must supply both `RuntimeRep` arguments. The second one defaults to `PtrRepLifted`. At the term level, we can then regeneralize, but you can't do that in types because there is no type-level lambda. An alternative to the current design would be to have {{{ (#,#) :: forall (r1 :: RuntimeRep). TYPE r1 -> forall (r2 :: RuntimeRep). TYPE r2 -> TYPE 'UnboxedTupleRep` }}} This is an improvement from a technical standpoint, but I wager humans would be even more confused here. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/12976#comment:2 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#12976: GHCi displays the kinds of unboxed tuples incorrectly -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.0.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Replying to [comment:2 goldfire]:
I say that this behavior is correct. As you report, the kind of `(#,#)` is `forall (r1 :: RuntimeRep) (r2 :: RuntimeRep). TYPE r1 -> TYPE r2 -> TYPE 'UnboxedTupleRep`. So once you provide a type argument (`(#,#) Int#`), then GHC must supply both `RuntimeRep` arguments. The second one defaults to `PtrRepLifted`.
Do you mind explaining your reasoning for in a little more detail? Because it's not cleat at all to me why making `r1 ~ 'IntRep` would cause `r2` to default to `PtrRepLifted`. In particular, I would have expected: {{{#!hs (#,#) Int# :: forall (r2 :: RuntimeRep). TYPE r2 -> TYPE 'UnboxedTupleRep }}} Why would it default with an argument, but not without arguments? Also, do you know what's going on with: {{{ λ> :k $(unboxedTupleT 2) $(unboxedTupleT 2) :: * -> * -> TYPE 'UnboxedTupleRep }}} Is Template Haskell causing some defaulting behavior that I'm not aware of? -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/12976#comment:3 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#12976: GHCi displays the kinds of unboxed tuples incorrectly -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.0.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): The `(#,#)` type constructor takes 4 arguments, `(r1 :: RuntimeRep)`, `(r2 :: RuntimeRep)`, `(a :: TYPE r1)`, and `(b :: TYPE r2)`. Because there is no type-level lambda, it ''must'' take these arguments in order. So we cannot supply the third argument (the `Int#` in the `(#,#) Int#` case) without supplying the second. Initially, this second argument is a unification variable, but this gets defaulted to `PtrRepLifted` before printing. Does that explain it? And I have no idea what's going on with TH. That looks like a separate ticket to me. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/12976#comment:4 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

The `(#,#)` type constructor takes 4 arguments, `(r1 :: RuntimeRep)`, `(r2 :: RuntimeRep)`, `(a :: TYPE r1)`, and `(b :: TYPE r2)`. Because
#12976: GHCi displays the kinds of unboxed tuples incorrectly -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: GHCi | Version: 8.0.2 Resolution: invalid | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: #12985 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => closed * resolution: => invalid * related: => #12985 Comment: Replying to [comment:4 goldfire]: there is no type-level lambda, it ''must'' take these arguments in order. So we cannot supply the third argument (the `Int#` in the `(#,#) Int#` case) without supplying the second. Initially, this second argument is a unification variable, but this gets defaulted to `PtrRepLifted` before printing.
Does that explain it?
Now it makes sense! Thanks. I'm a bit saddened that we apparently don't have a way to make `(#,#) Int# :: forall (r2 :: RuntimeRep). TYPE r2 -> TYPE 'UnboxedTupleRep`, but maybe that problem will be fixed once we have visible kind applications (#12045).
And I have no idea what's going on with TH. That looks like a separate ticket to me.
OK. I've opened #12985 specifically to address that issue. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/12976#comment:5 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#12976: GHCi displays the kinds of unboxed tuples incorrectly -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: GHCi | Version: 8.0.2 Resolution: invalid | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: #12985 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): No. Visible kind applications won't help. We need to either have: 1. Type-level lambdas, or 2. Declare `(#,#) :: forall r1. TYPE r1 -> forall r2. TYPE r2 -> TYPE 'UnboxedTupleRep`. (2) is obviously much much easier. But I'm worried about folks getting confused at the non-prenex type. On the other hand, if someone is wading in these waters, they had better know how to swim already... -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/12976#comment:6 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
participants (1)
-
GHC