GHC issueshttps://gitlab.haskell.org/ghc/ghc/-/issues2019-07-07T18:26:50Zhttps://gitlab.haskell.org/ghc/ghc/-/issues/12384Type family not reduced, again2019-07-07T18:26:50ZAndres LöhType family not reduced, againThis one looks similar to #12381, but unfortunately, it does not seem to be fixed in HEAD:
```hs
{-# LANGUAGE TypeInType, TypeFamilies, FlexibleInstances #-}
import GHC.Types
type family F (a :: Type) :: Type
class C a where
type D...This one looks similar to #12381, but unfortunately, it does not seem to be fixed in HEAD:
```hs
{-# LANGUAGE TypeInType, TypeFamilies, FlexibleInstances #-}
import GHC.Types
type family F (a :: Type) :: Type
class C a where
type D (a :: Type) :: F a
instance (F a ~ Bool) => C a where
type D a = True
```
This yields (in 8.0.1 and 8.1.20160709):
```
Constraint.hs:11:14: error:
• Expected kind ‘F a’, but ‘'True’ has kind ‘Bool’
• In the type ‘True’
In the type instance declaration for ‘D’
In the instance declaration for ‘C a’
```https://gitlab.haskell.org/ghc/ghc/-/issues/12382Rename clashing type variables more consistently2019-07-07T18:26:51ZJoachim Breitnermail@joachim-breitner.deRename clashing type variables more consistentlyThis is minor polishing, but polish is nice:
Consider
```
:t (id,id,id)
(id,id,id) :: (a -> a, a1 -> a1, a2 -> a2)
```
this looks as if the first `a` is in some way better or more important. What I’d like to see is
```
:t (id,id,id)
...This is minor polishing, but polish is nice:
Consider
```
:t (id,id,id)
(id,id,id) :: (a -> a, a1 -> a1, a2 -> a2)
```
this looks as if the first `a` is in some way better or more important. What I’d like to see is
```
:t (id,id,id)
(id,id,id) :: (a1 -> a2, a2 -> a2, a3 -> a3)
```
In other words: If two type variables clash and need to be renamed, then rename both (all) of them.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------------- |
| Version | 8.1 |
| Type | FeatureRequest |
| TypeOfFailure | OtherFailure |
| Priority | low |
| Resolution | Unresolved |
| Component | Compiler (Type checker) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Rename clasing type variables more consistently","status":"New","operating_system":"","component":"Compiler (Type checker)","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"FeatureRequest","description":"This is minor polishing, but polish is nice:\r\n\r\nConsider\r\n{{{\r\n:t (id,id,id)\r\n(id,id,id) :: (a -> a, a1 -> a1, a2 -> a2)\r\n}}}\r\nthis looks as if the first `a` is in some way better or more important. What I’d like to see is \r\n{{{\r\n:t (id,id,id)\r\n(id,id,id) :: (a1 -> a2, a2 -> a2, a3 -> a3)\r\n}}}\r\n\r\nIn other words: If two type variables clash and need to be renamed, then rename both (all) of them.","type_of_failure":"OtherFailure","blocking":[]} -->8.2.1Joachim Breitnermail@joachim-breitner.deJoachim Breitnermail@joachim-breitner.dehttps://gitlab.haskell.org/ghc/ghc/-/issues/12381Type family not reduced2019-07-07T18:26:51ZBen GamariType family not reducedAndres pointed out that the following fails to compile with GHC 8.0.1 but succeeds with `master` (f53d761df9762232b54ec57a950d301011cd21f8),
```hs
{-# LANGUAGE TypeInType, TypeFamilies #-}
module Kinds where
import GHC.Types
type fami...Andres pointed out that the following fails to compile with GHC 8.0.1 but succeeds with `master` (f53d761df9762232b54ec57a950d301011cd21f8),
```hs
{-# LANGUAGE TypeInType, TypeFamilies #-}
module Kinds where
import GHC.Types
type family G (a :: Type) :: Type
type instance G Int = Bool
type family F (a :: Type) :: G a
type instance F Int = True
```
Error:
```
Hi.hs:10:23: error:
• Expected kind ‘G Int’, but ‘'True’ has kind ‘Bool’
• In the type ‘True’
In the type instance declaration for ‘F’
```
We should figure out what fixed this so it can hopefully be merged for 8.0.2. I initially suspected the patch cited in #12175 but sadly this doesn't seem to be the case.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------------- |
| Version | 8.0.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler (Type checker) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Type family not reduced","status":"New","operating_system":"","component":"Compiler (Type checker)","related":[],"milestone":"8.0.2","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.0.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Andres pointed out that the following fails to compile with GHC 8.0.1 but succeeds with `master` (f53d761df9762232b54ec57a950d301011cd21f8),\r\n\r\n{{{#!hs\r\n{-# LANGUAGE TypeInType, TypeFamilies #-}\r\nmodule Kinds where\r\n\r\nimport GHC.Types\r\n\r\ntype family G (a :: Type) :: Type\r\ntype instance G Int = Bool\r\n\r\ntype family F (a :: Type) :: G a\r\ntype instance F Int = True\r\n}}}\r\n\r\nError:\r\n{{{\r\nHi.hs:10:23: error:\r\n • Expected kind ‘G Int’, but ‘'True’ has kind ‘Bool’\r\n • In the type ‘True’\r\n In the type instance declaration for ‘F’\r\n}}}\r\n\r\nWe should figure out what fixed this so it can hopefully be merged for 8.0.2. I initially suspected the patch cited in #12175 but sadly this doesn't seem to be the case.","type_of_failure":"OtherFailure","blocking":[]} -->8.2.1https://gitlab.haskell.org/ghc/ghc/-/issues/12380ghc: panic! (the 'impossible' happened)2019-07-07T18:26:51ZHassan58ghc: panic! (the 'impossible' happened)While building package yesod-auth-1.4.13.3 using:
```
/Users/hassanshahin/.stack/setup-exe-cache/x86_64-osx/setup-Simple-Cabal-1.22.5.0-ghc-7.10.3 --builddir=.stack-work/dist/x86_64-osx/Cabal-1.22.5.0 build --ghc-options " -ddump-...While building package yesod-auth-1.4.13.3 using:
```
/Users/hassanshahin/.stack/setup-exe-cache/x86_64-osx/setup-Simple-Cabal-1.22.5.0-ghc-7.10.3 --builddir=.stack-work/dist/x86_64-osx/Cabal-1.22.5.0 build --ghc-options " -ddump-hi -ddump-to-file"
Process exited with code: ExitFailure 1
Logs have been written to: /Users/hassanshahin/my-project/.stack-work/logs/yesod-auth-1.4.13.3.log
Configuring yesod-auth-1.4.13.3...
Building yesod-auth-1.4.13.3...
Preprocessing library yesod-auth-1.4.13.3...
[ 1 of 12] Compiling Yesod.PasswordStore ( Yesod/PasswordStore.hs, .stack-work/dist/x86_64-osx/Cabal-1.22.5.0/build/Yesod/PasswordStore.o )
/private/var/folders/g5/5wkx70392bs5gv_5tvvwbl180000gn/T/stack72472/yesod-auth-1.4.13.3/Yesod/PasswordStore.hs:166:31: Warning:
Defaulting the following constraint(s) to type ‘Integer’
(Integral b0)
arising from a use of ‘^’ at Yesod/PasswordStore.hs:166:31
(Num b0)
arising from the literal ‘32’ at Yesod/PasswordStore.hs:166:32-33
In the first argument of ‘(-)’, namely ‘2 ^ 32’
In the first argument of ‘(*)’, namely ‘(2 ^ 32 - 1)’
In the second argument of ‘(>)’, namely ‘(2 ^ 32 - 1) * hLen’
/private/var/folders/g5/5wkx70392bs5gv_5tvvwbl180000gn/T/stack72472/yesod-auth-1.4.13.3/Yesod/PasswordStore.hs:419:1: Warning:
Defined but not used: ‘toStrict’
/private/var/folders/g5/5wkx70392bs5gv_5tvvwbl180000gn/T/stack72472/yesod-auth-1.4.13.3/Yesod/PasswordStore.hs:422:1: Warning:
Defined but not used: ‘fromStrict’
[ 2 of 12] Compiling Yesod.Auth.Message ( Yesod/Auth/Message.hs, .stack-work/dist/x86_64-osx/Cabal-1.22.5.0/build/Yesod/Auth/Message.o )
/private/var/folders/g5/5wkx70392bs5gv_5tvvwbl180000gn/T/stack72472/yesod-auth-1.4.13.3/Yesod/Auth/Message.hs:23:1: Warning:
The import of ‘mappend’ from module ‘Data.Monoid’ is redundant
/private/var/folders/g5/5wkx70392bs5gv_5tvvwbl180000gn/T/stack72472/yesod-auth-1.4.13.3/Yesod/Auth/Message.hs:698:1: Warning:
Defined but not used: ‘croatianMessage’
/private/var/folders/g5/5wkx70392bs5gv_5tvvwbl180000gn/T/stack72472/yesod-auth-1.4.13.3/Yesod/Auth/Message.hs:459:1: Warning:
Pattern match(es) are overlapped
In an equation for ‘finnishMessage’: finnishMessage Password = ...
/private/var/folders/g5/5wkx70392bs5gv_5tvvwbl180000gn/T/stack72472/yesod-auth-1.4.13.3/Yesod/Auth/Message.hs:459:1: Warning:
Pattern match(es) are non-exhaustive
In an equation for ‘finnishMessage’:
Patterns not matched: CurrentPassword
[ 3 of 12] Compiling Yesod.Auth.Routes ( Yesod/Auth/Routes.hs, .stack-work/dist/x86_64-osx/Cabal-1.22.5.0/build/Yesod/Auth/Routes.o )
[ 4 of 12] Compiling Yesod.Auth ( Yesod/Auth.hs, .stack-work/dist/x86_64-osx/Cabal-1.22.5.0/build/Yesod/Auth.o )
ghc: panic! (the 'impossible' happened)
(GHC version 7.10.3 for x86_64-apple-darwin):
Loading temp shared object failed: dlopen(/var/folders/g5/5wkx70392bs5gv_5tvvwbl180000gn/T/ghc72516_0/libghc_21.dylib, 5): no suitable image found. Did find:
/var/folders/g5/5wkx70392bs5gv_5tvvwbl180000gn/T/ghc72516_0/libghc_21.dylib: malformed mach-o: load commands size (36488) > 32768
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
```https://gitlab.haskell.org/ghc/ghc/-/issues/12379WARN pragma gives warning `warning: [-Wdeprecations]'2019-07-07T18:26:52ZZilin Chenzilin.chen@data61.csiro.auWARN pragma gives warning `warning: [-Wdeprecations]'Example:
```hs
-- Warn.hs
module Warn where
__todo :: String -> a
{-# WARNING __todo "TODO" #-}
__todo msg = error $ "TODO: " ++ msg
```
```hs
-- Main.hs
{- OPTIONS_GHC -Wall #-}
import Warn
inc :: Int -> Int
inc n | n >= 0 = n + ...Example:
```hs
-- Warn.hs
module Warn where
__todo :: String -> a
{-# WARNING __todo "TODO" #-}
__todo msg = error $ "TODO: " ++ msg
```
```hs
-- Main.hs
{- OPTIONS_GHC -Wall #-}
import Warn
inc :: Int -> Int
inc n | n >= 0 = n + 1
inc _ = __todo "what about negatives?"
```
When compile the files (or ghci), I get
```
UseWarn.hs:9:9: warning: [-Wdeprecations]
In the use of ‘__todo’ (imported from Warn): "TODO"
```
Should the flag be `-Wwarnings-deprecations`? And `-Wdeprecations` is not in the user guide, if it is a genuine flag.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ---------------- |
| Version | 8.0.1 |
| Type | Bug |
| TypeOfFailure | IncorrectWarning |
| Priority | low |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | Linux |
| Architecture | x86_64 (amd64) |
</details>
<!-- {"blocked_by":[],"summary":"WARN pragma gives warning `warning: [-Wdeprecations]'","status":"New","operating_system":"Linux","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.0.1","keywords":[],"differentials":[],"test_case":"","architecture":"x86_64 (amd64)","cc":[""],"type":"Bug","description":"Example:\r\n\r\n{{{#!hs\r\n-- Warn.hs\r\n\r\nmodule Warn where\r\n\r\n__todo :: String -> a\r\n{-# WARNING __todo \"TODO\" #-}\r\n__todo msg = error $ \"TODO: \" ++ msg\r\n}}}\r\n\r\n{{{#!hs\r\n-- Main.hs\r\n\r\n{- OPTIONS_GHC -Wall #-}\r\n\r\nimport Warn\r\n\r\ninc :: Int -> Int\r\ninc n | n >= 0 = n + 1\r\ninc _ = __todo \"what about negatives?\"\r\n}}}\r\n\r\nWhen compile the files (or ghci), I get\r\n{{{\r\nUseWarn.hs:9:9: warning: [-Wdeprecations]\r\n In the use of ‘__todo’ (imported from Warn): \"TODO\"\r\n}}}\r\n\r\nShould the flag be `-Wwarnings-deprecations`? And `-Wdeprecations` is not in the user guide, if it is a genuine flag.","type_of_failure":"IncorrectWarning","blocking":[]} -->8.2.1https://gitlab.haskell.org/ghc/ghc/-/issues/12378Not enough inlining happens with single-method type classes2019-07-07T18:26:52Ztakano-akioNot enough inlining happens with single-method type classesIn the attached file, GHC produces code (with `-O2`) for `foo` that references a top-level definition of type `Small (Either () ())`, despite the fact that all bindings in the module are marked INLINE.
If I use `-DOTHER_METHOD` to add a...In the attached file, GHC produces code (with `-O2`) for `foo` that references a top-level definition of type `Small (Either () ())`, despite the fact that all bindings in the module are marked INLINE.
If I use `-DOTHER_METHOD` to add another method to the class, this problem goes away. It looks like a ClassOp rule is helping here.
I'm not sure if this is a bug, but it was a surprising behavior for me, so I'm reporting it. Please feel free to close this ticket if it's the correct behavior.
<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":"Not enough inlining happens with single-method type classes","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":"In the attached file, GHC produces code (with `-O2`) for `foo` that references a top-level definition of type `Small (Either () ())`, despite the fact that all bindings in the module are marked INLINE.\r\n\r\nIf I use `-DOTHER_METHOD` to add another method to the class, this problem goes away. It looks like a ClassOp rule is helping here.\r\n\r\nI'm not sure if this is a bug, but it was a surprising behavior for me, so I'm reporting it. Please feel free to close this ticket if it's the correct behavior.","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/12377getExecutablePath doesn't return absolute path on OpenBSD (and maybe other OS...2022-07-24T07:02:04ZoherralagetExecutablePath doesn't return absolute path on OpenBSD (and maybe other OS also)System.Environment.getExecutablePath doesn't return absolute path to executable in OpenBSD. This happens because getExecutablePath uses argv\[0\] to determine path and argv\[0\] might not be absolute path.
My environment:
```
$ uname -...System.Environment.getExecutablePath doesn't return absolute path to executable in OpenBSD. This happens because getExecutablePath uses argv\[0\] to determine path and argv\[0\] might not be absolute path.
My environment:
```
$ uname -a
OpenBSD fizbuz.pilkki.ciz.fi 6.0 GENERIC.MP#2274 amd64
$ ghc -V
The Glorious Glasgow Haskell Compilation System, version 7.10.3
```
This test program in OpenBSD:
```hs
module Main where
import System.Environment
main = getExecutablePath >>= print
```
returns
```
$ ./test
"./test"
```
For example in OS X the call returns absolute path:
```
$ ./test
"/Users/oherrala/tmp/test"
```
OpenBSD is one of the operating systems which gets fall back to using argv\[0\] to determine exec's location:
https://git.haskell.org/ghc.git/blob/HEAD:/libraries/base/System/Environment/ExecutablePath.hsc\#l152
Maybe the argv\[0\] result should be wrapped with realpath(3) to get absolute path?
This bug is also present in cabal-install and reported here: https://github.com/haskell/cabal/issues/3512\#issuecomment-231604356
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 8.0.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | libraries/base |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"getExecutablePath doesn't return absolute path on OpenBSD (and maybe other OS also)","status":"New","operating_system":"","component":"libraries/base","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.0.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"System.Environment.getExecutablePath doesn't return absolute path to executable in OpenBSD. This happens because getExecutablePath uses argv[0] to determine path and argv[0] might not be absolute path.\r\n\r\nMy environment:\r\n\r\n{{{\r\n$ uname -a\r\nOpenBSD fizbuz.pilkki.ciz.fi 6.0 GENERIC.MP#2274 amd64\r\n$ ghc -V\r\nThe Glorious Glasgow Haskell Compilation System, version 7.10.3\r\n}}}\r\n\r\nThis test program in OpenBSD:\r\n\r\n{{{#!hs\r\nmodule Main where\r\nimport System.Environment\r\nmain = getExecutablePath >>= print\r\n}}}\r\n\r\nreturns\r\n\r\n{{{\r\n$ ./test\r\n\"./test\"\r\n}}}\r\n\r\nFor example in OS X the call returns absolute path:\r\n\r\n{{{\r\n$ ./test\r\n\"/Users/oherrala/tmp/test\"\r\n}}}\r\n\r\nOpenBSD is one of the operating systems which gets fall back to using argv[0] to determine exec's location:\r\n\r\nhttps://git.haskell.org/ghc.git/blob/HEAD:/libraries/base/System/Environment/ExecutablePath.hsc#l152\r\n\r\nMaybe the argv[0] result should be wrapped with realpath(3) to get absolute path?\r\n\r\n\r\nThis bug is also present in cabal-install and reported here: https://github.com/haskell/cabal/issues/3512#issuecomment-231604356\r\n","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/12375type synonym to unboxed tuple causes crash2019-07-07T18:26:53ZÖmer Sinan Ağacantype synonym to unboxed tuple causes crash```haskell
{-# LANGUAGE UnboxedTuples #-}
module Main where
-- type Null = (# #)
{-# NOINLINE showNull #-}
showNull :: (# #) -> String
showNull (# #) = "(# #)"
{-# NOINLINE showNullPair #-}
showNullPair :: (# (# #), (# #) #) -> Strin...```haskell
{-# LANGUAGE UnboxedTuples #-}
module Main where
-- type Null = (# #)
{-# NOINLINE showNull #-}
showNull :: (# #) -> String
showNull (# #) = "(# #)"
{-# NOINLINE showNullPair #-}
showNullPair :: (# (# #), (# #) #) -> String
showNullPair (# n1, n2 #) = "(# " ++ showNull n1 ++ ", " ++ showNull n2 ++ "#)"
main :: IO ()
main = do
putStrLn (showNullPair (# (# #), (# #) #))
```
If I use the `Null` type synonym here instead of `(# #)`, I get:
```
[1 of 1] Compiling Main ( empty.hs, empty.o )
ghc: panic! (the 'impossible' happened)
(GHC version 8.0.1 for x86_64-unknown-linux):
unboxed tuple PrimRep
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
```
Tried with: 8.0.1
<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":"type synonym to unboxed tuple causes crash","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":"{{{#!haskell\r\n{-# LANGUAGE UnboxedTuples #-}\r\n\r\nmodule Main where\r\n\r\n-- type Null = (# #)\r\n\r\n{-# NOINLINE showNull #-}\r\nshowNull :: (# #) -> String\r\nshowNull (# #) = \"(# #)\"\r\n\r\n{-# NOINLINE showNullPair #-}\r\nshowNullPair :: (# (# #), (# #) #) -> String\r\nshowNullPair (# n1, n2 #) = \"(# \" ++ showNull n1 ++ \", \" ++ showNull n2 ++ \"#)\"\r\n\r\nmain :: IO ()\r\nmain = do\r\n putStrLn (showNullPair (# (# #), (# #) #))\r\n}}}\r\n\r\nIf I use the `Null` type synonym here instead of `(# #)`, I get:\r\n\r\n{{{\r\n[1 of 1] Compiling Main ( empty.hs, empty.o )\r\nghc: panic! (the 'impossible' happened)\r\n (GHC version 8.0.1 for x86_64-unknown-linux):\r\n unboxed tuple PrimRep\r\n\r\nPlease report this as a GHC bug: http://www.haskell.org/ghc/reportabug\r\n}}}\r\n\r\nTried with: 8.0.1","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/12374Type holes show incorrect type in GHCi2019-07-07T18:26:53ZEric CrockettType holes show incorrect type in GHCiIn a fresh GHCi:
```
> show _
<interactive>:7:6: error:
• Found hole: _h :: ()
Or perhaps ‘_h’ is mis-spelled, or not in scope
• In the first argument of ‘show’, namely ‘_h’
In the expression: show _h
In an eq...In a fresh GHCi:
```
> show _
<interactive>:7:6: error:
• Found hole: _h :: ()
Or perhaps ‘_h’ is mis-spelled, or not in scope
• In the first argument of ‘show’, namely ‘_h’
In the expression: show _h
In an equation for ‘it’: it = show _h
• Relevant bindings include
it :: String (bound at <interactive>:7:1)
```
This seems wrong: the type of the hole is `_h :: Show a0 => a0`, not `_h :: ()`.
On a related note, should this be reporting two errors (one for the hole, one for the constraint) as in #9479?
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.0.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | GHCi |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Type holes show incorrect type in GHCi","status":"New","operating_system":"","component":"GHCi","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.0.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"In a fresh GHCi:\r\n\r\n{{{\r\n> show _\r\n\r\n<interactive>:7:6: error:\r\n • Found hole: _h :: ()\r\n Or perhaps ‘_h’ is mis-spelled, or not in scope\r\n • In the first argument of ‘show’, namely ‘_h’\r\n In the expression: show _h\r\n In an equation for ‘it’: it = show _h\r\n • Relevant bindings include\r\n it :: String (bound at <interactive>:7:1)\r\n}}}\r\n\r\nThis seems wrong: the type of the hole is `_h :: Show a0 => a0`, not `_h :: ()`.\r\n\r\nOn a related note, should this be reporting two errors (one for the hole, one for the constraint) as in #9479?","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/12373Type error but types match2019-07-07T18:26:53ZÖmer Sinan AğacanType error but types match```
> unboxedsums git:(prim_sums_rebase_5) x cat primop_bug.hs
{-# LANGUAGE MagicHash, ScopedTypeVariables, UnboxedTuples #-}
module Main where
import GHC.MVar
import GHC.Prim
import GHC.Types
main :: IO ()
main = IO (\rw -> newMVar# ...```
> unboxedsums git:(prim_sums_rebase_5) x cat primop_bug.hs
{-# LANGUAGE MagicHash, ScopedTypeVariables, UnboxedTuples #-}
module Main where
import GHC.MVar
import GHC.Prim
import GHC.Types
main :: IO ()
main = IO (\rw -> newMVar# rw) >> return ()
> unboxedsums git:(prim_sums_rebase_5) x ghc-stage1 primop_bug.hs -ddump-stg -ddump-cmm -ddump-to-file -fforce-recomp -dumpdir primop_fails -O -fprint-explicit-kinds
[1 of 1] Compiling Main ( primop_bug.hs, primop_bug.o )
primop_bug.hs:10:19: error:
• Couldn't match a lifted type with an unlifted type
Expected type: (# State# RealWorld, MVar# RealWorld a0 #)
Actual type: (# State# RealWorld, MVar# RealWorld a0 #)
• In the expression: newMVar# rw
In the first argument of ‘IO’, namely ‘(\ rw -> newMVar# rw)’
In the first argument of ‘(>>)’, namely ‘IO (\ rw -> newMVar# rw)’
```
Tried with HEAD, 8.0.1.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------------- |
| Version | 8.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler (Type checker) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Type error but types match","status":"New","operating_system":"","component":"Compiler (Type checker)","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"{{{\r\n> unboxedsums git:(prim_sums_rebase_5) x cat primop_bug.hs\r\n{-# LANGUAGE MagicHash, ScopedTypeVariables, UnboxedTuples #-}\r\n\r\nmodule Main where\r\n\r\nimport GHC.MVar\r\nimport GHC.Prim\r\nimport GHC.Types\r\n\r\nmain :: IO ()\r\nmain = IO (\\rw -> newMVar# rw) >> return ()\r\n\r\n> unboxedsums git:(prim_sums_rebase_5) x ghc-stage1 primop_bug.hs -ddump-stg -ddump-cmm -ddump-to-file -fforce-recomp -dumpdir primop_fails -O -fprint-explicit-kinds\r\n[1 of 1] Compiling Main ( primop_bug.hs, primop_bug.o )\r\n\r\nprimop_bug.hs:10:19: error:\r\n • Couldn't match a lifted type with an unlifted type\r\n Expected type: (# State# RealWorld, MVar# RealWorld a0 #)\r\n Actual type: (# State# RealWorld, MVar# RealWorld a0 #)\r\n • In the expression: newMVar# rw\r\n In the first argument of ‘IO’, namely ‘(\\ rw -> newMVar# rw)’\r\n In the first argument of ‘(>>)’, namely ‘IO (\\ rw -> newMVar# rw)’\r\n}}}\r\n\r\nTried with HEAD, 8.0.1.","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/12372bug: documentation for Control.Monad.guard not useful after AMP2019-07-07T18:26:53ZNathan Collinsbug: documentation for Control.Monad.guard not useful after AMPSince the AMP refactor, the documentation for `Control.Monad.guard` \[1\] is no longer useful for beginners. It simply gives the definition of `guard`, but in prose:
```
guard b is pure () if b is True, and empty if b is False.
```
(an...Since the AMP refactor, the documentation for `Control.Monad.guard` \[1\] is no longer useful for beginners. It simply gives the definition of `guard`, but in prose:
```
guard b is pure () if b is True, and empty if b is False.
```
(and better to just use Haskell instead of prose here, no?)
To use `guard` in a `MonadPlus`, you now need to know that `Alternative` is a super class of `MonadPlus`, and that `mzero = zero`. The documentation \[2\] for `MonadPlus` doens't mention `mzero = zero` in the default definition -- you must look at the source for that -- and the docs for `guard` don't mention `MonadPlus`.
The documentation for `Control.Monad.guard` should suggest use with `MonadPlus`, and give an example (compare with the very helpful example for `Control.Monad.when`). A non-monadic example would also be useful.
\[1\] https://hackage.haskell.org/package/base-4.9.0.0/docs/Control-Monad.html\#v:guard
\[2\] https://hackage.haskell.org/package/base-4.9.0.0/docs/Control-Monad.html\#t:MonadPlus
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 8.0.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | libraries/base |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"bug: documentation for Control.Monad.guard not useful after AMP","status":"New","operating_system":"","component":"libraries/base","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.0.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Since the AMP refactor, the documentation for `Control.Monad.guard` [1] is no longer useful for beginners. It simply gives the definition of `guard`, but in prose:\r\n{{{\r\nguard b is pure () if b is True, and empty if b is False.\r\n}}}\r\n(and better to just use Haskell instead of prose here, no?)\r\n\r\nTo use `guard` in a `MonadPlus`, you now need to know that `Alternative` is a super class of `MonadPlus`, and that `mzero = zero`. The documentation [2] for `MonadPlus` doens't mention `mzero = zero` in the default definition -- you must look at the source for that -- and the docs for `guard` don't mention `MonadPlus`.\r\n\r\nThe documentation for `Control.Monad.guard` should suggest use with `MonadPlus`, and give an example (compare with the very helpful example for `Control.Monad.when`). A non-monadic example would also be useful.\r\n\r\n[1] https://hackage.haskell.org/package/base-4.9.0.0/docs/Control-Monad.html#v:guard\r\n\r\n[2] https://hackage.haskell.org/package/base-4.9.0.0/docs/Control-Monad.html#t:MonadPlus","type_of_failure":"OtherFailure","blocking":[]} -->8.4.1https://gitlab.haskell.org/ghc/ghc/-/issues/12371Error message, room for improvement2019-07-07T18:26:53ZIcelandjackError message, room for improvement```
$ ghci -ignore-dot-ghci
GHCi, version 8.0.1: http://www.haskell.org/ghc/ :? for help
Prelude> :set -XPatternSynonyms
Prelude> :set -XViewPatterns
Prelude> pattern Foo a <- ((\uncons -> Just (a, as) -> a) -> a)
<interactive>:3:20:...```
$ ghci -ignore-dot-ghci
GHCi, version 8.0.1: http://www.haskell.org/ghc/ :? for help
Prelude> :set -XPatternSynonyms
Prelude> :set -XViewPatterns
Prelude> pattern Foo a <- ((\uncons -> Just (a, as) -> a) -> a)
<interactive>:3:20: error:
Pattern syntax in expression context: \ uncons -> Just (a, as) -> a
Did you mean to enable TypeApplications?
```
Let's:
```
Prelude> :set -XTypeApplications
Prelude> pattern Foo a <- ((\uncons -> Just (a, as) -> a) -> a)
<interactive>:5:20: error:
Pattern syntax in expression context: \ uncons -> Just (a, as) -> a
Did you mean to enable TypeApplications?
Prelude>
```
<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":"Error message, room for improvement","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.0.1","keywords":["TypeApplications"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"{{{\r\n$ ghci -ignore-dot-ghci\r\nGHCi, version 8.0.1: http://www.haskell.org/ghc/ :? for help\r\nPrelude> :set -XPatternSynonyms \r\nPrelude> :set -XViewPatterns \r\nPrelude> pattern Foo a <- ((\\uncons -> Just (a, as) -> a) -> a)\r\n\r\n<interactive>:3:20: error:\r\n Pattern syntax in expression context: \\ uncons -> Just (a, as) -> a\r\n Did you mean to enable TypeApplications?\r\n}}}\r\n\r\nLet's:\r\n{{{\r\nPrelude> :set -XTypeApplications\r\nPrelude> pattern Foo a <- ((\\uncons -> Just (a, as) -> a) -> a)\r\n\r\n<interactive>:5:20: error:\r\n Pattern syntax in expression context: \\ uncons -> Just (a, as) -> a\r\n Did you mean to enable TypeApplications?\r\nPrelude> \r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->8.0.2https://gitlab.haskell.org/ghc/ghc/-/issues/12370Implement LetUp in DmdAnal (or document why we do not do it)2019-07-07T18:26:54ZJoachim Breitnermail@joachim-breitner.deImplement LetUp in DmdAnal (or document why we do not do it)The paper “Modular, Higher-Order Cardinality Analysis in Theory and Practice” has two rules for analizing let-bindings: LetDown, used for functions, that determines the function’s strictness signature, and passes it down, and LetUp, used...The paper “Modular, Higher-Order Cardinality Analysis in Theory and Practice” has two rules for analizing let-bindings: LetDown, used for functions, that determines the function’s strictness signature, and passes it down, and LetUp, used for thunks, which uses the demand coming from the scope.
The implementation uses only LetDown for all let-bindings.
I wonder why this is so. I implemented something that looks like LetUp and will validate and performance-test it soon, in order to either make the implementation match the analysis, or alternatively document why this is the case.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.1 |
| Type | Task |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | ilya |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Implement LetUp in DmdAnal (or document why we do not do it)","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["ilya"],"type":"Task","description":"The paper “Modular, Higher-Order Cardinality Analysis in Theory and Practice” has two rules for analizing let-bindings: LetDown, used for functions, that determines the function’s strictness signature, and passes it down, and LetUp, used for thunks, which uses the demand coming from the scope.\r\n\r\nThe implementation uses only LetDown for all let-bindings.\r\n\r\nI wonder why this is so. I implemented something that looks like LetUp and will validate and performance-test it soon, in order to either make the implementation match the analysis, or alternatively document why this is the case.","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/12369data families shouldn't be required to have return kind *, data instances should2021-09-09T23:17:59ZEdward Kmettdata families shouldn't be required to have return kind *, data instances shouldI'd like to be able to define
```hs
{-# language PolyKinds, KindSignatures, GADTs, TypeFamilies #-}
data family Fix :: (k -> *) -> k
newtype instance Fix f = In { out :: f (Fix f) }
```
But currently this is disallowed:
```
Fix.hs:2:1...I'd like to be able to define
```hs
{-# language PolyKinds, KindSignatures, GADTs, TypeFamilies #-}
data family Fix :: (k -> *) -> k
newtype instance Fix f = In { out :: f (Fix f) }
```
But currently this is disallowed:
```
Fix.hs:2:1: error:
• Kind signature on data type declaration has non-* return kind
(k -> *) -> k
• In the data family declaration for ‘Fix’
```
Ultimately I think the issue here is that data __instances__ should be required to end in kind \*, not the families, but this generalization didn't mean anything until we had `PolyKinds`.
As an example of a usecase, with the above, I could define a bifunctor fixed point such as
```hs
newtype instance Fix f a = In2 { out2 :: f (Fix f a) a }
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------------- |
| Version | 8.0.1 |
| Type | FeatureRequest |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler (Type checker) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"data families shouldn't be required to have return kind *, data instances should","status":"New","operating_system":"","component":"Compiler (Type checker)","related":[],"milestone":"8.2.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.0.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"FeatureRequest","description":"I'd like to be able to define\r\n\r\n{{{#!hs\r\n{-# language PolyKinds, KindSignatures, GADTs, TypeFamilies #-}\r\ndata family Fix :: (k -> *) -> k\r\nnewtype instance Fix f = In { out :: f (Fix f) }\r\n}}}\r\n\r\nBut currently this is disallowed:\r\n\r\n{{{\r\nFix.hs:2:1: error:\r\n • Kind signature on data type declaration has non-* return kind\r\n (k -> *) -> k\r\n • In the data family declaration for ‘Fix’\r\n}}}\r\n\r\nUltimately I think the issue here is that data __instances__ should be required to end in kind *, not the families, but this generalization didn't mean anything until we had `PolyKinds`.\r\n\r\nAs an example of a usecase, with the above, I could define a bifunctor fixed point such as\r\n\r\n{{{#!hs\r\nnewtype instance Fix f a = In2 { out2 :: f (Fix f a) a }\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->8.4.1https://gitlab.haskell.org/ghc/ghc/-/issues/12368Demand Analyzer: Cunnig plan not adhered to with aborting fixpoint interation2019-07-07T18:26:54ZJoachim Breitnermail@joachim-breitner.deDemand Analyzer: Cunnig plan not adhered to with aborting fixpoint interationNot sure how relevant this is, but when reading both paper and code long enough, on inevitably finds some code smell.
This is about nested recursion, as in this example
```
f [] = []
f (x:xs) = let g [] = f xs
...Not sure how relevant this is, but when reading both paper and code long enough, on inevitably finds some code smell.
This is about nested recursion, as in this example
```
f [] = []
f (x:xs) = let g [] = f xs
g (y:ys) = y+1 : g ys
in g (h x)
```
The “cunning plan” of fixpoint iteration (see Note \[Initialising strictness\]) says that in the first time an inner recursive definition is looked at, its strictness is assumed to be `b` (`botSig`), and from then on, its `idInformation` (presumably from the previous iteration or the outer recursive definition) is used. A flag (`virgin`) in the analysis environment is used to detect that.
The problem is that the fixpoint iteration code in `dmdFix` aborts after more than 10 iterations:
```
loop' n env pairs
| found_fixpoint
= (env', lazy_fv, pairs')
| n >= 10
= (env, lazy_fv, orig_pairs) -- Safe output
```
This means that if the iteration does not terminate, we will “not” attach a strictness signature to the inner binders (`g` in the example above), but rather leave the binders untouched.
Then, in the second iteration of finding a fixpoint for `f`, the `virgin` flag is `False`, and `idStrictness` is used, which in this case will simply be the default, namely `nopSig`.
I could not produce an example where it matters. And it might be that it simply does not matter, so I’m not sure what to do with this information.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.0.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | low |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | ilya, osa1 |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Demand Analyzer: Cunnig plan not adhered to with aborting fixpoint interation","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.0.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["ilya","osa1"],"type":"Bug","description":"Not sure how relevant this is, but when reading both paper and code long enough, on inevitably finds some code smell.\r\n\r\nThis is about nested recursion, as in this example\r\n{{{\r\n f [] = []\r\n f (x:xs) = let g [] = f xs\r\n g (y:ys) = y+1 : g ys\r\n in g (h x)\r\n}}}\r\nThe “cunning plan” of fixpoint iteration (see Note [Initialising strictness]) says that in the first time an inner recursive definition is looked at, its strictness is assumed to be `b` (`botSig`), and from then on, its `idInformation` (presumably from the previous iteration or the outer recursive definition) is used. A flag (`virgin`) in the analysis environment is used to detect that.\r\n\r\n\r\nThe problem is that the fixpoint iteration code in `dmdFix` aborts after more than 10 iterations:\r\n{{{\r\n loop' n env pairs\r\n | found_fixpoint\r\n = (env', lazy_fv, pairs')\r\n | n >= 10\r\n = (env, lazy_fv, orig_pairs) -- Safe output\r\n}}}\r\nThis means that if the iteration does not terminate, we will “not” attach a strictness signature to the inner binders (`g` in the example above), but rather leave the binders untouched.\r\n\r\nThen, in the second iteration of finding a fixpoint for `f`, the `virgin` flag is `False`, and `idStrictness` is used, which in this case will simply be the default, namely `nopSig`.\r\n\r\nI could not produce an example where it matters. And it might be that it simply does not matter, so I’m not sure what to do with this information.\r\n\r\n","type_of_failure":"OtherFailure","blocking":[]} -->8.2.1https://gitlab.haskell.org/ghc/ghc/-/issues/12367Commit adding instances to GHC.Generics regression compiler performance2019-07-07T18:26:54ZBen GamariCommit adding instances to GHC.Generics regression compiler performanceRecently 673efccb3b348e9daf23d9e65460691bbea8586e added a number of new instances for types defined in `GHC.Generics`. Unfortunately, it seems that this has regressed nofib compilation allocations (and also, it seems, compile time) by be...Recently 673efccb3b348e9daf23d9e65460691bbea8586e added a number of new instances for types defined in `GHC.Generics`. Unfortunately, it seems that this has regressed nofib compilation allocations (and also, it seems, compile time) by between 0 and 20% (on average about 5%).8.0.2Ben GamariBen Gamarihttps://gitlab.haskell.org/ghc/ghc/-/issues/12366Use TypeOperators for pattern synonyms?2019-07-07T18:26:55ZdubiousjimUse TypeOperators for pattern synonyms?With the language setting `-XTypeOperators`, I can use *varsym* expressions, like `<|`, as type constructors. I would expect that we would then also be able to use them as pattern synonyms; but we can't. This is a request for that to bec...With the language setting `-XTypeOperators`, I can use *varsym* expressions, like `<|`, as type constructors. I would expect that we would then also be able to use them as pattern synonyms; but we can't. This is a request for that to become possible.
```hs
{-# LANGUAGE TypeOperators, PatternSynonyms #-}
module Main where
pattern (<|) x xs = Just (x, xs)
main = case Just (1, [2,3]) of { Nothing -> putStrLn "Nothing"; y <| ys -> print y }
```
gives a parse error.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------- |
| Version | 8.0.1 |
| Type | FeatureRequest |
| TypeOfFailure | OtherFailure |
| Priority | low |
| Resolution | Unresolved |
| Component | Compiler (Parser) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Use TypeOperators for pattern synonyms?","status":"New","operating_system":"","component":"Compiler (Parser)","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.0.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"FeatureRequest","description":"With the language setting `-XTypeOperators`, I can use ''varsym'' expressions, like `<|`, as type constructors. I would expect that we would then also be able to use them as pattern synonyms; but we can't. This is a request for that to become possible.\r\n\r\n{{{#!hs\r\n{-# LANGUAGE TypeOperators, PatternSynonyms #-}\r\n\r\nmodule Main where\r\n\r\npattern (<|) x xs = Just (x, xs)\r\n\r\nmain = case Just (1, [2,3]) of { Nothing -> putStrLn \"Nothing\"; y <| ys -> print y }\r\n}}}\r\n\r\ngives a parse error.","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/12365Update documentation for partial type signatures2019-07-07T18:26:55ZRichard Eisenbergrae@richarde.devUpdate documentation for partial type signaturesIn the [documentation](https://downloads.haskell.org/~ghc/master/users-guide/glasgow_exts.html#partial-type-signatures) for partial type signatures, I found several bits that are out of date:
- There are several sample error messages gi...In the [documentation](https://downloads.haskell.org/~ghc/master/users-guide/glasgow_exts.html#partial-type-signatures) for partial type signatures, I found several bits that are out of date:
- There are several sample error messages given. These have been substantively reworded (`Found hole `_` with type: ...` to `Found type wildcard `_` standing for ...`) where I find the new wording much clearer.
- In the "Where can they occur?" section, there's no mention of `TypeApplications`, which is a new context where they can appear.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------- |
| Version | 8.0.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Documentation |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Update documentation for partial type signatures","status":"New","operating_system":"","component":"Documentation","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.0.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"In the [https://downloads.haskell.org/~ghc/master/users-guide/glasgow_exts.html#partial-type-signatures documentation] for partial type signatures, I found several bits that are out of date:\r\n\r\n- There are several sample error messages given. These have been substantively reworded ({{{Found hole `_` with type: ...}}} to {{{Found type wildcard `_` standing for ...}}}) where I find the new wording much clearer.\r\n\r\n- In the \"Where can they occur?\" section, there's no mention of `TypeApplications`, which is a new context where they can appear.","type_of_failure":"OtherFailure","blocking":[]} -->8.0.2thomaswthomaswhttps://gitlab.haskell.org/ghc/ghc/-/issues/12358Read1/Read2 don't have methods defined in terms of ReadPrec2019-07-07T18:26:56ZRyan ScottRead1/Read2 don't have methods defined in terms of ReadPrecOriginal Haskell libraries mailing list discussion: https://mail.haskell.org/pipermail/libraries/2016-June/027102.html
> GHC 8.0 added the [Data.Functor.Classes](http://hackage.haskell.org/package/base-4.9.0.0/docs/Data-Functor-Classes....Original Haskell libraries mailing list discussion: https://mail.haskell.org/pipermail/libraries/2016-June/027102.html
> GHC 8.0 added the [Data.Functor.Classes](http://hackage.haskell.org/package/base-4.9.0.0/docs/Data-Functor-Classes.html) module to `base`, and with it the `Read1` and `Read2` typeclasses. The current definition of `Read1` is this:
>
> ```hs
> class Read1 f where
> liftReadsPrec :: (Int -> ReadS a) -> ReadS [a] -> Int -> ReadS (f a)
> liftReadList :: (Int -> ReadS a) -> ReadS [a] -> ReadS [f a]
> ```
>
> There's a pretty big problem with this definition: it uses `ReadS` (a synonym for `String -> [(a, String)]`). This sort of parser is very slow (the docs even [admit as such](http://hackage.haskell.org/package/base-4.9.0.0/docs/Text-ParserCombinators-ReadP.html#t:ReadS)), and moreover, the actual `Read` typeclass on which Read1 is based tries to avoid using it whenever possible.
>
> The `Read` typeclass has this definition currently:
>
> ```hs
> class Read a where
> readsPrec :: Int -> ReadS a
> readList :: ReadS [a]
> readPrec :: ReadPrec a
> readListPrec :: ReadPrec [a]
> ```
>
> Where `ReadPrec` is a much more efficient parser datatype. When deriving `Read` instances, GHC defines them in terms of `readPrec`, and gives the other methods default definitions that leverage `readPrec`.
>
> For the sake of consistency, I propose adding analogous methods to `Read1` and `Read2` that use the `ReadPrec` datatype. For example, here is how I would change `Read1`:
>
> ```hs
> class Read1 f where
> liftReadsPrec :: (Int -> ReadS a) -> ReadS [a] -> Int -> ReadS (f a)
> liftReadList :: (Int -> ReadS a) -> ReadS [a] -> ReadS [f a]
> liftReadPrec :: ReadPrec a -> ReadPrec [a] -> ReadPrec (f a)
> liftReadListPrec :: ReadPrec a -> ReadPrec [a] -> ReadPrec [f a]
> ```
>
> And similarly for `Read2`. Here is a [full gist](https://gist.github.com/RyanGlScott/7cdd11d6aa878e4229acf1a682beb1fc) with a sketch of what the new `Read1`/`Read2` definitions would look like, including what the default definitions of the other methods would be.
Diff coming soon.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 8.0.1 |
| Type | FeatureRequest |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | libraries/base |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Read1/Read2 don't have methods defined in terms of ReadPrec","status":"New","operating_system":"","component":"libraries/base","related":[],"milestone":"8.2.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.0.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"FeatureRequest","description":"Original Haskell libraries mailing list discussion: https://mail.haskell.org/pipermail/libraries/2016-June/027102.html\r\n\r\n> GHC 8.0 added the [http://hackage.haskell.org/package/base-4.9.0.0/docs/Data-Functor-Classes.html Data.Functor.Classes] module to `base`, and with it the `Read1` and `Read2` typeclasses. The current definition of `Read1` is this:\r\n>\r\n> {{{#!hs\r\n> class Read1 f where\r\n> liftReadsPrec :: (Int -> ReadS a) -> ReadS [a] -> Int -> ReadS (f a)\r\n> liftReadList :: (Int -> ReadS a) -> ReadS [a] -> ReadS [f a]\r\n> }}}\r\n>\r\n> There's a pretty big problem with this definition: it uses `ReadS` (a synonym for `String -> [(a, String)]`). This sort of parser is very slow (the docs even [http://hackage.haskell.org/package/base-4.9.0.0/docs/Text-ParserCombinators-ReadP.html#t:ReadS admit as such]), and moreover, the actual `Read` typeclass on which Read1 is based tries to avoid using it whenever possible.\r\n>\r\n> The `Read` typeclass has this definition currently:\r\n>\r\n> {{{#!hs\r\n> class Read a where\r\n> readsPrec :: Int -> ReadS a\r\n> readList :: ReadS [a]\r\n> readPrec :: ReadPrec a\r\n> readListPrec :: ReadPrec [a]\r\n> }}}\r\n>\r\n> Where `ReadPrec` is a much more efficient parser datatype. When deriving `Read` instances, GHC defines them in terms of `readPrec`, and gives the other methods default definitions that leverage `readPrec`.\r\n>\r\n> For the sake of consistency, I propose adding analogous methods to `Read1` and `Read2` that use the `ReadPrec` datatype. For example, here is how I would change `Read1`:\r\n>\r\n> {{{#!hs\r\n> class Read1 f where\r\n> liftReadsPrec :: (Int -> ReadS a) -> ReadS [a] -> Int -> ReadS (f a)\r\n> liftReadList :: (Int -> ReadS a) -> ReadS [a] -> ReadS [f a]\r\n> liftReadPrec :: ReadPrec a -> ReadPrec [a] -> ReadPrec (f a)\r\n> liftReadListPrec :: ReadPrec a -> ReadPrec [a] -> ReadPrec [f a]\r\n> }}}\r\n>\r\n> And similarly for `Read2`. Here is a [https://gist.github.com/RyanGlScott/7cdd11d6aa878e4229acf1a682beb1fc full gist] with a sketch of what the new `Read1`/`Read2` definitions would look like, including what the default definitions of the other methods would be.\r\n\r\nDiff coming soon.","type_of_failure":"OtherFailure","blocking":[]} -->8.2.1https://gitlab.haskell.org/ghc/ghc/-/issues/12357Increasing maximum constraint tuple size significantly blows up compiler allo...2019-07-07T18:26:56ZBen GamariIncreasing maximum constraint tuple size significantly blows up compiler allocationsIn July 2015 (dd3080fe0263082f65bf2570f49189c277b12e28) the maximum constraint tuple size was raised from 16 to 62 to address #10451. It turns out that this change is apparently one of the larger compile-time regressions in recent GHC hi...In July 2015 (dd3080fe0263082f65bf2570f49189c277b12e28) the maximum constraint tuple size was raised from 16 to 62 to address #10451. It turns out that this change is apparently one of the larger compile-time regressions in recent GHC history. For instance, the nofib `real/fulsom/Shapes.hs` module regresses by around 15% in both compiler allocations and compile time.
Judging by ticky and the cost-center profiler the performance regression appears to simply be the result of the loading the new declarations from the interface file, as one might expect. Nevertheless, it's quite silly to pay such a large price for a change that only gets occasionally exercised.8.2.1Ben GamariBen Gamari