GHC issueshttps://gitlab.haskell.org/ghc/ghc/-/issues2021-09-28T10:28:48Zhttps://gitlab.haskell.org/ghc/ghc/-/issues/17360Panic while printing levity polymorphism error2021-09-28T10:28:48ZmniipPanic while printing levity polymorphism error## Program
```haskell
{-# LANGUAGE UnliftedNewtypes #-}
{-# LANGUAGE ExplicitForAll #-}
{-# LANGUAGE PolyKinds #-} ...## Program
```haskell
{-# LANGUAGE UnliftedNewtypes #-}
{-# LANGUAGE ExplicitForAll #-}
{-# LANGUAGE PolyKinds #-}
import GHC.Exts
newtype Id (a :: TYPE r) = Id a
foo :: forall r (a :: TYPE r). Id a -> Id a
foo x = x
```
## Output
```
ghc-stage2: panic! (the 'impossible' happened)
(GHC version 8.9.0.20191008:
isUnliftedType
Id a_a1g7 :: TYPE r_a1g6
Call stack:
CallStack (from HasCallStack):
callStackDoc, called at compiler/utils/Outputable.hs:1179:37 in ghc:Outputable
pprPanic, called at compiler/types/Type.hs:2229:10 in ghc:Type
```
## Expected output
```
A levity-polymorphic type is not allowed here:
Type: Id a
Kind: TYPE r
In the type of binder ‘x’
```
The issue seems to be specific to binders of types that are unlifted newtypes.
## Environment
GHC HEAD8.10.1https://gitlab.haskell.org/ghc/ghc/-/issues/16829Error messages could suggest UnliftedNewtypes in more situations2019-06-23T23:21:41ZRyan ScottError messages could suggest UnliftedNewtypes in more situationsConsider the following program:
```hs
{-# LANGUAGE DataKinds #-}
{-# LANGUAGE GADTs #-}
{-# LANGUAGE MagicHash #-}
{-# LANGUAGE TypeFamilies #-}
module Bug where
import GHC.Exts
newtype T :: TYPE IntRep where
MkT :: Int# -> T
```
T...Consider the following program:
```hs
{-# LANGUAGE DataKinds #-}
{-# LANGUAGE GADTs #-}
{-# LANGUAGE MagicHash #-}
{-# LANGUAGE TypeFamilies #-}
module Bug where
import GHC.Exts
newtype T :: TYPE IntRep where
MkT :: Int# -> T
```
This fails to compile with the following message:
```
GHCi, version 8.9.0.20190614: https://www.haskell.org/ghc/ :? for help
Loaded GHCi configuration from /home/rgscott/.ghci
[1 of 1] Compiling Bug ( Bug.hs, interpreted )
Bug.hs:9:1: error:
• Kind signature on data type declaration has non-* return kind
TYPE 'IntRep
• In the newtype declaration for ‘T’
|
9 | newtype T :: TYPE IntRep where
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^...
```
It took me a while before I realized what was wrong: I had simply forgotten to enable `UnliftedNewtypes`. I would have been spared some frustration if only GHC had just suggested "`Perhaps you intended to use UnliftedNewtypes`", as it usually does whenever one tries to use a feature that is gated on some language extension. This shouldn't be too difficult to arrange.8.10.1Ryan ScottRyan Scotthttps://gitlab.haskell.org/ghc/ghc/-/issues/16828Newtype instance typechecks normally, but fails to typecheck when UnliftedNew...2019-07-12T07:47:47ZRyan ScottNewtype instance typechecks normally, but fails to typecheck when UnliftedNewtypes is enabledThis perfectly ordinary `newtype instance` compiles:
```hs
{-# LANGUAGE GADTs #-}
{-# LANGUAGE TypeFamilies #-}
-- {-# LANGUAGE UnliftedNewtypes #-}
module Bug where
import Data.Kind
data family Foo :: Type -> Type
newtype instance Fo...This perfectly ordinary `newtype instance` compiles:
```hs
{-# LANGUAGE GADTs #-}
{-# LANGUAGE TypeFamilies #-}
-- {-# LANGUAGE UnliftedNewtypes #-}
module Bug where
import Data.Kind
data family Foo :: Type -> Type
newtype instance Foo :: Type -> Type where
MkFoo :: a -> Foo a
```
However, if you uncomment the `{-# LANGUAGE UnliftedNewtypes #-}` line, then it fails to compile!
```
GHCi, version 8.9.0.20190614: https://www.haskell.org/ghc/ :? for help
Loaded GHCi configuration from /home/rgscott/.ghci
[1 of 1] Compiling Bug ( Bug.hs, interpreted )
Bug.hs:10:3: error:
• Expected kind ‘* -> *’, but ‘a’ has kind ‘*’
• In the definition of data constructor ‘MkFoo’
In the newtype instance declaration for ‘Foo’
|
10 | MkFoo :: a -> Foo a
| ^^^^^^^^^^^^^^^^^^^
```8.10.1https://gitlab.haskell.org/ghc/ghc/-/issues/16827Data family declarations don't adhere to the UnliftedNewtypes spec2019-06-23T23:21:41ZRyan ScottData family declarations don't adhere to the UnliftedNewtypes specAccording to the [text of the `UnliftedNewtypes` proposal](https://github.com/ghc-proposals/ghc-proposals/blob/42dba0035aca002d70b0bf2c04c314e293dfda6a/proposals/0013-unlifted-newtypes.rst#effects-and-interactions):
> Data Families: Dat...According to the [text of the `UnliftedNewtypes` proposal](https://github.com/ghc-proposals/ghc-proposals/blob/42dba0035aca002d70b0bf2c04c314e293dfda6a/proposals/0013-unlifted-newtypes.rst#effects-and-interactions):
> Data Families: Data families currently do not allow unlifted return kinds. This means that the following is rejected by the compiler:
>
> ```hs
> data family Foo (a :: Type) :: TYPE 'IntRep
> ```
>
> Under this proposal, this restriction would be lifted, not only in modules where `UnliftedTuples` [_sic_] is enabled, but everywhere. Although defining the data families itself would not require the extension, defining instances would.
(I'm pretty sure that should say `UnliftedNewtypes`, not `UnliftedTuples`. I'll assume as much from here on.)
Despite the spec's claim that this restriction would be lifted "everywhere", GHC currently does not permit `Foo` without first enabling `UnliftedNewtypes`:
```hs
{-# LANGUAGE DataKinds #-}
{-# LANGUAGE TypeFamilies #-}
module Bug where
import Data.Kind
import GHC.Exts
data family Foo (a :: Type) :: TYPE 'IntRep
```
```
$ ~/Software/ghc5/inplace/bin/ghc-stage2 Bug.hs
[1 of 1] Compiling Bug ( Bug.hs, Bug.o )
Bug.hs:8:1: error:
• Kind signature on data type declaration has non-*
and non-variable return kind
TYPE 'IntRep
• In the data family declaration for ‘Foo’
|
8 | data family Foo (a :: Type) :: TYPE 'IntRep
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
$ ~/Software/ghc5/inplace/bin/ghc-stage2 Bug.hs -XUnliftedNewtypes
[1 of 1] Compiling Bug ( Bug.hs, Bug.o )
```
Fixing this won't be too difficult, as it simply involves removing a validity check.8.10.1Ryan ScottRyan Scotthttps://gitlab.haskell.org/ghc/ghc/-/issues/16821Enabling -XUnliftedNewtypes permits panicking code (getRuntimeRep)2019-08-03T01:31:20ZRyan ScottEnabling -XUnliftedNewtypes permits panicking code (getRuntimeRep)One interesting piece of `UnliftedNewtypes` trivia is that it permits the use of type families in newtype return kinds. It seems that this can have unfortunate consequences, however. Consider this example:
```hs
{-# LANGUAGE DataKinds #...One interesting piece of `UnliftedNewtypes` trivia is that it permits the use of type families in newtype return kinds. It seems that this can have unfortunate consequences, however. Consider this example:
```hs
{-# LANGUAGE DataKinds #-}
{-# LANGUAGE GADTs #-}
{-# LANGUAGE TypeFamilies #-}
-- {-# LANGUAGE UnliftedNewtypes #-}
module Bug where
import Data.Kind
type family Id (x :: Type) :: Type where
Id x = x
newtype T :: Id Type where
MkT :: Int -> T
f :: T -> T
f (MkT x) = MkT (x + 1)
```
If you compile this, you'll simply get an error:
```
$ ~/Software/ghc5/inplace/bin/ghc-stage2 Bug.hs
[1 of 1] Compiling Bug ( Bug.hs, Bug.o )
Bug.hs:12:1: error:
• Kind signature on data type declaration has non-* return kind
Id *
• In the newtype declaration for ‘T’
|
12 | newtype T :: Id Type where
| ^^^^^^^^^^^^^^^^^^^^^^^^^^...
```
However, if you uncomment the `{-# LANGUAGE UnliftedNewtypes #-}` line, then GHC will panic:
```
$ ~/Software/ghc5/inplace/bin/ghc-stage2 Bug.hs
[1 of 1] Compiling Bug ( Bug.hs, Bug.o )
ghc-stage2: panic! (the 'impossible' happened)
(GHC version 8.9.0.20190614:
getRuntimeRep
T :: Id *
Call stack:
CallStack (from HasCallStack):
callStackDoc, called at compiler/utils/Outputable.hs:1179:37 in ghc:Outputable
pprPanic, called at compiler/types/Type.hs:2366:18 in ghc:Type
```
It's unclear to me whether this program should work or not, but either way, something is afoot.8.10.1Ryan ScottRyan Scotthttps://gitlab.haskell.org/ghc/ghc/-/issues/16300Make TH always reify data types with explicit return kinds2019-07-26T14:15:14ZRyan ScottMake TH always reify data types with explicit return kindsCurrently, whenever you reify a data type with Template Haskell, it will return a `DataD`/`NewtypeD` where the return kind information has been set to `Nothing`:
```
λ> putStrLn $(reify ''Bool >>= stringE . show)
TyConI (DataD [] GHC.Ty...Currently, whenever you reify a data type with Template Haskell, it will return a `DataD`/`NewtypeD` where the return kind information has been set to `Nothing`:
```
λ> putStrLn $(reify ''Bool >>= stringE . show)
TyConI (DataD [] GHC.Types.Bool [] Nothing [NormalC GHC.Types.False [],NormalC GHC.Types.True []] [])
```
One could argue that this isn't a problem since data types always have return kind `Type` anyway. For 99% of data types, this is true. There are a handful of exceptions, such as unboxed tuples (with return kind `TYPE (TupleRep [...])`, but those could be dismissed as unusual special cases.
With the advent of [unlifted newtypes](https://phabricator.haskell.org/D4777), however, things become murkier. `UnliftedNewtypes` let you define newtypes like this one:
```hs
newtype Foo :: TYPE IntRep where MkFoo :: Int# -> Foo
```
Notice how the return kind is //not// `Type`, but instead `TYPE IntRep`. However, TH reification doesn't clue you in to this fact:
```
λ> putStrLn $(reify ''Foo >>= stringE . show)
TyConI (NewtypeD [] Ghci8.Foo [] Nothing (GadtC [Ghci8.MkFoo] [(Bang NoSourceUnpackedness NoSourceStrictness,ConT GHC.Prim.Int#)] (ConT Ghci8.Foo)) [])
```
Still `Nothing`. There's no easy way in general to determine what the return kind of an unlifted newtype is using TH reification, which is unfortunate.
Luckily, I think there's a very simple fix that we could apply here: just have TH reification return `Just (<kind>)` instead of `Nothing`! There's no technical reason why TH couldn't do this; the only reason it currently returns `Nothing` is due to historical convention. Moreover, I doubt that this would even break any code in the wild, since `Nothing` doesn't convey any useful information in the context of TH reification anyway.
Does this sound reasonable?
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ---------------- |
| Version | 8.6.3 |
| Type | FeatureRequest |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Template Haskell |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Make TH always reify data types with explicit return kinds","status":"New","operating_system":"","component":"Template Haskell","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.6.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"FeatureRequest","description":"Currently, whenever you reify a data type with Template Haskell, it will return a `DataD`/`NewtypeD` where the return kind information has been set to `Nothing`:\r\n\r\n{{{\r\nλ> putStrLn $(reify ''Bool >>= stringE . show)\r\nTyConI (DataD [] GHC.Types.Bool [] Nothing [NormalC GHC.Types.False [],NormalC GHC.Types.True []] [])\r\n}}}\r\n\r\nOne could argue that this isn't a problem since data types always have return kind `Type` anyway. For 99% of data types, this is true. There are a handful of exceptions, such as unboxed tuples (with return kind `TYPE (TupleRep [...])`, but those could be dismissed as unusual special cases.\r\n\r\nWith the advent of [https://phabricator.haskell.org/D4777 unlifted newtypes], however, things become murkier. `UnliftedNewtypes` let you define newtypes like this one:\r\n\r\n{{{#!hs\r\nnewtype Foo :: TYPE IntRep where MkFoo :: Int# -> Foo\r\n}}}\r\n\r\nNotice how the return kind is //not// `Type`, but instead `TYPE IntRep`. However, TH reification doesn't clue you in to this fact:\r\n\r\n{{{\r\nλ> putStrLn $(reify ''Foo >>= stringE . show)\r\nTyConI (NewtypeD [] Ghci8.Foo [] Nothing (GadtC [Ghci8.MkFoo] [(Bang NoSourceUnpackedness NoSourceStrictness,ConT GHC.Prim.Int#)] (ConT Ghci8.Foo)) [])\r\n}}}\r\n\r\nStill `Nothing`. There's no easy way in general to determine what the return kind of an unlifted newtype is using TH reification, which is unfortunate.\r\n\r\nLuckily, I think there's a very simple fix that we could apply here: just have TH reification return `Just (<kind>)` instead of `Nothing`! There's no technical reason why TH couldn't do this; the only reason it currently returns `Nothing` is due to historical convention. Moreover, I doubt that this would even break any code in the wild, since `Nothing` doesn't convey any useful information in the context of TH reification anyway.\r\n\r\nDoes this sound reasonable?","type_of_failure":"OtherFailure","blocking":[]} -->8.10.1https://gitlab.haskell.org/ghc/ghc/-/issues/15883GHC panic: newtype F rep = F (forall (a :: TYPE rep). a)2020-01-17T16:43:24ZIcelandjackGHC panic: newtype F rep = F (forall (a :: TYPE rep). a)```hs
{-# Language RankNTypes #-}
{-# Language KindSignatures #-}
{-# Language PolyKinds #-}
import GHC.Exts
newtype Foo rep = MkFoo (forall (a :: TYPE rep). a)
```
```
$ ~/code/unmodifiedghc/inplace/bin/ghc-stage2 --interact...```hs
{-# Language RankNTypes #-}
{-# Language KindSignatures #-}
{-# Language PolyKinds #-}
import GHC.Exts
newtype Foo rep = MkFoo (forall (a :: TYPE rep). a)
```
```
$ ~/code/unmodifiedghc/inplace/bin/ghc-stage2 --interactive -ignore-dot-ghci /tmp/U.hs
GHCi, version 8.7.20181029: http://www.haskell.org/ghc/ :? for help
[1 of 1] Compiling Main ( /tmp/U.hs, interpreted )
ghc-stage2: panic! (the 'impossible' happened)
(GHC version 8.7.20181029 for x86_64-unknown-linux):
isUnliftedType
forall (a :: TYPE rep_a1AA[sk:0]). a :: TYPE rep_a1AA[sk:0]
Call stack:
CallStack (from HasCallStack):
callStackDoc, called at compiler/utils/Outputable.hs:1160:37 in ghc:Outputable
pprPanic, called at compiler/types/Type.hs:2332:10 in ghc:Type
isUnliftedType, called at compiler/typecheck/TcTyClsDecls.hs:3055:25 in ghc:TcTyClsDecls
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
>
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.6.2 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"GHC panic: newtype F rep = F (forall (a :: TYPE rep). a)","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"8.6.3","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.6.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"{{{#!hs\r\n{-# Language RankNTypes #-}\r\n{-# Language KindSignatures #-}\r\n{-# Language PolyKinds #-}\r\n\r\nimport GHC.Exts\r\n\r\nnewtype Foo rep = MkFoo (forall (a :: TYPE rep). a)\r\n}}}\r\n\r\n{{{\r\n$ ~/code/unmodifiedghc/inplace/bin/ghc-stage2 --interactive -ignore-dot-ghci /tmp/U.hs\r\nGHCi, version 8.7.20181029: http://www.haskell.org/ghc/ :? for help\r\n[1 of 1] Compiling Main ( /tmp/U.hs, interpreted )\r\nghc-stage2: panic! (the 'impossible' happened)\r\n (GHC version 8.7.20181029 for x86_64-unknown-linux):\r\n isUnliftedType\r\n forall (a :: TYPE rep_a1AA[sk:0]). a :: TYPE rep_a1AA[sk:0]\r\n Call stack:\r\n CallStack (from HasCallStack):\r\n callStackDoc, called at compiler/utils/Outputable.hs:1160:37 in ghc:Outputable\r\n pprPanic, called at compiler/types/Type.hs:2332:10 in ghc:Type\r\n isUnliftedType, called at compiler/typecheck/TcTyClsDecls.hs:3055:25 in ghc:TcTyClsDecls\r\n\r\nPlease report this as a GHC bug: http://www.haskell.org/ghc/reportabug\r\n\r\n>\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->8.10.1https://gitlab.haskell.org/ghc/ghc/-/issues/15219Implement UnliftedNewtypes proposal2019-07-07T18:13:44ZAndrew MartinImplement UnliftedNewtypes proposalThe unlifted newtypes proposal is described here: https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0013-unlifted-newtypes.rst
I am going to be working on it.
<details><summary>Trac metadata</summary>
| Trac field ...The unlifted newtypes proposal is described here: https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0013-unlifted-newtypes.rst
I am going to be working on it.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.4.3 |
| Type | Task |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Implement UnliftedNewtypes proposal","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"8.6.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.4.3","keywords":["UnliftedNewtypes"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Task","description":"The unlifted newtypes proposal is described here: https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0013-unlifted-newtypes.rst\r\n\r\nI am going to be working on it.","type_of_failure":"OtherFailure","blocking":[]} -->8.10.1https://gitlab.haskell.org/ghc/ghc/-/issues/13595Should ‘coerce’ be levity polymorphic?2019-07-07T18:21:06ZIcelandjackShould ‘coerce’ be levity polymorphic?I'm not able to write `coerce @Int# @Int#` or `coerce :: Double# -> Double#`, just checking to see if its intentional or not
```
>>> :set -XTypeApplications
>>> :set -XMagicHash
>>> import Data.Coerce
>>> import GHC.Exts
>>>> :t coerc...I'm not able to write `coerce @Int# @Int#` or `coerce :: Double# -> Double#`, just checking to see if its intentional or not
```
>>> :set -XTypeApplications
>>> :set -XMagicHash
>>> import Data.Coerce
>>> import GHC.Exts
>>>> :t coerce @Int
coerce @Int :: Coercible b Int => Int -> b
>>> :t coerce @Int#
<interactive>:1:1: error:
Couldn't match a lifted type with an unlifted type
When matching types
b :: *
Int# :: TYPE 'IntRep
<interactive>:1:9: error:
• Expecting a lifted type, but ‘Int#’ is unlifted
• In the type ‘Int#’
In the expression: coerce @Int#
```
This was needed for #13592.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.0.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Should ‘coerce’ be levity polymorphic?","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.0.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"I'm not able to write `coerce @Int# @Int#` or `coerce :: Double# -> Double#`, just checking to see if its intentional or not\r\n\r\n{{{\r\n>>> :set -XTypeApplications\r\n>>> :set -XMagicHash\r\n\r\n>>> import Data.Coerce\r\n>>> import GHC.Exts\r\n\r\n>>>> :t coerce @Int\r\ncoerce @Int :: Coercible b Int => Int -> b\r\n>>> :t coerce @Int#\r\n\r\n<interactive>:1:1: error:\r\n Couldn't match a lifted type with an unlifted type\r\n When matching types\r\n b :: *\r\n Int# :: TYPE 'IntRep\r\n\r\n<interactive>:1:9: error:\r\n • Expecting a lifted type, but ‘Int#’ is unlifted\r\n • In the type ‘Int#’\r\n In the expression: coerce @Int#\r\n}}} \r\n\r\nThis was needed for #13592.","type_of_failure":"OtherFailure","blocking":[]} -->8.10.1https://gitlab.haskell.org/ghc/ghc/-/issues/12766Allow runtime-representation polymorphic data families2019-07-07T18:25:14ZIcelandjackAllow runtime-representation polymorphic data familiesThis is an offshoot of #12369 (‘data families shouldn't be required to have return kind \*, data instances should’), allowing family declarations something like:
```hs
data family Array a :: TYPE rep
```This is an offshoot of #12369 (‘data families shouldn't be required to have return kind \*, data instances should’), allowing family declarations something like:
```hs
data family Array a :: TYPE rep
```8.10.1https://gitlab.haskell.org/ghc/ghc/-/issues/1311newtypes of unboxed types disallowed - documentation bug and/or feature request2021-02-24T11:23:39ZIsaac Dupreenewtypes of unboxed types disallowed - documentation bug and/or feature requestTested in 6.6.1 and today's 6.7 (which claims to be version 6.7.20070418),
`newtype FastBool = FastBool Int#`
doesn't work. However this is not documented in the unboxed-types documentation in the User's Guide that lists similar restri...Tested in 6.6.1 and today's 6.7 (which claims to be version 6.7.20070418),
`newtype FastBool = FastBool Int#`
doesn't work. However this is not documented in the unboxed-types documentation in the User's Guide that lists similar restrictions http://www.haskell.org/ghc/docs/latest/html/users_guide/primitives.html
Similarly (maybe), in phantom type arguments, even in GADTs where kind inference could be at work
`data Boo a where Boo :: Int# -> Boo Int#`
doesn't work.
I tried `newtype ( FastBool :: # ) = ...` , and `data Boo ( a :: # ) where...` , which just confused GHC.
Is there a reason that coercions of unlifted types shouldn't work, or is it just unimplemented? (inspired by looking at GHC's
compiler/utils/FastTypes.lhs and thinking that using newtypes instead of type synonyms in places like that would improve type-safety)
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.6.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | Unknown |
| Architecture | Unknown |
</details>
<!-- {"blocked_by":[],"summary":"newtypes of unboxed types disallowed - documentation bug and/or feature request","status":"New","operating_system":"Unknown","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.6.1","keywords":[],"differentials":[],"test_case":"","architecture":"Unknown","cc":[""],"type":"Bug","description":"Tested in 6.6.1 and today's 6.7 (which claims to be version 6.7.20070418),\r\n\r\n{{{newtype FastBool = FastBool Int#}}}\r\n\r\ndoesn't work. However this is not documented in the unboxed-types documentation in the User's Guide that lists similar restrictions http://www.haskell.org/ghc/docs/latest/html/users_guide/primitives.html\r\n\r\nSimilarly (maybe), in phantom type arguments, even in GADTs where kind inference could be at work\r\n\r\n{{{data Boo a where Boo :: Int# -> Boo Int#}}}\r\n\r\ndoesn't work.\r\n\r\nI tried {{{newtype ( FastBool :: # ) = ...}}} , and {{{data Boo ( a :: # ) where...}}} , which just confused GHC.\r\n\r\nIs there a reason that coercions of unlifted types shouldn't work, or is it just unimplemented? (inspired by looking at GHC's \r\ncompiler/utils/FastTypes.lhs and thinking that using newtypes instead of type synonyms in places like that would improve type-safety)","type_of_failure":"OtherFailure","blocking":[]} -->8.10.1Ömer Sinan AğacanÖmer Sinan Ağacan