GHC issueshttps://gitlab.haskell.org/kcsongor/ghc/-/issues2021-05-11T18:25:47Zhttps://gitlab.haskell.org/kcsongor/ghc/-/issues/29Does not build with ghc 92021-05-11T18:25:47ZJacco KrijnenDoes not build with ghc 9See comment below
<details>
<summary>original post</summary>
I'd very much like to try this out, but couldn't get it to build (this is probably just my inexperience with building GHC). Both `BuildFlavour = quick` and the default flavo...See comment below
<details>
<summary>original post</summary>
I'd very much like to try this out, but couldn't get it to build (this is probably just my inexperience with building GHC). Both `BuildFlavour = quick` and the default flavor result in scope errors such as:
```
compiler/stage1/build/GHC/Cmm/Parser.hs:482:24: error:
Not in scope: ‘Prelude.*’
No module named ‘Prelude’ is imported.
|
482 | bit_start = st Prelude.* 134
|
```
Which makes sense, because it seems the files are being compiled with `-XNoImplicitPrelude` and it's not being imported. Any suggestions?
</details>https://gitlab.haskell.org/kcsongor/ghc/-/issues/28Type Family fails to reduce without PolyKinds extension2021-02-23T12:15:30ZYu XuanchiType Family fails to reduce without PolyKinds extension## Summary
Sometimes without PolyKinds extension, type family fails to reduce to expected type.
## Steps to reproduce
```haskell
{-# LANGUAGE TypeFamilies #-}
{-# LANGUAGE UnsaturatedTypeFamilies #-}
module Test where
type famil...## Summary
Sometimes without PolyKinds extension, type family fails to reduce to expected type.
## Steps to reproduce
```haskell
{-# LANGUAGE TypeFamilies #-}
{-# LANGUAGE UnsaturatedTypeFamilies #-}
module Test where
type family Id (x :: *) :: * where
Id a = a
type family Apply (f :: * -> *) (x :: *) :: * where
Apply f x = f x
foo :: Apply Id String
foo = "foo"
```
Above code will produce compile error:
```haskell
Test.hs:13:7: error:
• Couldn't match type: Apply Id String
with: [Char]
Expected: Apply Id String
Actual: String
• In the expression: "foo"
In an equation for ‘foo’ foo = "foo"
|
13 | foo = "foo"
| ^^^^^
```
After adding the PolyKinds extension, everything works fine.https://gitlab.haskell.org/kcsongor/ghc/-/issues/27Data constructor ‘X’ has existential type variables, a context, or a speciali...2021-02-16T14:13:43ZkindaroData constructor ‘X’ has existential type variables, a context, or a specialised result type.Except it does not.
{-# language TypeFamilies #-}
data family X a :: *
data instance X a = X (a -> Int)
main = undefined
This example compiles with official GHC 8.10 and the the one from the recent official master bra...Except it does not.
{-# language TypeFamilies #-}
data family X a :: *
data instance X a = X (a -> Int)
main = undefined
This example compiles with official GHC 8.10 and the the one from the recent official master branch, but not with the one I built from your fork.
% ghc-8.11.0 X.hs
Loaded package environment from /home/kindaro/.ghc/x86_64-linux-8.11.0.20200910/environments/default
[1 of 1] Compiling Main ( X.hs, X.o )
X.hs:4:21: error:
• Data constructor ‘X’ has existential type variables, a context, or a specialised result type
X :: forall a. (a -> Int) -> X a
(Enable ExistentialQuantification or GADTs to allow this)
• In the definition of data constructor ‘X’
In the data instance declaration for ‘X’
|
4 | data instance X a = X (a -> Int)
| ^^^^^^^^^^^^
I initially noticed this error when trying to build `hashable` so you may check it as a real world example. If the extensions are enabled as it wants, there appears another, more cryptic error.
This is the version as reported:
% ghc-8.11.0 --version
The Glorious Glasgow Haskell Compilation System, version 8.11.0.20200910
I built it back in September, but I do not see any updates since then!https://gitlab.haskell.org/kcsongor/ghc/-/issues/26Reified function types use AppT (rather than AppKindT) to apply matchabilitie...2020-09-23T12:27:02ZRyan ScottReified function types use AppT (rather than AppKindT) to apply matchabilities to (->)If you run this program:
```hs
{-# LANGUAGE TemplateHaskell #-}
module Main where
import Language.Haskell.TH
main :: IO ()
main = do
putStrLn $(reify 'id >>= stringE . pprint)
putStrLn $(reify 'id >>= stringE . show)
```
It will ...If you run this program:
```hs
{-# LANGUAGE TemplateHaskell #-}
module Main where
import Language.Haskell.TH
main :: IO ()
main = do
putStrLn $(reify 'id >>= stringE . pprint)
putStrLn $(reify 'id >>= stringE . show)
```
It will output this:
```
GHC.Base.id :: forall (a_0 :: *) .
(->) 'GHC.Types.Unmatchable a_0 a_0
VarI GHC.Base.id (ForallT [KindedTV a_6989586621679019003 SpecifiedSpec StarT] [] (AppT (AppT (AppT ArrowT (PromotedT GHC.Types.Unmatchable)) (VarT a_6989586621679019003)) (VarT a_6989586621679019003))) Nothing
```
The type of `id` that is reported, `(->) 'Unmatchable a_0 a_0`, is rather strange, as it treats `Unmatchable` as if it were a visible argument to `(->)`. The last line reveals the likely culprit behind this oddity: the AST uses `AppT ArrowT (PromotedT GHC.Types.Unmatchable)` rather than `AppKindT ArrowT (PromotedT GHC.Types.Unmatchable)`, which is what I would have expected.Csongor KissCsongor Kisshttps://gitlab.haskell.org/kcsongor/ghc/-/issues/25GHC overquantifies matchabilities in data types' kinds when PolyKinds is enabled2020-09-17T13:06:29ZRyan ScottGHC overquantifies matchabilities in data types' kinds when PolyKinds is enabledIf I load this file into GHCi:
```hs
{-# LANGUAGE KindSignatures #-}
{-# LANGUAGE PolyKinds #-}
module Bug where
import Data.Kind
data T :: Type -> Type
```
The `:info` command reveals something strange:
```
λ> :set -fprint-explicit...If I load this file into GHCi:
```hs
{-# LANGUAGE KindSignatures #-}
{-# LANGUAGE PolyKinds #-}
module Bug where
import Data.Kind
data T :: Type -> Type
```
The `:info` command reveals something strange:
```
λ> :set -fprint-explicit-matchabilities
λ> :info T
type role T phantom
type T :: forall {t :: GHC.Types.Matchability}.
* -> @('GHC.Types.Matchable) *
data T a
-- Defined at Bug.hs:7:1
```
Note how the kind of `T` quantifies `t` but never uses it. Note that this only happens when `PolyKinds` is enabled, since disabling that extension will produce a more sensible kind for `T`:
```
λ> :info T
type role T phantom
type T :: * -> @('GHC.Types.Matchable) *
data T a
-- Defined at Bug.hs:7:1
```https://gitlab.haskell.org/kcsongor/ghc/-/issues/18Consider partial application of invisible arguments2020-09-17T13:11:24ZCsongor KissConsider partial application of invisible argumentsAt the moment, when a type family has an unmatchable invisible argument:
```haskell
type Foo :: forall (k :: Type). Type
type family Foo :: Type where
Foo @Char = Int
Foo @Bool = Int
```
the arguments always get instantiated...At the moment, when a type family has an unmatchable invisible argument:
```haskell
type Foo :: forall (k :: Type). Type
type family Foo :: Type where
Foo @Char = Int
Foo @Bool = Int
```
the arguments always get instantiated at the call sites, so `Foo` always means `Foo @k`. There are at least two reasons for changing this behaviour so `Foo` only gets partially instantiated based on the expected kind (like those constructors with matchable foralls):
1) Why not? If we can partially apply unmatchable visible arguments, we should be able to partially apply unmatchable invisible arguments.
2) It would help with error messages: https://gitlab.haskell.org/kcsongor/ghc/-/issues/14#note_296569
When
```haskell
type F1 :: forall k. k
type family F1 :: k
type F2 :: forall k. k
type F2 = F1 :: forall k. k
```
here `F1` has an unmatchable forall, and `F2` has a matchable forall. Thus, behind the scenes `F1` gets instantiated to `F1 @k0 :: k0` but it's expected to have kind `forall k. k` so we get a unification error between `k0 ~ forall k. k`
If, instead, `F1` was _not_ instantiated, then we would try to unify `forall k. @Unmatchable k` with `forall k. @Matchable k` and get a unification error between the matchabilities instead.Csongor KissCsongor Kisshttps://gitlab.haskell.org/kcsongor/ghc/-/issues/10Core Lint error with term-level matchable arrows2020-09-02T11:10:39ZRyan ScottCore Lint error with term-level matchable arrowsThe following code will produce an error when compiled with `-dcore-lint`:
```hs
{-# LANGUAGE DataKinds #-}
module Bug where
import GHC.Exts (Matchability(..))
f :: (->>) Matchable a a
f x = x
```
```
$ ghc-stage2 Bug.hs -dcore-lint
[...The following code will produce an error when compiled with `-dcore-lint`:
```hs
{-# LANGUAGE DataKinds #-}
module Bug where
import GHC.Exts (Matchability(..))
f :: (->>) Matchable a a
f x = x
```
```
$ ghc-stage2 Bug.hs -dcore-lint
[1 of 1] Compiling Bug ( Bug.hs, Bug.o )
*** Core Lint errors : in result of Desugar (before optimization) ***
Bug.hs:7:1: warning:
[RHS of f :: forall a. a -> a]
The type of this binder doesn't match the type of its RHS: f
Binder's type: forall a. a -> a
Rhs type: forall a. a ~> a
*** Offending Program ***
Rec {
$trModule :: Module
[LclIdX]
$trModule = Module (TrNameS "main"#) (TrNameS "Bug"#)
f :: forall a. a -> a
[LclIdX]
f = \ (@ a_a101) (x_aZQ :: a_a101) -> x_aZQ
end Rec }
*** End of Offense ***
<no location info>: error:
Compilation had errors
```https://gitlab.haskell.org/kcsongor/ghc/-/issues/8Unmatchable arrows and data constructor promotion2020-09-06T15:32:37ZRyan ScottUnmatchable arrows and data constructor promotionThis is halfway between a bug report and a design question. The immediate issue is that the following code works on current GHCs:
```hs
{-# LANGUAGE DataKinds #-}
module Bug where
import Data.Kind
data T = MkT (Type -> Type)
type S =...This is halfway between a bug report and a design question. The immediate issue is that the following code works on current GHCs:
```hs
{-# LANGUAGE DataKinds #-}
module Bug where
import Data.Kind
data T = MkT (Type -> Type)
type S = MkT Maybe
```
However, it fails on the `unsaturated_type_families` branch:
```
[1 of 1] Compiling Bug ( Bug.hs, Bug.o )
Bug.hs:8:14: error:
• Expected kind ‘* ~> *’, but ‘Maybe’ has kind ‘* -> *’
• In the first argument of ‘MkT’, namely ‘Maybe’
In the type ‘MkT Maybe’
In the type declaration for ‘S’
|
8 | type S = MkT Maybe
| ^^^^^
```
The cause appears to be that the `->` arrow in the type of `MkT`'s field gets renamed to `~>`, which is not changed back when `MkT` is promoted to a type. In other words, the type of `MkT` is `(Type ~> Type) ~> T`, but the kind of `'MkT` is `(Type ~> Type) -> T`.
Should it be promoted to `(Type -> Type) -> Type` instead? Granted, this is a bit of a thorny question since there's likely some use cases where you'd want one arrow and other use cases where you'd want the other arrow. As things currently stand, however, there is code that compiles in today's GHC but not with your branch, which is a bit suspicious.