GHC issueshttps://gitlab.haskell.org/ghc/ghc/-/issues2020-12-18T15:20:30Zhttps://gitlab.haskell.org/ghc/ghc/-/issues/13600surprising error message with bang pattern2020-12-18T15:20:30ZAndrew U. Franksurprising error message with bang patternthe following code
```
f3 :: [Int] -> IO Int
f3 x = return (sum x)
f4 :: [Int] -> IO Int
f4 !x = return (sum x)
```
gives `The type signature for ‘f4’ lacks an accompanying binding` for the second function (the two functions are...the following code
```
f3 :: [Int] -> IO Int
f3 x = return (sum x)
f4 :: [Int] -> IO Int
f4 !x = return (sum x)
```
gives `The type signature for ‘f4’ lacks an accompanying binding` for the second function (the two functions are exactly the same except for the added bang). I do not understand bang patterns well, but would expect a more instructive error message. without the type definition, the second function f4 compiles with the bang).
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 8.0.2 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | Linux |
| Architecture | x86_64 (amd64) |
</details>
<!-- {"blocked_by":[],"summary":"surprising error message with bang pattern","status":"New","operating_system":"Linux","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.0.2","keywords":[],"differentials":[],"test_case":"","architecture":"x86_64 (amd64)","cc":[""],"type":"Bug","description":"the following code \r\n\r\n{{{\r\nf3 :: [Int] -> IO Int \r\nf3 x = return (sum x) \r\n\r\nf4 :: [Int] -> IO Int \r\nf4 !x = return (sum x) \r\n}}}\r\n\r\ngives `The type signature for ‘f4’ lacks an accompanying binding` for the second function (the two functions are exactly the same except for the added bang). I do not understand bang patterns well, but would expect a more instructive error message. without the type definition, the second function f4 compiles with the bang). ","type_of_failure":"OtherFailure","blocking":[]} -->8.8.1Sasha Bogicevicsasa.bogicevic@pm.meSasha Bogicevicsasa.bogicevic@pm.mehttps://gitlab.haskell.org/ghc/ghc/-/issues/15426`elemIndex` and `findIndex` still can't fuse2023-09-01T16:08:46ZKevinBuhr`elemIndex` and `findIndex` still can't fuseTicket #14387 introduced a change to the implementation of `listToMaybe` to allow:
```hs
findIndex p = listToMaybe . findIndices p
```
to fuse.
However, to take advantage of this, it looks like we also need `findIndex` (and `elemIndex...Ticket #14387 introduced a change to the implementation of `listToMaybe` to allow:
```hs
findIndex p = listToMaybe . findIndices p
```
to fuse.
However, to take advantage of this, it looks like we also need `findIndex` (and `elemIndex`) to be marked inlinable (or some similar step).
As a concrete example, the module:
```hs
module Foo where
import Data.List (findIndex)
foo :: Maybe Int
foo = findIndex (==999999) [1..1000000]
```
compiled with GHC 8.4.3 using `-O2` produces the following unfused core:
```hs
foo_go
= \ ds1_a2ws eta_a2wt ->
case ds1_a2ws of {
[] -> Nothing;
: y_a2wx ys_a2wy ->
case eqInteger# y_a2wx ds_r2we of {
__DEFAULT -> foo_go ys_a2wy (+# eta_a2wt 1#);
1# -> Just (I# eta_a2wt)
}
}
foo = foo_go (enumDeltaToInteger1 foo2 foo1) 0#
```
but if the definition of `findIndex` from `Data.OldList` is copied into the module or imported from another module with an `INLINABLE` pragma, then it fuses fine:
```hs
foo_go
= \ x_a2Du eta_B1 ->
case gtInteger# x_a2Du lim_r2Ey of {
__DEFAULT ->
case eqInteger# x_a2Du ds_r2Cv of {
__DEFAULT -> foo_go (plusInteger x_a2Du foo1) (+# eta_B1 1#);
1# -> Just (I# eta_B1)
};
1# -> Nothing
}
foo = foo_go foo1 0#
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 8.4.3 |
| 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":"`elemIndex` and `findIndex` still can't fuse","status":"New","operating_system":"","component":"libraries/base","related":[],"milestone":"8.6.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.4.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Ticket #14387 introduced a change to the implementation of `listToMaybe` to allow:\r\n{{{#!hs\r\nfindIndex p = listToMaybe . findIndices p\r\n}}}\r\nto fuse.\r\n\r\nHowever, to take advantage of this, it looks like we also need `findIndex` (and `elemIndex`) to be marked inlinable (or some similar step).\r\n\r\nAs a concrete example, the module:\r\n\r\n{{{#!hs\r\nmodule Foo where\r\n\r\nimport Data.List (findIndex)\r\n\r\nfoo :: Maybe Int\r\nfoo = findIndex (==999999) [1..1000000]\r\n}}}\r\n\r\ncompiled with GHC 8.4.3 using `-O2` produces the following unfused core:\r\n\r\n{{{#!hs\r\nfoo_go\r\n = \\ ds1_a2ws eta_a2wt ->\r\n case ds1_a2ws of {\r\n [] -> Nothing;\r\n : y_a2wx ys_a2wy ->\r\n case eqInteger# y_a2wx ds_r2we of {\r\n __DEFAULT -> foo_go ys_a2wy (+# eta_a2wt 1#);\r\n 1# -> Just (I# eta_a2wt)\r\n }\r\n }\r\n\r\nfoo = foo_go (enumDeltaToInteger1 foo2 foo1) 0#\r\n}}}\r\nbut if the definition of `findIndex` from `Data.OldList` is copied into the module or imported from another module with an `INLINABLE` pragma, then it fuses fine:\r\n{{{#!hs\r\nfoo_go\r\n = \\ x_a2Du eta_B1 ->\r\n case gtInteger# x_a2Du lim_r2Ey of {\r\n __DEFAULT ->\r\n case eqInteger# x_a2Du ds_r2Cv of {\r\n __DEFAULT -> foo_go (plusInteger x_a2Du foo1) (+# eta_B1 1#);\r\n 1# -> Just (I# eta_B1)\r\n };\r\n 1# -> Nothing\r\n }\r\n\r\nfoo = foo_go foo1 0#\r\n}}}\r\n","type_of_failure":"OtherFailure","blocking":[]} -->8.8.1KevinBuhrKevinBuhrhttps://gitlab.haskell.org/ghc/ghc/-/issues/16964Documentation of RuntimeRep is wrong about 64-bit integer reps2022-02-12T03:28:41ZÖmer Sinan AğacanDocumentation of RuntimeRep is wrong about 64-bit integer repsDocumentation of `Int64Rep` and `Word64Rep` currently have the note "on 32-bit only" which seems wrong. Here's an example (this is on a 64-bit system):
```
~ $ cat Main.hs
{-# LANGUAGE TypeApplications, MagicHash #-}
import Type.Reflec...Documentation of `Int64Rep` and `Word64Rep` currently have the note "on 32-bit only" which seems wrong. Here's an example (this is on a 64-bit system):
```
~ $ cat Main.hs
{-# LANGUAGE TypeApplications, MagicHash #-}
import Type.Reflection
import GHC.Types
import GHC.Prim
import Data.Int
main = do
print (splitApps (typeRepKind (typeRep @Int64#)))
print (splitApps (typeRepKind (typeRep @Int#)))
~ $ ghc Main.hs
[1 of 1] Compiling Main ( Main.hs, Main.o )
Linking Main ...
~ $ ./Main
(TYPE,['Int64Rep])
(TYPE,['IntRep])
```
The documentation seems to suggest that `Int64Rep` should only be used on 32-bit systems, and we should get `IntRep` for `Int64#` on 64-bit.
[(Link to `RuntimeRep`)](https://hackage.haskell.org/package/base-4.12.0.0/docs/GHC-Exts.html#t:RuntimeRep)
(The same comments exist in GHC HEAD source tree too)
(cc @rae)8.8.1Carter SchonwaldJohn EricsonCarter Schonwald