GHC issueshttps://gitlab.haskell.org/ghc/ghc/-/issues2021-06-28T19:14:45Zhttps://gitlab.haskell.org/ghc/ghc/-/issues/1532Implicit parameters are not available in breakpoints2021-06-28T19:14:45ZmnislaihImplicit parameters are not available in breakpointsWe may want to leave this for after 6.8
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 6.7 |
| Type ...We may want to leave this for after 6.8
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 6.7 |
| Type | FeatureRequest |
| TypeOfFailure | OtherFailure |
| Priority | low |
| Resolution | Unresolved |
| Component | GHCi |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | Unknown |
| Architecture | Unknown |
</details>
<!-- {"blocked_by":[],"summary":"Implicit parameters are not available in breakpoints","status":"New","operating_system":"Unknown","component":"GHCi","related":[],"milestone":"6.10 branch","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.7","keywords":[],"differentials":[],"test_case":"","architecture":"Unknown","cc":[""],"type":"FeatureRequest","description":"We may want to leave this for after 6.8","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/1534[Debugger] Watch on accesses of "variables"2019-07-07T19:13:01Ziampure@gmail.com[Debugger] Watch on accesses of "variables"I would like to put a "watch" on certain parts of records. With such a watch in place, when writing to such a part of a record (e.g. foo{bar = 2} a new break point would be activated and the current line number would be shown somewhere. ...I would like to put a "watch" on certain parts of records. With such a watch in place, when writing to such a part of a record (e.g. foo{bar = 2} a new break point would be activated and the current line number would be shown somewhere. I believe the "watch" terminology is used in other debuggers. Often such a breakpoint will halt in a set_foo_bar function. This obviously would be the wrong result. The result should be a chain of calls like in the output of -xc. The user should be able to quickly move through such chains (with showing line numbers, etc).
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 6.7 |
| Type | FeatureRequest |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | GHCi |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | Unknown |
| Architecture | Unknown |
</details>
<!-- {"blocked_by":[],"summary":"[Debugger] Watch on accesses of \"variables\"","status":"New","operating_system":"Unknown","component":"GHCi","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.7","keywords":[],"differentials":[],"test_case":"","architecture":"Unknown","cc":[""],"type":"FeatureRequest","description":"I would like to put a \"watch\" on certain parts of records. With such a watch in place, when writing to such a part of a record (e.g. foo{bar = 2} a new break point would be activated and the current line number would be shown somewhere. I believe the \"watch\" terminology is used in other debuggers. Often such a breakpoint will halt in a set_foo_bar function. This obviously would be the wrong result. The result should be a chain of calls like in the output of -xc. The user should be able to quickly move through such chains (with showing line numbers, etc).","type_of_failure":"OtherFailure","blocking":[]} -->8.0.1https://gitlab.haskell.org/ghc/ghc/-/issues/1544Derived Read instances for recursive datatypes with infix constructors are to...2019-07-07T19:12:59ZDaniel GorínDerived Read instances for recursive datatypes with infix constructors are too inefficientConsider this definition:
```haskell
data Exp = C | Exp :+: Exp | Exp :-: Exp deriving ( Read, Show )
```
Now, try something like:
```haskell
> read "((((((((((C))))))))))" :: Exp
```
Even this simple expression may take several seco...Consider this definition:
```haskell
data Exp = C | Exp :+: Exp | Exp :-: Exp deriving ( Read, Show )
```
Now, try something like:
```haskell
> read "((((((((((C))))))))))" :: Exp
```
Even this simple expression may take several seconds to parse. It gets worse if you keep adding parenthesis. And even worse if you add more infix constructors....8.0.1https://gitlab.haskell.org/ghc/ghc/-/issues/1572Make it easy to find documentation for GHC and installed packages2019-07-07T19:12:51ZSimon Peyton JonesMake it easy to find documentation for GHC and installed packages`ghc-pkg` builds a package database that helps GHC find all installed packages. But it'd be a great improment if the same step also helped the **user** find the Haddock documentation for all installed packages.
Corresponding to GHC's pa...`ghc-pkg` builds a package database that helps GHC find all installed packages. But it'd be a great improment if the same step also helped the **user** find the Haddock documentation for all installed packages.
Corresponding to GHC's package database would be an HTML page that is a single point of entry for the user to find documentation about installed packages. Preferably together with a consolidated index. (And maybe `ghc --help` should give the local URL of this documentation root.)
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.6.1 |
| Type | Task |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | Unknown |
| Architecture | Unknown |
</details>
<!-- {"blocked_by":[],"summary":"Make it easy to find documentation for installed packages","status":"New","operating_system":"Unknown","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.6.1","keywords":[],"differentials":[],"test_case":"","architecture":"Unknown","cc":[""],"type":"Task","description":"`ghc-pkg` builds a package database that helps GHC find all installed packages. But it'd be a great improment if the same step also helped the '''user''' find the Haddock documentation for all installed packages.\r\n\r\nCorresponding to GHC's package database would be an HTML page that is a single point of entry for the user to find documentation about installed packages. Preferably together with a consolidated index. (And maybe `ghc --help` should give the local URL of this documentation root.)","type_of_failure":"OtherFailure","blocking":[]} -->8.0.1https://gitlab.haskell.org/ghc/ghc/-/issues/1574Broken link testing2019-07-07T19:12:51Ziampure@gmail.comBroken link testingOn http://www.haskell.org/ghc/dist/current/docs/ the link ../users_guide/index.html is broken.
Suggested fix to make sure this never happens again: let a broken link analyser be part of the build bots.
<details><summary>Trac metadata</...On http://www.haskell.org/ghc/dist/current/docs/ the link ../users_guide/index.html is broken.
Suggested fix to make sure this never happens again: let a broken link analyser be part of the build bots.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------- |
| Version | 6.6.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Documentation |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | Unknown |
| Architecture | Unknown |
</details>
<!-- {"blocked_by":[],"summary":"Broken link","status":"New","operating_system":"Unknown","component":"Documentation","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.6.1","keywords":[],"differentials":[],"test_case":"","architecture":"Unknown","cc":[""],"type":"Bug","description":"On http://www.haskell.org/ghc/dist/current/docs/ the link ../users_guide/index.html is broken.\r\n\r\nSuggested fix to make sure this never happens again: let a broken link analyser be part of the build bots.","type_of_failure":"OtherFailure","blocking":[]} -->8.0.1https://gitlab.haskell.org/ghc/ghc/-/issues/1612GHC_PACKAGE_PATH and $topdir bug2019-07-07T19:12:37ZeivuokkoGHC_PACKAGE_PATH and $topdir bugIn ghc-pkg $topdir is replaced according to path to package that is considered global - the last on in GHC_PACKAGE_PATH (if it doesn't contain trailing ';')
Following shows how (head, 1.1.7) Cabal's haddock-command gets broken.
```
C:\...In ghc-pkg $topdir is replaced according to path to package that is considered global - the last on in GHC_PACKAGE_PATH (if it doesn't contain trailing ';')
Following shows how (head, 1.1.7) Cabal's haddock-command gets broken.
```
C:\Users\eivuokko>copy con temp.conf
[]
^Z
1 file(s) copied.
C:\Users\eivuokko>set GHC_PACKAGE_PATH=c:\tools\ghc\ghc-6.6.1\package.conf;c:\Us
ers\eivuokko\temp.conf
C:\Users\eivuokko>ghc-pkg field base haddock-interfaces
haddock-interfaces: c:\Users\eivuokko\html\libraries\base\base.haddock
C:\Users\eivuokko>set GHC_PACKAGE_PATH=
C:\Users\eivuokko>ghc-pkg field base haddock-interfaces
haddock-interfaces: C:/tools/ghc/ghc-6.6.1\html\libraries\base\base.haddock
C:\Users\eivuokko>
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.6.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | eivuokko |
| Operating system | Unknown |
| Architecture | Unknown |
</details>
<!-- {"blocked_by":[],"summary":"GHC_PACKAGE_PATH and $topdir bug","status":"New","operating_system":"Unknown","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.6.1","keywords":[],"differentials":[],"test_case":"","architecture":"Unknown","cc":["eivuokko"],"type":"Bug","description":"In ghc-pkg $topdir is replaced according to path to package that is considered global - the last on in GHC_PACKAGE_PATH (if it doesn't contain trailing ';')\r\n\r\nFollowing shows how (head, 1.1.7) Cabal's haddock-command gets broken.\r\n\r\n{{{\r\nC:\\Users\\eivuokko>copy con temp.conf\r\n[]\r\n^Z\r\n 1 file(s) copied.\r\n\r\nC:\\Users\\eivuokko>set GHC_PACKAGE_PATH=c:\\tools\\ghc\\ghc-6.6.1\\package.conf;c:\\Us\r\ners\\eivuokko\\temp.conf\r\n\r\nC:\\Users\\eivuokko>ghc-pkg field base haddock-interfaces\r\nhaddock-interfaces: c:\\Users\\eivuokko\\html\\libraries\\base\\base.haddock\r\n\r\nC:\\Users\\eivuokko>set GHC_PACKAGE_PATH=\r\n\r\nC:\\Users\\eivuokko>ghc-pkg field base haddock-interfaces\r\nhaddock-interfaces: C:/tools/ghc/ghc-6.6.1\\html\\libraries\\base\\base.haddock\r\n\r\nC:\\Users\\eivuokko>\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->⊥https://gitlab.haskell.org/ghc/ghc/-/issues/1614Type checker does not use functional dependency to avoid ambiguity2019-07-07T19:12:36ZguestType checker does not use functional dependency to avoid ambiguityCompiling the following module gives an error
```
module X where
class C a | -> a
instance C Int
unC :: (C a) => a -> Int
unC i = undefined
test :: Int
test = unC undefined
```
Error message:
```
X.hs:13:7:
Ambiguous type varia...Compiling the following module gives an error
```
module X where
class C a | -> a
instance C Int
unC :: (C a) => a -> Int
unC i = undefined
test :: Int
test = unC undefined
```
Error message:
```
X.hs:13:7:
Ambiguous type variable `a' in the constraint:
`C a' arising from a use of `unC' at X.hs:13:7-19
Probable fix: add a type signature that fixes these type variable(s)
```
But that is just plain wrong. The functional dependency in the definition of C forces a to be Int. No other type is possible. So what's ambiguous about that?
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------------- |
| Version | 6.7 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler (Type checker) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | lennart@augustsson.net |
| Operating system | MacOS X |
| Architecture | x86 |
</details>
<!-- {"blocked_by":[],"summary":"Type checker does not use fundep to avoid ambiguity","status":"New","operating_system":"MacOS X","component":"Compiler (Type checker)","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.7","keywords":[],"differentials":[],"test_case":"","architecture":"x86","cc":["lennart@augustsson.net"],"type":"Bug","description":"Compiling the following module gives an error\r\n{{{\r\nmodule X where\r\n\r\nclass C a | -> a\r\ninstance C Int\r\n\r\nunC :: (C a) => a -> Int\r\nunC i = undefined\r\n\r\ntest :: Int\r\ntest = unC undefined\r\n}}}\r\nError message:\r\n{{{\r\nX.hs:13:7:\r\n Ambiguous type variable `a' in the constraint:\r\n `C a' arising from a use of `unC' at X.hs:13:7-19\r\n Probable fix: add a type signature that fixes these type variable(s)\r\n}}}\r\n\r\nBut that is just plain wrong. The functional dependency in the definition of C forces a to be Int. No other type is possible. So what's ambiguous about that?","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/1628warning(s) for using stolen syntax that's not currently enabled2019-07-07T19:12:31ZIsaac Dupreewarning(s) for using stolen syntax that's not currently enabledTurning on `-fglasgow-exts` makes `f x = id$x` break. I propose having a flag to warn about things like this, enabled by `-Wall`. To be precise, "stolen syntax" is syntax that means something valid in (usually) Haskell98 and something di...Turning on `-fglasgow-exts` makes `f x = id$x` break. I propose having a flag to warn about things like this, enabled by `-Wall`. To be precise, "stolen syntax" is syntax that means something valid in (usually) Haskell98 and something different with some extension enabled. If there are syntax-stealing extensions implemented by other non-GHC compilers, we may want to warn about those too. (This includes all keywords, possibly other words like "forall", "exists", "family", unicode symbols for `->` and others...)
If anyone actually agrees on or implements a (optional) change to unary-minus, this would subsume the warning aspects of #1318.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 6.6.1 |
| Type | FeatureRequest |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | Unknown |
| Architecture | Unknown |
</details>
<!-- {"blocked_by":[],"summary":"warning(s) for using stolen syntax that's not currently enabled","status":"New","operating_system":"Unknown","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.6.1","keywords":[],"differentials":[],"test_case":"","architecture":"Unknown","cc":[""],"type":"FeatureRequest","description":"Turning on `-fglasgow-exts` makes {{{f x = id$x}}} break. I propose having a flag to warn about things like this, enabled by `-Wall`. To be precise, \"stolen syntax\" is syntax that means something valid in (usually) Haskell98 and something different with some extension enabled. If there are syntax-stealing extensions implemented by other non-GHC compilers, we may want to warn about those too. (This includes all keywords, possibly other words like \"forall\", \"exists\", \"family\", unicode symbols for `->` and others...)\r\n\r\nIf anyone actually agrees on or implements a (optional) change to unary-minus, this would subsume the warning aspects of #1318.","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/1631Make the External Package Table contain ModDetails not ModIface2019-07-07T19:12:30ZSimon Peyton JonesMake the External Package Table contain ModDetails not ModIfaceCurrently the `External Package Table` contains `ModIfaces`. But that makes it hard to answer the question "which instances were introduced by module Foo" in the GHC API. See Kenny Lu's problem http://www.haskell.org/pipermail/glasgow-ha...Currently the `External Package Table` contains `ModIfaces`. But that makes it hard to answer the question "which instances were introduced by module Foo" in the GHC API. See Kenny Lu's problem http://www.haskell.org/pipermail/glasgow-haskell-users/2007-August/013027.html
Furthermore the `ModIfaces` in the EPS are cut-down ones, with decls etc trimmed off becuase they are in the type envts.
Since `loadInterface` does typechecking etc, it'd make sense for it to return a `ModDetails` instead and for that `ModDetails` to be stored in the EPS. This would also tidy up the oddity that a `ModIface` contains redundant fields for fixity envt and deprecaction envt (they would move to `ModDetails`).
Then it'd also make sense for the GHC API to use `ModDetails` instead of `ModInfo`.
This change isn't truly hard, but it needs care.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.6.1 |
| Type | Task |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | Unknown |
| Architecture | Unknown |
</details>
<!-- {"blocked_by":[],"summary":"Make the External Package Table contain ModDetails not ModIface","status":"New","operating_system":"Unknown","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.6.1","keywords":[],"differentials":[],"test_case":"","architecture":"Unknown","cc":[""],"type":"Task","description":"Currently the `External Package Table` contains `ModIfaces`. But that makes it hard to answer the question \"which instances were introduced by module Foo\" in the GHC API. See Kenny Lu's problem http://www.haskell.org/pipermail/glasgow-haskell-users/2007-August/013027.html\r\n\r\nFurthermore the `ModIfaces` in the EPS are cut-down ones, with decls etc trimmed off becuase they are in the type envts. \r\n\r\nSince `loadInterface` does typechecking etc, it'd make sense for it to return a `ModDetails` instead and for that `ModDetails` to be stored in the EPS. This would also tidy up the oddity that a `ModIface` contains redundant fields for fixity envt and deprecaction envt (they would move to `ModDetails`).\r\n\r\n\r\n\r\nThen it'd also make sense for the GHC API to use `ModDetails` instead of `ModInfo`.\r\n\r\nThis change isn't truly hard, but it needs care.","type_of_failure":"OtherFailure","blocking":[]} -->8.0.1Edward Z. YangEdward Z. Yanghttps://gitlab.haskell.org/ghc/ghc/-/issues/1687A faster (^)-function.2023-08-07T22:39:10Zmoonlite@dtek.chalmers.seA faster (^)-function.This function performs better for me than the `(^)`-function in GHC. I seem to only be able to test it for the Integer type though and its only tested with ghc 6.6 (and ghc 6.6.1 by byorgey on \#haskell).
I'm not sure if you really need ...This function performs better for me than the `(^)`-function in GHC. I seem to only be able to test it for the Integer type though and its only tested with ghc 6.6 (and ghc 6.6.1 by byorgey on \#haskell).
I'm not sure if you really need this or if it is correct, but after discussion on \#haskell i was asked to make a bug report so here it is! Enjoy. :)
```
module Pow (pow) where
import Prelude hiding ((^))
pow = (^)
(^) :: (Integral b, Num a) => a -> b -> a
x ^ y | y < 0 = error "Negative exponent"
| y == 0 = 1
| y == 1 = x
| odd y = x * x^(y - 1)
| otherwise = let x' = x^(y `div` 2)
in x' * x'
```
Tests
```
-- TestData.hs
module TestData where
e = 10^8
```
```
-- mytest.hs
import Pow
import TestData
main = print $ (2 `pow` e) `mod` 2
```
```
-- ghctest.hs
import TestData
main = print $ (2 ^ e) `mod` 2
```
Test results (performance)
```
$ time ./ghctest
0
real 0m11.744s
user 0m11.449s
sys 0m0.104s
$ time ./mytest
0
real 0m6.794s
user 0m6.696s
sys 0m0.084s
-}
```
QuickCheck test
```
-- qc.hs
-- $ ./qc
-- OK, passed 100 tests.
import Test.QuickCheck
import Pow
main = quickCheck prop
prop x y = y >= 0 ==> x `pow` y == x^y
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.6.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | Unknown |
| Architecture | Unknown |
</details>
<!-- {"blocked_by":[],"summary":"A faster (^)-function.","status":"New","operating_system":"Unknown","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.6.1","keywords":[],"differentials":[],"test_case":"","architecture":"Unknown","cc":[""],"type":"Bug","description":"This function performs better for me than the `(^)`-function in GHC. I seem to only be able to test it for the Integer type though and its only tested with ghc 6.6 (and ghc 6.6.1 by byorgey on #haskell).\r\nI'm not sure if you really need this or if it is correct, but after discussion on #haskell i was asked to make a bug report so here it is! Enjoy. :)\r\n\r\n{{{\r\nmodule Pow (pow) where\r\nimport Prelude hiding ((^))\r\npow = (^)\r\n\r\n(^) :: (Integral b, Num a) => a -> b -> a\r\nx ^ y | y < 0 = error \"Negative exponent\"\r\n | y == 0 = 1\r\n | y == 1 = x\r\n | odd y = x * x^(y - 1)\r\n | otherwise = let x' = x^(y `div` 2) \r\n in x' * x'\r\n}}}\r\n\r\nTests\r\n\r\n{{{\r\n-- TestData.hs\r\nmodule TestData where\r\ne = 10^8\r\n}}}\r\n{{{\r\n-- mytest.hs\r\nimport Pow\r\nimport TestData\r\nmain = print $ (2 `pow` e) `mod` 2\r\n}}}\r\n{{{\r\n-- ghctest.hs\r\nimport TestData\r\nmain = print $ (2 ^ e) `mod` 2\r\n}}}\r\n\r\nTest results (performance)\r\n{{{\r\n$ time ./ghctest\r\n0\r\n\r\nreal 0m11.744s\r\nuser 0m11.449s\r\nsys 0m0.104s\r\n\r\n$ time ./mytest\r\n0\r\n\r\nreal 0m6.794s\r\nuser 0m6.696s\r\nsys 0m0.084s\r\n\r\n-}\r\n}}}\r\n\r\nQuickCheck test\r\n{{{\r\n-- qc.hs\r\n-- $ ./qc \r\n-- OK, passed 100 tests.\r\n\r\nimport Test.QuickCheck\r\nimport Pow\r\n\r\nmain = quickCheck prop \r\nprop x y = y >= 0 ==> x `pow` y == x^y\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/1727Precedence and associativity rules ignored when mixing infix type and data co...2019-07-07T19:11:59Zpat@jantar.orgPrecedence and associativity rules ignored when mixing infix type and data constructors in a single expressionThe following code:
```
infixr 5 `Foo`
infixr 6 `Bar`
data a `Foo` b = a `FOO` a `Bar` b
data a `Bar` b = a `BAR` b
```
fails to compile, ignoring the fixity declarations. It should be parsed as a `FOO` (a `Bar` b) but currently the p...The following code:
```
infixr 5 `Foo`
infixr 6 `Bar`
data a `Foo` b = a `FOO` a `Bar` b
data a `Bar` b = a `BAR` b
```
fails to compile, ignoring the fixity declarations. It should be parsed as a `FOO` (a `Bar` b) but currently the parentheses are required, which misses the point of fixity annotations.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------- |
| Version | 6.6.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler (Parser) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | Unknown |
| Architecture | Unknown |
</details>
<!-- {"blocked_by":[],"summary":"Precedence and associativity rules ignored when mixing infix type and data constructors in a single expression","status":"New","operating_system":"Unknown","component":"Compiler (Parser)","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.6.1","keywords":[],"differentials":[],"test_case":"","architecture":"Unknown","cc":[""],"type":"Bug","description":"The following code:\r\n\r\n{{{\r\ninfixr 5 `Foo`\r\ninfixr 6 `Bar`\r\n\r\ndata a `Foo` b = a `FOO` a `Bar` b\r\ndata a `Bar` b = a `BAR` b\r\n}}}\r\n\r\nfails to compile, ignoring the fixity declarations. It should be parsed as a `FOO` (a `Bar` b) but currently the parentheses are required, which misses the point of fixity annotations.","type_of_failure":"OtherFailure","blocking":[]} -->8.0.1https://gitlab.haskell.org/ghc/ghc/-/issues/1768More flexible type signatures for data constructors2019-07-07T19:11:49ZSimon Peyton JonesMore flexible type signatures for data constructorsSee [http://article.gmane.org/gmane.comp.lang.haskell.cafe/29409](http://article.gmane.org/gmane.comp.lang.haskell.cafe/29409), and the rest of the thread. The idea is to allow data constructor declarations to have things like this:
```...See [http://article.gmane.org/gmane.comp.lang.haskell.cafe/29409](http://article.gmane.org/gmane.comp.lang.haskell.cafe/29409), and the rest of the thread. The idea is to allow data constructor declarations to have things like this:
```
type Foo = Int -> Bool -> T
data T where
C :: Foo
```
This is a silly example, but the idea is not to require the arrows to be all visible at top level, and to allow the result type to be something other than visibly `T` itself.
I'm recording this as a feature request, since it came up on Haskell Cafe, but I'm not sure that I like it. The type signatures in data type declarations are pretty special: notably, they allow record syntax, and support strictness annotations.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 6.6.1 |
| Type | FeatureRequest |
| TypeOfFailure | OtherFailure |
| Priority | low |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | Unknown |
| Architecture | Unknown |
</details>
<!-- {"blocked_by":[],"summary":"More flexible type signatures for data constructors","status":"New","operating_system":"Unknown","component":"Compiler","related":[],"milestone":"⊥","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.6.1","keywords":[],"differentials":[],"test_case":"","architecture":"Unknown","cc":[""],"type":"FeatureRequest","description":"See [http://article.gmane.org/gmane.comp.lang.haskell.cafe/29409], and the rest of the thread. The idea is to allow data constructor declarations to have things like this:\r\n{{{\r\ntype Foo = Int -> Bool -> T\r\n\r\ndata T where\r\n C :: Foo\r\n}}}\r\nThis is a silly example, but the idea is not to require the arrows to be all visible at top level, and to allow the result type to be something other than visibly `T` itself.\r\n\r\nI'm recording this as a feature request, since it came up on Haskell Cafe, but I'm not sure that I like it. The type signatures in data type declarations are pretty special: notably, they allow record syntax, and support strictness annotations.","type_of_failure":"OtherFailure","blocking":[]} -->⊥https://gitlab.haskell.org/ghc/ghc/-/issues/1800Template Haskell support for running functions defined in the same module2020-06-01T13:36:21ZSimon Peyton JonesTemplate Haskell support for running functions defined in the same moduleCurrently TH has the following restriction:
> You can only run a function at compile time if it is imported from another module. That is, you can't define a function in a module, and call it from within a splice in the same module.
Thi...Currently TH has the following restriction:
> You can only run a function at compile time if it is imported from another module. That is, you can't define a function in a module, and call it from within a splice in the same module.
This is a pain. It should be fixed.
See http://www.haskell.org/pipermail/template-haskell/2007-October/000619.html, for example.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 6.6.1 |
| Type | FeatureRequest |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | Unknown |
| Architecture | Unknown |
</details>
<!-- {"blocked_by":[],"summary":"Template Haskell support for running functions defined in the same module","status":"New","operating_system":"Unknown","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.6.1","keywords":[],"differentials":[],"test_case":"","architecture":"Unknown","cc":[""],"type":"FeatureRequest","description":"Currently TH has the following restriction:\r\n\r\n You can only run a function at compile time if it is imported from another module. That is, you can't define a function in a module, and call it from within a splice in the same module.\r\n\r\nThis is a pain. It should be fixed.\r\n\r\nSee http://www.haskell.org/pipermail/template-haskell/2007-October/000619.html, for example.\r\n","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/1826unable to list source for <exception thrown> should never occur2019-07-07T19:11:33Zguestunable to list source for <exception thrown> should never occurI get the very unhelpful "unable to list source for \<exception thrown\>". I would like to get one of the following two responses, the last one is best.
```
Do this and that to list source
```
```
We currently cannot list source, becau...I get the very unhelpful "unable to list source for \<exception thrown\>". I would like to get one of the following two responses, the last one is best.
```
Do this and that to list source
```
```
We currently cannot list source, because you did and that Do you still want to list source although it requires to do that and that(for example automatically recompiling and reexecuting it until the same program point) [Y/n]?
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 6.8.1 |
| Type | FeatureRequest |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | Unknown |
| Architecture | Unknown |
</details>
<!-- {"blocked_by":[],"summary":"unable to list source for <exception thrown> should never occur","status":"New","operating_system":"Unknown","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.8.1","keywords":[],"differentials":[],"test_case":"","architecture":"Unknown","cc":[""],"type":"FeatureRequest","description":"I get the very unhelpful \"unable to list source for <exception thrown>\". I would like to get one of the following two responses, the last one is best. \r\n{{{\r\nDo this and that to list source\r\n}}}\r\n{{{\r\nWe currently cannot list source, because you did and that Do you still want to list source although it requires to do that and that(for example automatically recompiling and reexecuting it until the same program point) [Y/n]?\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/1831reify never provides the declaration of variables2022-04-26T22:06:04Zguestreify never provides the declaration of variablesThe information returned by reify when provided a variable Name is
```
VarI Name Type (Maybe Dec) Fixity
```
The Dec part, due to be nested in Maybe, is clearly optional. In fact, according to Language.Haskell.TH.Syntax:
```
-- Nothin...The information returned by reify when provided a variable Name is
```
VarI Name Type (Maybe Dec) Fixity
```
The Dec part, due to be nested in Maybe, is clearly optional. In fact, according to Language.Haskell.TH.Syntax:
```
-- Nothing for lambda-bound variables, and
-- for anything else TH can't figure out
-- E.g. [| let x = 1 in $(do { d <- reify 'x; .. }) |]
```
However, the typechecker (TcSplice module) always returns Nothing. So it's simply not implemented.
I suggest either implementing the feature or removing the Dec part of VarI. Either way, the type should be consistent with the features offered in TH.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ---------------- |
| Version | 6.8.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Template Haskell |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | Unknown |
| Architecture | Unknown |
</details>
<!-- {"blocked_by":[],"summary":"reify never provides the declaration of variables","status":"New","operating_system":"Unknown","component":"Template Haskell","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.8.1","keywords":[],"differentials":[],"test_case":"","architecture":"Unknown","cc":[""],"type":"Bug","description":"The information returned by reify when provided a variable Name is\r\n\r\n{{{\r\nVarI Name Type (Maybe Dec) Fixity\r\n}}}\r\n\r\nThe Dec part, due to be nested in Maybe, is clearly optional. In fact, according to Language.Haskell.TH.Syntax:\r\n\r\n{{{\r\n-- Nothing for lambda-bound variables, and\r\n-- for anything else TH can't figure out\r\n-- E.g. [| let x = 1 in $(do { d <- reify 'x; .. }) |]\r\n}}}\r\n\r\nHowever, the typechecker (TcSplice module) always returns Nothing. So it's simply not implemented.\r\n\r\n\r\nI suggest either implementing the feature or removing the Dec part of VarI. Either way, the type should be consistent with the features offered in TH.\r\n","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/1851"make install-strip" should work2019-07-07T19:11:26ZIan Lynagh <igloo@earth.li>"make install-strip" should workWith the bindists (not sure about a normal build tree) install-strip doesn't work:
```
$ make install-strip
make: *** No rule to make target `install-strip'. Stop.
$
```
It is defined in mk/install.mk, so it presumably is meant to. Th...With the bindists (not sure about a normal build tree) install-strip doesn't work:
```
$ make install-strip
make: *** No rule to make target `install-strip'. Stop.
$
```
It is defined in mk/install.mk, so it presumably is meant to. The blurb after running configure should mention it, too.
The target is described in the GNU coding standards: http://www.gnu.org/prep/standards/html_node/Standard-Targets.html
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.8.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Build System |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | Unknown |
| Architecture | Unknown |
</details>
<!-- {"blocked_by":[],"summary":"\"make install-strip\" should work","status":"New","operating_system":"Unknown","component":"Build System","related":[],"milestone":"6.8.2","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.8.1","keywords":[],"differentials":[],"test_case":"","architecture":"Unknown","cc":[""],"type":"Bug","description":"With the bindists (not sure about a normal build tree) install-strip doesn't work:\r\n{{{\r\n$ make install-strip\r\nmake: *** No rule to make target `install-strip'. Stop.\r\n$\r\n}}}\r\nIt is defined in mk/install.mk, so it presumably is meant to. The blurb after running configure should mention it, too.\r\n\r\nThe target is described in the GNU coding standards: http://www.gnu.org/prep/standards/html_node/Standard-Targets.html\r\n","type_of_failure":"OtherFailure","blocking":[]} -->8.2.1Thomas MiedemaThomas Miedemahttps://gitlab.haskell.org/ghc/ghc/-/issues/1853hpc mix files for Main modules overwrite each other2019-07-07T19:11:25Zguesthpc mix files for Main modules overwrite each otherI have several programs, and hence several files that define Main modules, in the same directory. I build each one with a ghc --make -o Progname. When The hpc mix files describing the compiled modules are dumped in .hpc, the current Main...I have several programs, and hence several files that define Main modules, in the same directory. I build each one with a ghc --make -o Progname. When The hpc mix files describing the compiled modules are dumped in .hpc, the current Main.mix overwrites any previous Main.mix. As a result, I can only get an hpc report from Progname.tix if Progname was the most recent binary to be compiled.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------- |
| Version | 6.8.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Code Coverage |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | chris@connett.net |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"hpc mix files for Main modules overwrite each other","status":"New","operating_system":"","component":"Code Coverage","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"OwnedBy","contents":"andy@galois.com"},"version":"6.8.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["chris@connett.net"],"type":"Bug","description":"I have several programs, and hence several files that define Main modules, in the same directory. I build each one with a ghc --make -o Progname. When The hpc mix files describing the compiled modules are dumped in .hpc, the current Main.mix overwrites any previous Main.mix. As a result, I can only get an hpc report from Progname.tix if Progname was the most recent binary to be compiled.\r\n","type_of_failure":"OtherFailure","blocking":[]} -->8.0.1AndyGillAndyGillhttps://gitlab.haskell.org/ghc/ghc/-/issues/1885Improve CPR analysis (but actually improve eta-expansion)2021-09-30T12:06:11ZSimon Peyton JonesImprove CPR analysis (but actually improve eta-expansion)When a function returns a *nested* data structure, GHC should expose that fact to the caller. This can make a very big difference in inner loops. A good example is the following message (from GHC users http://www.haskell.org/pipermail/gl...When a function returns a *nested* data structure, GHC should expose that fact to the caller. This can make a very big difference in inner loops. A good example is the following message (from GHC users http://www.haskell.org/pipermail/glasgow-haskell-users/2007-November/013454.html).
Compile the attached files thus:
```
ghc --make Unpacked.hs -O2 -cpp -DPOLY_SAME
```
and similarly with `DPOLY_OTHER`. The `POLY_OTHER` case does a lot more allocation because a key function isn't inlined.
```
$wa_r1Wb :: GHC.Prim.Addr#
-> GHC.Prim.State# GHC.Prim.RealWorld
-> (# GHC.Prim.State# GHC.Prim.RealWorld,
OtherP.C
GHC.Float.Double (OtherP.C GHC.Float.Double
(OtherP.C GHC.Float.Double ())) #)
[GlobalId]
[Arity 2
NoCafRefs
Str: DmdType LL]
$wa_r1Wb =
\ (ww_s1S5 :: GHC.Prim.Addr#) (w_s1S7 :: GHC.Prim.State# GHC.Prim.RealWorld) ->
case GHC.Prim.readDoubleOffAddr# @ GHC.Prim.RealWorld ww_s1S5 0 w_s1S7
of wild2_a1xI { (# s2_a1xK, x_a1xL #) ->
let {
ipv_XGd [Just L] :: GHC.Prim.Addr#
[Str: DmdType]
ipv_XGd = GHC.Prim.plusAddr# ww_s1S5 8 } in
case GHC.Prim.readDoubleOffAddr# @ GHC.Prim.RealWorld ipv_XGd 0 s2_a1xK
of wild21_X1yK { (# s21_X1yN, x1_X1yP #) ->
case GHC.Prim.readDoubleOffAddr#
@ GHC.Prim.RealWorld (GHC.Prim.plusAddr# ipv_XGd 8) 0 s21_X1yN
of wild22_X1yU { (# s22_X1yX, x2_X1yZ #) ->
(# s22_X1yX,
OtherP.C
@ GHC.Float.Double
@ (OtherP.C GHC.Float.Double (OtherP.C GHC.Float.Double ()))
(GHC.Float.D# x_a1xL)
(OtherP.C
@ GHC.Float.Double
@ (OtherP.C GHC.Float.Double ())
(GHC.Float.D# x1_X1yP)
(OtherP.C @ GHC.Float.Double @ ()
(GHC.Float.D# x2_X1yZ) GHC.Base.())) #)
} } }
```8.0.1https://gitlab.haskell.org/ghc/ghc/-/issues/1894Add a total order on type constructors2019-07-07T19:11:10ZguestAdd a total order on type constructorsSeveral proposals for ExtensibleRecords can be implemented as libraries if type constructors can be ordered globally.
This proposal is to add built-in types:
```
data LabelLT
data LabelEQ
data LabelGT
type family LabelCMP
```
such tha...Several proposals for ExtensibleRecords can be implemented as libraries if type constructors can be ordered globally.
This proposal is to add built-in types:
```
data LabelLT
data LabelEQ
data LabelGT
type family LabelCMP
```
such that, for any two datatypes
```
data N = N
data M = M
```
the instance `LabelCMP N M` takes one of the values `LabelLT, LabelEQ, LabelGT` depending on the lexicographic ordering on the fully-qualified names of `N` and `M`.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------------- |
| Version | 6.8.1 |
| Type | FeatureRequest |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler (Type checker) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | Multiple |
| Architecture | Multiple |
</details>
<!-- {"blocked_by":[],"summary":"Add a total order on type constructors","status":"New","operating_system":"Multiple","component":"Compiler (Type checker)","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.8.1","keywords":[],"differentials":[],"test_case":"","architecture":"Multiple","cc":[""],"type":"FeatureRequest","description":"Several proposals for ExtensibleRecords can be implemented as libraries if type constructors can be ordered globally.\r\n\r\nThis proposal is to add built-in types:\r\n{{{\r\ndata LabelLT\r\ndata LabelEQ\r\ndata LabelGT\r\ntype family LabelCMP\r\n}}}\r\nsuch that, for any two datatypes\r\n{{{\r\ndata N = N\r\ndata M = M\r\n}}}\r\nthe instance {{{LabelCMP N M}}} takes one of the values {{{LabelLT, LabelEQ, LabelGT}}} depending on the lexicographic ordering on the fully-qualified names of {{{N}}} and {{{M}}}.\r\n\r\n\r\n\r\n","type_of_failure":"OtherFailure","blocking":[]} -->8.0.1https://gitlab.haskell.org/ghc/ghc/-/issues/1928Confusing type error message2022-03-07T06:48:02ZjosefConfusing type error messageThe following code (which is part of a bigger module) needs scoped type variables to compile.
```
run_state :: forall a s. State s a -> s -> (a,s)
run_state m s = observe_monad unit_op bind_op m where
unit_op v = (v,s)
bind...The following code (which is part of a bigger module) needs scoped type variables to compile.
```
run_state :: forall a s. State s a -> s -> (a,s)
run_state m s = observe_monad unit_op bind_op m where
unit_op v = (v,s)
bind_op :: BindOp (StateE s) a (a,s)
bind_op Get k = run_state (k s) s
bind_op (Put s1) k = run_state (k ()) s1
```
However, forgetting to turn on scoped type variables will give a very confusing error message:
```
Unimo.hs:56:36:
Couldn't match expected type `s1' against inferred type `s'
`s1' is a rigid type variable bound by
the type signature for `bind_op' at Unimo.hs:55:28
`s' is a rigid type variable bound by
the type signature for `run_state' at Unimo.hs:52:22
In the first argument of `k', namely `s'
In the first argument of `run_state', namely `(k s)'
In the expression: run_state (k s) s
```
Line 52 is the type signature of run_state and line 55 is the type signature of bind_op. The error message talks about a type variable \`s1' which isn't mentioned anywhere. I guess the reason for this is that we have name collision and this is ghc's way of trying to tell the two variables apart. I don't think it works that well though. But I'm afraid I don't have any suggestion on how to make it better.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------------- |
| Version | 6.8.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler (Type checker) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | Unknown |
| Architecture | Unknown |
</details>
<!-- {"blocked_by":[],"summary":"Confusing type error message","status":"New","operating_system":"Unknown","component":"Compiler (Type checker)","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.8.1","keywords":[],"differentials":[],"test_case":"","architecture":"Unknown","cc":[""],"type":"Bug","description":"The following code (which is part of a bigger module) needs scoped type variables to compile.\r\n\r\n{{{\r\nrun_state :: forall a s. State s a -> s -> (a,s)\r\nrun_state m s = observe_monad unit_op bind_op m where\r\n unit_op v = (v,s)\r\n bind_op :: BindOp (StateE s) a (a,s)\r\n bind_op Get k = run_state (k s) s\r\n bind_op (Put s1) k = run_state (k ()) s1\r\n}}}\r\nHowever, forgetting to turn on scoped type variables will give a very confusing error message:\r\n{{{\r\nUnimo.hs:56:36:\r\n Couldn't match expected type `s1' against inferred type `s'\r\n `s1' is a rigid type variable bound by\r\n the type signature for `bind_op' at Unimo.hs:55:28\r\n `s' is a rigid type variable bound by\r\n the type signature for `run_state' at Unimo.hs:52:22\r\n In the first argument of `k', namely `s'\r\n In the first argument of `run_state', namely `(k s)'\r\n In the expression: run_state (k s) s\r\n}}}\r\nLine 52 is the type signature of run_state and line 55 is the type signature of bind_op. The error message talks about a type variable `s1' which isn't mentioned anywhere. I guess the reason for this is that we have name collision and this is ghc's way of trying to tell the two variables apart. I don't think it works that well though. But I'm afraid I don't have any suggestion on how to make it better.","type_of_failure":"OtherFailure","blocking":[]} -->