GHC issueshttps://gitlab.haskell.org/ghc/ghc/-/issues2023-05-10T12:55:55Zhttps://gitlab.haskell.org/ghc/ghc/-/issues/23331Make reifyInstances support Typeable2023-05-10T12:55:55ZMagnus ViernickelMake reifyInstances support Typeable<!--
READ THIS FIRST: If the feature you are proposing changes the language that GHC accepts
or adds any warnings to `-Wall`, it should be written as a [GHC Proposal](https://github.com/ghc-proposals/ghc-proposals/).
Other features, appr...<!--
READ THIS FIRST: If the feature you are proposing changes the language that GHC accepts
or adds any warnings to `-Wall`, it should be written as a [GHC Proposal](https://github.com/ghc-proposals/ghc-proposals/).
Other features, appropriate for a GitLab feature request, include GHC API/plugin
innovations, new low-impact compiler flags, or other similar additions to GHC.
-->
## Motivation
GHC currently does not reifyInstances for Typeable. This makes it so that I have to special case something that has to support Typeable in my TH code.
## Proposal
Support Typeable reification.
## Additional Context
https://hackage.haskell.org/package/template-haskell-2.19.0.0/docs/Language-Haskell-TH.html#v:reifyInstances
For an example of where this is useful/ an issue, please refer to:
https://git.sr.ht/~mangoiv/htree/tree/main/item/test/Spec/HTree/TH.hs
And
https://git.sr.ht/~mangoiv/htree/tree/main/item/test/Spec/HTree/Orphans.hsMatthew PickeringMatthew Pickeringhttps://gitlab.haskell.org/ghc/ghc/-/issues/22553Typeable appears not to work with UnboxedSums2022-12-02T12:24:09ZMatthew PickeringTypeable appears not to work with UnboxedSumsThis program fails to compile:
```
{-# LANGUAGE UnboxedSums, UnboxedTuples #-}
module Test where ...This program fails to compile:
```
{-# LANGUAGE UnboxedSums, UnboxedTuples #-}
module Test where
import Data.Proxy
import Type.Reflection
main = do
print (someTypeRep (Proxy @(# () , () #)))
print (someTypeRep (Proxy @(# () | () #)))
```
with error:
```
Unboxed.hs:10:10: error: [GHC-39999]
• No instance for ‘Typeable (# | #)’
arising from a use of ‘someTypeRep’
GHC can't yet do polykinded
Typeable ((# | #) :: *
-> *
-> TYPE
(GHC.Types.SumRep [GHC.Types.LiftedRep, GHC.Types.LiftedRep]))
• In the first argument of ‘print’, namely
‘(someTypeRep (Proxy @(# () | () #)))’
In a stmt of a 'do' block:
print (someTypeRep (Proxy @(# () | () #)))
In the expression:
do print (someTypeRep (Proxy @(# (), () #)))
print (someTypeRep (Proxy @(# () | () #)))
|
10 | print (someTypeRep (Proxy @(# () | () #)))
| ^^^^^^^^^^^
```
If it works for unboxed tuples then I expected the same to work for unboxed sums.https://gitlab.haskell.org/ghc/ghc/-/issues/22113Document behaviour of `Ord TypeRep` instance (inconsistent across compilations)2022-09-14T22:01:22ZNiklas Hambüchenmail@nh2.meDocument behaviour of `Ord TypeRep` instance (inconsistent across compilations)## Summary
`Data.Typeable` has an [`instance Ord TypeRep`](https://hackage.haskell.org/package/base-4.17.0.0/docs/src/Data.Typeable.Internal.html#line-359) that we suspect is not lawful across compiler invocations.
It compares `typeRep...## Summary
`Data.Typeable` has an [`instance Ord TypeRep`](https://hackage.haskell.org/package/base-4.17.0.0/docs/src/Data.Typeable.Internal.html#line-359) that we suspect is not lawful across compiler invocations.
It compares `typeRepFingerprint`.
We have a `servant`-like web server with type-defined routes, and a function that can generate TypeScript type definitions from it ([code](https://github.com/chpatrick/solga/blob/ba057e4c6f8865d848a5f8388f5bc29328b45f15/solga-typescript/src/Solga/TypeScript.hs#L95). It uses the `aeson-typescript` package that provides functions based on `Data.Set.Set TSType`; the [`Ord` instance of `TSType`](https://www.stackage.org/haddock/lts-19.20/aeson-typescript-0.3.0.1/src/Data.Aeson.TypeScript.Types.html#line-68) compares `typeRep`s.
As such, the generated `.ts` files have different contents depending on whether they are generated in `ghc` or `ghci`, even though the code that produces their contents is pure (no `IO`). This is bad.
## Proposed improvements or changes
* Somebody to confirm if the above is correct.
* If yes, document it.
* Is it possible to write an `Ord` instance that is lawful/consistent across different ways of compilation?
## Environment
* Current and older versions of `base` (currently `4.17.0.0`).Ben GamariBen Gamarihttps://gitlab.haskell.org/ghc/ghc/-/issues/21822Improve Typeable instances2022-07-11T08:19:39ZSimon Peyton JonesImprove Typeable instancesConsider this example, taken from [this email thread](https://mail.haskell.org/pipermail/ghc-steering-committee/2022-July/002812.html)
```
newtype D a = D { getD :: Int }
class Typeable a => S a
instance Typeable a => S (D a)
```
This l...Consider this example, taken from [this email thread](https://mail.haskell.org/pipermail/ghc-steering-committee/2022-July/002812.html)
```
newtype D a = D { getD :: Int }
class Typeable a => S a
instance Typeable a => S (D a)
```
This looks OK but it isn't:
```
Poly.hs:10:10: error:
• Could not deduce (Typeable k)
arising from the superclasses of an instance declaration
from the context: Typeable a
bound by the instance declaration at Poly.hs:10:10-30
```
The problem is that `D` is poly-kinded, thus `D :: forall k. k -> Type`. So the instance is really like this:
```
instance Typeable a => S (D @k (a::k))
```
And now GHC wants a `Typeable k` instance so it can make the type representation for `D @k a`.
But this is a bit funny. WE have `Typeable (a::k)`, and we have a function
```
typeRepKind :: forall a (a::k). TypeRep a -> TypeRep k
```
So, given a `TypeRep (a::k)` (or equivalently `Typeable (a::k)`) we can easily get a `TypeRep k`
(or equivalently `Typeable k`).
This ticket is to suggest that we automtate this. I can see two alternatives:
1. Change the definition of `Typeable` thus:
```
class Typeable k => Typeable (a::k) where ...
```
That is, add the typerep of the kind as a superclass. This would require `UndecideableSuperclasses`
(but only in `Data.Typeable` not in clients). It's a sort of infinite regress, but it bottoms
out with `Typeable Type`, which is its own superclass.
2. Don't make a proper superclass (a field of the dictionary) but instead somehow use `typeRepKind` to
make a kind of bespoke superclass, during superclass expansion.
(2) sounds a bit magical and ad-hoc; let's try (1) first.
Maybe this should be a GHC proposal, but I wanted to float it here first.https://gitlab.haskell.org/ghc/ghc/-/issues/21501Confusion around visible type application in pattern synonym pattern2023-02-09T17:22:10ZRichard Eisenbergrae@richarde.devConfusion around visible type application in pattern synonym patternSee also #19847
Sometimes, I like to declare
```hs
import Data.Kind
import Type.Reflection
pattern TypeApp ::
forall {k1} {k2} (f :: k1 -> k2) (result :: k2).
Typeable f =>
forall (arg :: k1).
result ~ f arg =>
TypeRep arg ...See also #19847
Sometimes, I like to declare
```hs
import Data.Kind
import Type.Reflection
pattern TypeApp ::
forall {k1} {k2} (f :: k1 -> k2) (result :: k2).
Typeable f =>
forall (arg :: k1).
result ~ f arg =>
TypeRep arg ->
TypeRep result
pattern TypeApp arg_rep <- App (eqTypeRep (typeRep @f) -> Just HRefl) arg_rep
```
This pattern synonym allows me to match on a `TypeRep` to see whether its an application of some known type constructor, like `List` or `Maybe`.
GHC accepts this declaration, as it should.
But using causes chaos:
```hs
f :: TypeRep a -> String
f (TypeApp @[] rep) = show rep
```
produces
```
Bug.hs:18:4: error:
• No instance for (Typeable f0) arising from a use of ‘TypeApp’
• In the pattern: TypeApp @[] rep
In an equation for ‘f’: f (TypeApp @[] rep) = show rep
|
18 | f (TypeApp @[] rep) = show rep
| ^^^^^^^^^^^^^^^
Bug.hs:18:4: error:
• Could not deduce (k1 ~ *)
from the context: a ~ f0 arg
bound by a pattern with pattern synonym:
TypeApp :: forall {k1} {k2} (f :: k1 -> k2) (result :: k2).
Typeable f =>
forall (arg :: k1).
(result ~ f arg) =>
TypeRep arg -> TypeRep result,
in an equation for ‘f’
at Bug.hs:18:4-18
‘k1’ is a rigid type variable bound by
the type signature for:
f :: forall {k1} (a :: k1). TypeRep a -> String
at Bug.hs:17:1-24
• In the pattern: TypeApp @[] rep
In an equation for ‘f’: f (TypeApp @[] rep) = show rep
• Relevant bindings include
f :: TypeRep a -> String (bound at Bug.hs:18:1)
|
18 | f (TypeApp @[] rep) = show rep
| ^^^^^^^^^^^^^^^
```
I have no clue what GHC is thinking here. Even when I try making `k1` and `k2` *specified* (in parens, not braces) and stating `@Type @Type`, GHC is no better off, producing roughly the same messages.
For the record, this was encountered while I was writing a library that is intended to be useful in the Real World.https://gitlab.haskell.org/ghc/ghc/-/issues/21183Typeable evidence is always CAFfy2022-03-08T10:48:26ZBen GamariTypeable evidence is always CAFfyIt turns out that `Typeable`'s `TypeRep` evidence, which ends up being quite widely used in the exception machinery and elsewhere, produces gobs of CAFs. For instance, consider the case of `typeRep @Int`. Today this will result in the ev...It turns out that `Typeable`'s `TypeRep` evidence, which ends up being quite widely used in the exception machinery and elsewhere, produces gobs of CAFs. For instance, consider the case of `typeRep @Int`. Today this will result in the evidence binding:
```haskell
tr :: TypeRep Int
tr = Data.Typeable.Internal.mkTrCon $tcInt []
```
After being floated to the top-level (as it very likely will be) this binding is, of course, a CAF. However, on examining the definition of `mkTrCon` one might suspect that this could be easily reduced to a static constructor application:
```haskell
mkTrCon :: forall k (a :: k). TyCon -> [SomeTypeRep] -> TypeRep a
mkTrCon tc kind_vars
= TrTyCon
{ trTyConFingerprint = fpr
, trTyCon = tc
, trKindVars = kind_vars
, trTyConKind = kind }
where
fpr_tc = tyConFingerprint tc
fpr_kvs = map someTypeRepFingerprint kind_vars
fpr = fingerprintFingerprints (fpr_tc:fpr_kvs)
kind = unsafeCoerceRep $ tyConKind tc kind_vars
```
Nearly all of this computation can, in principle, be done at compile-time:
* `trTyConFingerprint` is simply a fold over a known list
* `trTyCon` is the `TyCon` itself
* `trKindVars` is simply the given list of kind variables
* `trTyConKind` is a bit tricky as it instantiates the tycon's `KindRep`. However, in the case of a kind-monomorphic type this instantiation is trivial.Ben GamariBen Gamarihttps://gitlab.haskell.org/ghc/ghc/-/issues/20766Don't generate instances with -dno-typeable-binds2021-12-02T03:36:11ZKrzysztof GogolewskiDon't generate instances with -dno-typeable-binds`-dno-typeable-binds` is a debugging flag that disables generation of bindings for `Typeable` instances. Usually they just clutter the Core output. If you try to use a Typeable instance in this case, GHC will panic.
I think it would be ...`-dno-typeable-binds` is a debugging flag that disables generation of bindings for `Typeable` instances. Usually they just clutter the Core output. If you try to use a Typeable instance in this case, GHC will panic.
I think it would be better if `-dno-typeable-binds` disabled derivation of Typeable instances instead (in the compiled module). Then attempting to use the instance will be a normal missing instance error. Some time ago we had a flag `-XAutoDeriveTypeable`.https://gitlab.haskell.org/ghc/ghc/-/issues/20613Add `typeToName` bike shedding2021-11-29T11:13:45ZparsonsmattAdd `typeToName` bike sheddingI've written a helper function `typeToName` that seems like a useful addition to `template-haskell`. Here's the code currently:
```haskell
module Data.Typeable.Extended
( module Data.Typeable.Extended,
module Data.Typeable,
)
wh...I've written a helper function `typeToName` that seems like a useful addition to `template-haskell`. Here's the code currently:
```haskell
module Data.Typeable.Extended
( module Data.Typeable.Extended,
module Data.Typeable,
)
where
import Data.Typeable
import Language.Haskell.TH.Syntax
-- | Retrieve a @TemplateHaskell@ 'Name' for a 'Typeable' type. Used to drive derivation:
--
-- @
-- $(
-- let
-- prxy = Proxy :: Proxy Int
-- in
-- mobileGen (moatOptionsP prxy) (typeToName prxy)
-- )
-- @
typeToName :: Typeable a => Proxy a -> Name
typeToName prxy =
let tyRep =
typeRep prxy
tyCon =
typeRepTyCon tyRep
in mkNameG TcClsName (tyConPackage tyCon) (tyConModule tyCon) (tyConName tyCon)
```
Would a PR adding this be accepted?
If so, where should it go? And should it have a different name or signature?Matthew PickeringMatthew Pickeringhttps://gitlab.haskell.org/ghc/ghc/-/issues/20280TyCon should include fixity, etc.2021-08-26T09:44:23ZDavid FeuerTyCon should include fixity, etc.## Motivation
When using `Type.Reflection`, the base case is `TyCon`, which gives info about a type constructor. Unfortunately, it's not really enough information to display expressions properly or provide full details.
## Proposal
It...## Motivation
When using `Type.Reflection`, the base case is `TyCon`, which gives info about a type constructor. Unfortunately, it's not really enough information to display expressions properly or provide full details.
## Proposal
It would be nice to get
1. Fixity.
2. Is this a `Nat`, and if so what `Natural` does it represent?
3. Is this a `Symbol`, and if so what `String` (or `Text`?) does it represent?
4. Is this a promoted datacon, and if so, what is the name of the underlying constructor?https://gitlab.haskell.org/ghc/ghc/-/issues/20164Linear types: investigate the multiplicity argument of FUN2021-12-08T18:59:04ZKrzysztof GogolewskiLinear types: investigate the multiplicity argument of FUNCurrently, the kind of `FUN` is
```forall (m :: Multiplicity) -> forall {r1 r2 :: RuntimeRep}. TYPE r1 -> TYPE r2 -> Type```
This is a hack. The argument `m` is dependent, even though it is not used as such.
The goal of this ticket is...Currently, the kind of `FUN` is
```forall (m :: Multiplicity) -> forall {r1 r2 :: RuntimeRep}. TYPE r1 -> TYPE r2 -> Type```
This is a hack. The argument `m` is dependent, even though it is not used as such.
The goal of this ticket is to investigate how to simplify this and make `m` non-dependent. There are two candidates; I prefer the second one.
1. ```Multiplicity -> forall {r1 r2 :: RuntimeRep}. TYPE r1 -> TYPE r2 -> Type```
I could not get this to work with `Typeable`, which discards toplevel `forall`s to get rid of kind polymorphism.
2. ```forall {r1 r2 :: RuntimeRep}. Multiplicity -> TYPE r1 -> TYPE r2 -> Type```
During the implementation of linear types, I was worried that with this option `type (->) = FUN 'Many` would no longer support levity polymorphism. However, this should be doable with a built-in `type (->) @r1 @r2 = FUN @r1 @r2 'Many`.
One consequence of this hack is that the implementation of `Typeable` with linear types is more complicated. Previously, the TypeRep for `((->) x) y` was stored using a separate constructor `TrFun` as a mere optimisation. Now, `TrFun` is an irreducible primitive remembering the multiplicity. This ticket should restore the previous state, and furthermore it should be possible to remove the restriction `"splitApps: Only unrestricted functions are supported"` in Typeable.
This ticket is best done after #18750.Krzysztof GogolewskiKrzysztof Gogolewskihttps://gitlab.haskell.org/ghc/ghc/-/issues/19991Unused instances retained2021-06-22T14:33:52ZDavid FeuerUnused instances retainedSince instances are global, GHC always exports them. Normally, this is fine. With `Typeable`, it often leads to unnecessary junk in object files, interface files, and dumps. For example, consider this (complete) module
```haskell
module...Since instances are global, GHC always exports them. Normally, this is fine. With `Typeable`, it often leads to unnecessary junk in object files, interface files, and dumps. For example, consider this (complete) module
```haskell
module Foo (sauce)
data Res = Goodness | Gracious
deriving Enum
stir :: Int -> Res
sauce :: Int -> Bool
sauce = toEnum . fromEnum . stir
```
GHC will produce all the bindings for `Typeable Res`, `Typeable 'Goodness` and
`Typeable 'Gracious`, none of which can ever be used. It also exports an `Enum` instance for `Res` which is unusable outside the module (and which will be optimized out of existence inside it). It would be really nice to find a way to clean up at least the totally unused/unusable bindings.
I think the key idea is to come up with (a conservative approximation of?) when a type is "exported". Only instances of exported types should be considered "GC roots" for cleanup. Any type listed in an export list is immediately considered exported. Similarly, any type that appears in the type signature of an exported binding or data constructor is immediately considered exported. I imagine the tricky bits will be in type/data families and maybe functional dependencies. But even the most conservative approximations will probably clean up the vast majority of the crud.https://gitlab.haskell.org/ghc/ghc/-/issues/19691Add 'pattern TypeRep :: () => Typeable a => TypeRep a' to Type.Reflection2022-08-26T15:09:21ZIcelandjackAdd 'pattern TypeRep :: () => Typeable a => TypeRep a' to Type.Reflection`Type.Reflection` should export a `TypeRep` pattern synonym akin to [`pattern Sing`](https://hackage.haskell.org/package/singletons-3.0/docs/src/Data.Singletons.html#%24bSing) from singletons, that brings a local `Typeable a` constraint ...`Type.Reflection` should export a `TypeRep` pattern synonym akin to [`pattern Sing`](https://hackage.haskell.org/package/singletons-3.0/docs/src/Data.Singletons.html#%24bSing) from singletons, that brings a local `Typeable a` constraint into scope by pattern matching:
```haskell
type TypeableInstance :: forall k. k -> Type
data TypeableInstance a where
TypeableInstance :: Typeable a => TypeableInstance a
typeableInstance :: forall (k :: Type) (a :: k). TypeRep a -> TypeableInstance a
typeableInstance typeRep = withTypeable typeRep TypeableInstance
pattern TypeRep :: forall (k :: Type) (a :: k). () => Typeable a => TypeRep a
pattern TypeRep <- (typeableInstance -> TypeableInstance)
where TypeRep = typeRep
```
Relevant to this question: [What's the modern way to apply a polymorphic function to a Dynamic value in GHC 8.8 and onwards?](https://mail.haskell.org/pipermail/ghc-devs/2021-April/019812.html) ([reddit](https://www.reddit.com/r/haskell/comments/mpcqpq/whats_the_modern_way_to_apply_a_polymorphic/)) where the answer would be
```haskell
apD :: Typeable f => (forall a. a -> f a) -> Dynamic -> Dynamic
apD f (Dynamic TypeRep a) = Dynamic TypeRep (f a)
```
This is a much nicer interface than continuation passing style with `withTypeable`.
I always forget where these proposals should go so please direct me to the proper venue. Thank you.https://gitlab.haskell.org/ghc/ghc/-/issues/19548Kind generalisation without -XPolyKinds leading to breakage2021-03-17T08:07:24ZSebastian GrafKind generalisation without -XPolyKinds leading to breakageThe following program is reduced from `libraries/Cabal/Cabal/src/Distribution/Utils/Path.hs`, which I didn't manage to compile with @bgamari's [build-cabal.sh script](https://gitlab.haskell.org/bgamari/ghc-utils/-/blob/master/build-cabal...The following program is reduced from `libraries/Cabal/Cabal/src/Distribution/Utils/Path.hs`, which I didn't manage to compile with @bgamari's [build-cabal.sh script](https://gitlab.haskell.org/bgamari/ghc-utils/-/blob/master/build-cabal.sh) today:
```hs
{-# LANGUAGE DeriveDataTypeable #-}
module Path where
import Data.Typeable
class Typeable a => C a where
data T a = T deriving Typeable
instance Typeable a => C (T a)
```
If compiled with HEAD (and `-fprint-explicit-kinds`, this errors
```
Path.hs:9:10: error:
• Could not deduce (Typeable @(*) k)
arising from the superclasses of an instance declaration
from the context: Typeable @k a
bound by the instance declaration at Path.hs:9:10-30
• In the instance declaration for ‘C @{*} (T @{k} a)’
|
9 | instance Typeable a => C (T a)
| ^^^^^^^^^^^^^^^^^^^^^
```
Apparently, `T`'s type parameter has been kind generalised. Why? I don't think `-XDeriveDataTypeable` implies `-XPolyKinds`.
Yet the error message mentions an implicit kind `k` that appears nowhere else in the program.https://gitlab.haskell.org/ghc/ghc/-/issues/19288Type literals in Reflection of type constructor kinds leads to SafeHaskell vi...2021-02-05T21:10:33ZKyle EhrlichType literals in Reflection of type constructor kinds leads to SafeHaskell violation## Summary
[Data.Typeable.Internal#mkTypeLitFromString](https://hackage.haskell.org/package/base-4.14.1.0/docs/src/Data.Typeable.Internal.html#mkTypeLitFromString) has a typo which causes type Natural literals are tagged with the type S...## Summary
[Data.Typeable.Internal#mkTypeLitFromString](https://hackage.haskell.org/package/base-4.14.1.0/docs/src/Data.Typeable.Internal.html#mkTypeLitFromString) has a typo which causes type Natural literals are tagged with the type Symbol type constructor. This can be used to get a `TypeRep Nat` that is equal to the true `TypeRep Symbol`.
## Steps to reproduce
Run this program:
```hs
{-# LANGUAGE DataKinds, KindSignatures, PolyKinds, TypeOperators, Safe #-}
module Main where
import Data.Maybe
import Data.Proxy
import Type.Reflection
import GHC.TypeLits
data Dat (x :: Proxy 1) = MkD1
evil :: Maybe (Nat :~~: Symbol)
evil = eqTypeRep (case (typeRepKind (typeRep :: TypeRep Dat)) of
(Fun (App _ x) _) -> typeRepKind x)
(typeRep :: TypeRep Symbol)
main :: IO ()
main = print (isJust evil)
```
The program prints True. This could easily be used to make an unsafeCast.
## Expected behavior
The program prints False
## Environment
* GHC version used: 8.10.39.0.2https://gitlab.haskell.org/ghc/ghc/-/issues/19196TypeInType prevents Typeable from being resolved from a given2021-01-11T03:19:52ZSerge KosyrevTypeInType prevents Typeable from being resolved from a givenThe following program is accepted without `TypeInType` by GHC 8.10.2:
```haskell
{-# LANGUAGE DataKinds #-}
{-# LANGUAGE GADTs #-}
{-# LANGUAGE KindSignatures #-}
{-# LANGUAGE ScopedTypeVariables #-}
{-# LANGUAGE UndecidableInstances #-}...The following program is accepted without `TypeInType` by GHC 8.10.2:
```haskell
{-# LANGUAGE DataKinds #-}
{-# LANGUAGE GADTs #-}
{-# LANGUAGE KindSignatures #-}
{-# LANGUAGE ScopedTypeVariables #-}
{-# LANGUAGE UndecidableInstances #-}
import Data.Dynamic
import Type.Reflection
data Liveness
= forall t. Live t
data IOA (l :: Liveness) where
IOE :: IOA (Live t)
data LTag (l :: Liveness) where
LLive :: Typeable t => TypeRep t -> LTag (Live t)
reconstruct :: Dynamic -> LTag l -> ()
reconstruct dyn l@LLive{} =
case l of
(LLive tr :: LTag (Live t)) ->
undefined $ withTypeable tr $
(fromDynamic dyn :: Maybe (IOA (Live t)))
main :: IO ()
main = undefined
```
It is, however, rejected with `TypeInType`, as follows:
```haskell
common/src/Dom/Pipe/IOA.hs:26:17: error:
• Could not deduce (Typeable t) arising from a use of ‘fromDynamic’
from the context: (l ~ 'Live t1, Typeable t1)
bound by a pattern with constructor:
LLive :: forall t1 (t2 :: t1).
Typeable t2 =>
TypeRep t2 -> LTag ('Live t2),
in an equation for ‘reconstruct’
at common/src/Dom/Pipe/IOA.hs:22:19-25
or from: ('Live t1 ~ 'Live t3, Typeable t3)
bound by a pattern with constructor:
LLive :: forall t1 (t2 :: t1).
Typeable t2 =>
TypeRep t2 -> LTag ('Live t2),
in a case alternative
at common/src/Dom/Pipe/IOA.hs:24:10-17
or from: Typeable t3
bound by a type expected by the context:
Typeable t3 => Maybe (IOA ('Live t1))
at common/src/Dom/Pipe/IOA.hs:26:16-56
• In the second argument of ‘($)’, namely
‘(fromDynamic dyn :: Maybe (IOA (Live t)))’
In the second argument of ‘($)’, namely
‘withTypeable tr $ (fromDynamic dyn :: Maybe (IOA (Live t)))’
In the expression:
undefined
$ withTypeable tr $ (fromDynamic dyn :: Maybe (IOA (Live t)))
|
26 | (fromDynamic dyn :: Maybe (IOA (Live t)))
| ^^^^^^^^^^^^^^^
```
Potentially related to #16627https://gitlab.haskell.org/ghc/ghc/-/issues/18769No instance for Typeable when using DataKinds + TypeFamilies2020-09-29T18:49:50ZBrandon ChinnNo instance for Typeable when using DataKinds + TypeFamilies## Summary
In the program below, I get an error
```
• No instance for (Typeable 'Foo1) arising from a use of ‘foo1’
• In the expression: foo1
In the first argument of ‘print’, namely ‘(foo1, foo2)’
In the ex...## Summary
In the program below, I get an error
```
• No instance for (Typeable 'Foo1) arising from a use of ‘foo1’
• In the expression: foo1
In the first argument of ‘print’, namely ‘(foo1, foo2)’
In the expression: print (foo1, foo2)
```
which doesn't make sense to me. Why is `Typeable` being applied to just `'Foo1` and not the applied `'Foo1 'True`? Shouldn't `Foo1` be equivalent to `Foo2`? What about the use of type families changes the formula here?
## Steps to reproduce
Compile the following problem:
```hs
{-# LANGUAGE DataKinds #-}
{-# LANGUAGE FlexibleContexts #-}
{-# LANGUAGE TypeFamilies #-}
import Data.Proxy
import Data.Typeable
type family Bar a where
Bar () = Bool
data Foo1 = Foo1 (Bar ())
foo1 :: Typeable (Proxy ('Foo1 'True)) => ()
foo1 = ()
data Foo2 = Foo2 Bool
foo2 :: Typeable (Proxy 'Foo2) => ()
foo2 = ()
main :: IO ()
main = print (foo1, foo2)
```
## Expected behavior
I would expect `Foo1` to be equivalent to `Foo2`
## Environment
* GHC version used: 8.8.1
Optional:
* Operating System: MacOS
* System Architecture:https://gitlab.haskell.org/ghc/ghc/-/issues/18723"Can't find interface-file declaration" error when using a large tuple in a d...2020-10-30T09:05:37ZRyan Scott"Can't find interface-file declaration" error when using a large tuple in a data typeThe following programs all report rather cryptic error messages on GHC 8.2 or later:
* ```hs
module Bug1 where
data T1 = MkT1
( Int, Int, Int, Int, Int, Int, Int, Int, Int, Int
, Int, Int, Int, Int, Int, Int, Int, Int, In...The following programs all report rather cryptic error messages on GHC 8.2 or later:
* ```hs
module Bug1 where
data T1 = MkT1
( Int, Int, Int, Int, Int, Int, Int, Int, Int, Int
, Int, Int, Int, Int, Int, Int, Int, Int, Int, Int
, Int, Int, Int, Int, Int, Int, Int, Int, Int, Int
, Int, Int, Int, Int, Int, Int, Int, Int, Int, Int
, Int, Int, Int, Int, Int, Int, Int, Int, Int, Int
, Int, Int, Int, Int, Int, Int, Int, Int, Int, Int
, Int, Int, Int
)
```
```
$ /opt/ghc/8.10.2/bin/ghc Bug1.hs
[1 of 1] Compiling Bug1 ( Bug1.hs, Bug1.o )
Bug1.hs:1:1: error:
Can't find interface-file declaration for variable GHC.Tuple.$tc(,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,)
Probable cause: bug in .hi-boot file, or inconsistent .hi file
Use -ddump-if-trace to get an idea of which file caused the error
|
1 | module Bug1 where
| ^
```
* ```hs
{-# LANGUAGE DataKinds #-}
module Bug2 where
import Data.Proxy
data T2 = MkT2 (Proxy
'( Int, Int, Int, Int, Int, Int, Int, Int, Int, Int
, Int, Int, Int, Int, Int, Int, Int, Int, Int, Int
, Int, Int, Int, Int, Int, Int, Int, Int, Int, Int
, Int, Int, Int, Int, Int, Int, Int, Int, Int, Int
, Int, Int, Int, Int, Int, Int, Int, Int, Int, Int
, Int, Int, Int, Int, Int, Int, Int, Int, Int, Int
, Int, Int, Int
))
```
```
$ /opt/ghc/8.10.2/bin/ghc Bug2.hs
[1 of 1] Compiling Bug2 ( Bug2.hs, Bug2.o )
Bug2.hs:1:1: error:
Can't find interface-file declaration for variable GHC.Tuple.$tc(,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,)
Probable cause: bug in .hi-boot file, or inconsistent .hi file
Use -ddump-if-trace to get an idea of which file caused the error
|
1 | {-# LANGUAGE DataKinds #-}
| ^
```
* ```hs
{-# LANGUAGE UnboxedTuples #-}
module Bug3 where
data T3 = MkT3
(# Int, Int, Int, Int, Int, Int, Int, Int, Int, Int
, Int, Int, Int, Int, Int, Int, Int, Int, Int, Int
, Int, Int, Int, Int, Int, Int, Int, Int, Int, Int
, Int, Int, Int, Int, Int, Int, Int, Int, Int, Int
, Int, Int, Int, Int, Int, Int, Int, Int, Int, Int
, Int, Int, Int, Int, Int, Int, Int, Int, Int, Int
, Int, Int, Int
#)
```
```
$ /opt/ghc/8.10.2/bin/ghc Bug3.hs
[1 of 1] Compiling Bug3 ( Bug3.hs, Bug3.o )
Bug3.hs:1:1: error:
Can't find interface-file declaration for variable GHC.Types.$tc(#,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,#)
Probable cause: bug in .hi-boot file, or inconsistent .hi file
Use -ddump-if-trace to get an idea of which file caused the error
|
1 | {-# LANGUAGE UnboxedTuples #-}
| ^
```
Interestingly, the following programs do _not_ throw a "Can't find interface-file declaration" error:
* ```hs
{-# LANGUAGE ConstraintKinds #-}
module Bug4 where
import Data.Proxy
data T4 = MkT4 (Proxy
(( Show Int, Show Int, Show Int, Show Int, Show Int, Show Int, Show Int, Show Int, Show Int, Show Int
, Show Int, Show Int, Show Int, Show Int, Show Int, Show Int, Show Int, Show Int, Show Int, Show Int
, Show Int, Show Int, Show Int, Show Int, Show Int, Show Int, Show Int, Show Int, Show Int, Show Int
, Show Int, Show Int, Show Int, Show Int, Show Int, Show Int, Show Int, Show Int, Show Int, Show Int
, Show Int, Show Int, Show Int, Show Int, Show Int, Show Int, Show Int, Show Int, Show Int, Show Int
, Show Int, Show Int, Show Int, Show Int, Show Int, Show Int, Show Int, Show Int, Show Int, Show Int
, Show Int, Show Int, Show Int
)))
```
```
$ /opt/ghc/8.10.2/bin/ghc Bug4.hs
[1 of 1] Compiling Bug4 ( Bug4.hs, Bug4.o )
Bug4.hs:7:3: error:
• Constraint tuple arity too large: 63 (max arity = 62)
Instead, use a nested tuple
• In the first argument of ‘Proxy’, namely
‘((Show Int, Show Int, Show Int, Show Int, Show Int, Show Int,
Show Int, Show Int, Show Int, Show Int, Show Int, Show Int,
Show Int, Show Int, Show Int, Show Int, Show Int, Show Int,
Show Int, Show Int, Show Int, Show Int, Show Int, Show Int,
Show Int, Show Int, Show Int, Show Int, Show Int, Show Int,
Show Int, Show Int, Show Int, Show Int, Show Int, Show Int,
Show Int, Show Int, Show Int, Show Int, Show Int, Show Int,
Show Int, Show Int, Show Int, Show Int, Show Int, Show Int,
Show Int, Show Int, Show Int, Show Int, Show Int, Show Int,
Show Int, Show Int, Show Int, Show Int, Show Int, Show Int,
Show Int, Show Int, Show Int))’
In the type ‘(Proxy ((Show Int, Show Int, Show Int, Show Int,
Show Int, Show Int, Show Int, Show Int, Show Int, Show Int,
Show Int, Show Int, Show Int, Show Int, Show Int, Show Int,
Show Int, Show Int, Show Int, Show Int, Show Int, Show Int,
Show Int, Show Int, Show Int, Show Int, Show Int, Show Int,
Show Int, Show Int, Show Int, Show Int, Show Int, Show Int,
Show Int, Show Int, Show Int, Show Int, Show Int, Show Int,
Show Int, Show Int, Show Int, Show Int, Show Int, Show Int,
Show Int, Show Int, Show Int, Show Int, Show Int, Show Int,
Show Int, Show Int, Show Int, Show Int, Show Int, Show Int,
Show Int, Show Int, Show Int, Show Int, Show Int)))’
In the definition of data constructor ‘MkT4’
|
7 | (( Show Int, Show Int, Show Int, Show Int, Show Int, Show Int, Show Int, Show Int, Show Int, Show Int
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^...
```
The reason is that there is a dedicated validity check for large constraint tuples in [`GHC.Tc.Gen.HsType.finish_tuple`](https://gitlab.haskell.org/ghc/ghc/-/blob/a1f34d37b47826e86343e368a5c00f1a4b1f2bce/compiler/GHC/Tc/Gen/HsType.hs#L1189-1190), unlike for boxed or unboxed tuples.
* ```hs
module Bug5 where
f ::
( Int, Int, Int, Int, Int, Int, Int, Int, Int, Int
, Int, Int, Int, Int, Int, Int, Int, Int, Int, Int
, Int, Int, Int, Int, Int, Int, Int, Int, Int, Int
, Int, Int, Int, Int, Int, Int, Int, Int, Int, Int
, Int, Int, Int, Int, Int, Int, Int, Int, Int, Int
, Int, Int, Int, Int, Int, Int, Int, Int, Int, Int
, Int, Int, Int
)
f =
( 123, 123, 123, 123, 123, 123, 123, 123, 123, 123
, 123, 123, 123, 123, 123, 123, 123, 123, 123, 123
, 123, 123, 123, 123, 123, 123, 123, 123, 123, 123
, 123, 123, 123, 123, 123, 123, 123, 123, 123, 123
, 123, 123, 123, 123, 123, 123, 123, 123, 123, 123
, 123, 123, 123, 123, 123, 123, 123, 123, 123, 123
, 123, 123, 123
)
```
```
$ /opt/ghc/8.10.2/bin/ghc Bug5.hs
[1 of 1] Compiling Bug5 ( Bug5.hs, Bug5.o )
Bug5.hs:13:3: error:
A 63-tuple is too large for GHC
(max size is 62)
Workaround: use nested tuples or define a data type
|
13 | ( 123, 123, 123, 123, 123, 123, 123, 123, 123, 123
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^...
```
Using an overly large tuple _expression_ fails because there is a dedicated validity check ([`GHC.Rename.Utils.checkTupSize`](https://gitlab.haskell.org/ghc/ghc/-/blob/a1f34d37b47826e86343e368a5c00f1a4b1f2bce/compiler/GHC/Rename/Utils.hs#L441-448)) that is used when renaming tuple expressions and patterns. Curiously, the same check is _not_ used when renaming tuple types.
* ```hs
module Bug6 where
data T6 = MkT6
((,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,)
Int Int Int Int Int Int Int Int Int Int
Int Int Int Int Int Int Int Int Int Int
Int Int Int Int Int Int Int Int Int Int
Int Int Int Int Int Int Int Int Int Int
Int Int Int Int Int Int Int Int Int Int
Int Int Int Int Int Int Int Int Int Int
Int Int Int)
```
```
$ /opt/ghc/8.10.2/bin/ghc Bug6.hs
[1 of 1] Compiling Bug6 ( Bug6.hs, Bug6.o )
Bug6.hs:4:4: error:
A 63-tuple is too large for GHC
(max size is 62)
Workaround: use nested tuples or define a data type
|
4 | ((,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,)
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
```
This is because GHC goes through a different code path when renaming prefix applications of tuple types than when renaming mixfix tuple types, and the code for renaming prefix applications of tuple types [uses `checkTupSize`](https://gitlab.haskell.org/ghc/ghc/-/blob/a1f34d37b47826e86343e368a5c00f1a4b1f2bce/compiler/GHC/Rename/Env.hs#L286).
Perhaps we should use `checkTupSize` when renaming mixfix tuple types in `rnHsTyKi`?9.2.1https://gitlab.haskell.org/ghc/ghc/-/issues/18525Typeable can leak information about instances defined using DerivingVia2020-08-19T15:54:45ZZubinTypeable can leak information about instances defined using DerivingVia```haskell
{-# LANGUAGE GADTs #-}
{-# LANGUAGE DerivingVia #-}
module TypeableVia where
import Data.Typeable
data Typed where
Typed :: Typeable a => a -> Typed
class C a where
foo :: a -> Typed
newtype T a = T a
instance Typeabl...```haskell
{-# LANGUAGE GADTs #-}
{-# LANGUAGE DerivingVia #-}
module TypeableVia where
import Data.Typeable
data Typed where
Typed :: Typeable a => a -> Typed
class C a where
foo :: a -> Typed
newtype T a = T a
instance Typeable a => C (T a) where
foo = Typed
newtype Foo = Foo Int
deriving C via T Int
bar :: C a => a -> TypeRep
bar x = case foo x of
Typed t -> typeOf t
-- bar (Foo 1) == T Int
newtype Foo' = Foo' Int
instance C Foo' where
foo = Typed
-- bar (Foo' 1) == Foo'
```
At first glance, the instances for `C Foo` and `C Foo'` seem like they should be identical, but they are in fact quite distinct.
I'm not sure what exactly can be done about this.https://gitlab.haskell.org/ghc/ghc/-/issues/18185Unrelated error message triggered on absent kind annotation.2021-04-07T16:00:00ZpermeakraUnrelated error message triggered on absent kind annotation.## Summary
On some inputs GHC complains about error in hi-file, while actual problem is related to kind checking.
## Steps to reproduce
on loading of the attached file [testcase.hs](/uploads/c63b79f5f1800bc273f1f9404fbf3a63/testcase.h...## Summary
On some inputs GHC complains about error in hi-file, while actual problem is related to kind checking.
## Steps to reproduce
on loading of the attached file [testcase.hs](/uploads/c63b79f5f1800bc273f1f9404fbf3a63/testcase.hs) ghci-8.10.1 complains that
> Can't find interface-file declaration for variable GHC.Types.$tcOrdering
The error disappears on giving `ord` variable explicit kind signature like `(ord :: Ordering)`.
## Expected behavior
GHC should either infer kind of `ord` automagically or complain about inability to infer `ord`'s kind
## Environment
* GHC version used: 8.10.1 , ghcup
* Operating System: Ubuntu-18.04
* System Architecture: amd648.10.2https://gitlab.haskell.org/ghc/ghc/-/issues/18175Compiler panic when compiling Cabal with 8.10.1 and `dno-typeable-binds`2020-05-11T16:54:19ZAndreas KlebingerCompiler panic when compiling Cabal with 8.10.1 and `dno-typeable-binds`I wondered about the cost of `Typeable` (see #13261) bindings on real world code so wanted to do
the "Cabal test" (compiling cabal the library).
However this surprisingly triggered a panic instead.
```
Andi@___ MINGW64 ~/cabal-head/Cab...I wondered about the cost of `Typeable` (see #13261) bindings on real world code so wanted to do
the "Cabal test" (compiling cabal the library).
However this surprisingly triggered a panic instead.
```
Andi@___ MINGW64 ~/cabal-head/Cabal
$ ghc -O Setup.hs -fforce-recomp -dno-typeable-binds +RTS -s
[ 1 of 242] Compiling Distribution.Compat.Async ( Distribution\Compat\Async.hs, Distribution\Compat\Async.o )
GHC error in desugarer lookup in Distribution.Compat.Async:
attempting to use module `main:Distribution.Compat.Async' (.\Distribution\Compat\Async.hs) which is not loaded
ghc.exe: panic! (the 'impossible' happened)
(GHC version 8.10.1:
initDs
Please report this as a GHC bug: https://www.haskell.org/ghc/reportabug
750,182,440 bytes allocated in the heap
89,913,368 bytes copied during GC
24,635,776 bytes maximum residency (8 sample(s))
857,728 bytes maximum slop
49 MiB total memory in use (0 MB lost due to fragmentation)
Tot time (elapsed) Avg pause Max pause
Gen 0 308 colls, 0 par 0.094s 0.061s 0.0002s 0.0082s
Gen 1 8 colls, 0 par 0.062s 0.090s 0.0112s 0.0231s
TASKS: 5 (1 bound, 4 peak workers (4 total), using -N1)
SPARKS: 0 (0 converted, 0 overflowed, 0 dud, 0 GC'd, 0 fizzled)
INIT time 0.000s ( 0.000s elapsed)
MUT time 0.281s ( 2.163s elapsed)
GC time 0.156s ( 0.151s elapsed)
EXIT time 0.000s ( 0.000s elapsed)
Total time 0.438s ( 2.314s elapsed)
Alloc rate 2,667,315,342 bytes per MUT second
Productivity 64.3% of total user, 93.5% of total elapsed
```