GHC issueshttps://gitlab.haskell.org/ghc/ghc/-/issues2019-07-07T19:13:12Zhttps://gitlab.haskell.org/ghc/ghc/-/issues/1497Rebinding (:) -- built-in syntax, or just another constructor?2019-07-07T19:13:12ZdonsRebinding (:) -- built-in syntax, or just another constructor?This program is valid in Hugs 2005, but not in GHC:
```
import Prelude (print,(<),Bool(..))
data Cond a = a : a
infixl 0 ?
infixl 1 :
(?) :: Bool -> Cond a -> a
True ? (x : _) = x
False ? (_ : y) = y
main = print (1 < 2 ? "yeah" : ...This program is valid in Hugs 2005, but not in GHC:
```
import Prelude (print,(<),Bool(..))
data Cond a = a : a
infixl 0 ?
infixl 1 :
(?) :: Bool -> Cond a -> a
True ? (x : _) = x
False ? (_ : y) = y
main = print (1 < 2 ? "yeah" : "no!")
```
Hugs responds with:
```
Main> main
"yeah"
```
GHCi says:
```
$ ghci A.hs
A.hs:4:16: Illegal binding of built-in syntax: :
```
Which one is right?
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------- |
| Version | 6.6 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | low |
| Resolution | Unresolved |
| Component | Compiler (Parser) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | Unknown |
| Architecture | Multiple |
</details>
<!-- {"blocked_by":[],"summary":"Rebinding (:) -- built-in syntax, or just another constructor?","status":"New","operating_system":"Unknown","component":"Compiler (Parser)","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.6","keywords":[],"differentials":[],"test_case":"","architecture":"Multiple","cc":[""],"type":"Bug","description":"This program is valid in Hugs 2005, but not in GHC:\r\n\r\n{{{\r\n\r\nimport Prelude (print,(<),Bool(..))\r\n\r\ndata Cond a = a : a\r\n\r\ninfixl 0 ?\r\ninfixl 1 :\r\n\r\n(?) :: Bool -> Cond a -> a\r\nTrue ? (x : _) = x\r\nFalse ? (_ : y) = y\r\n\r\nmain = print (1 < 2 ? \"yeah\" : \"no!\")\r\n\r\n}}}\r\n\r\nHugs responds with:\r\n\r\n{{{\r\nMain> main\r\n\"yeah\"\r\n}}}\r\n\r\nGHCi says:\r\n\r\n{{{\r\n$ ghci A.hs\r\nA.hs:4:16: Illegal binding of built-in syntax: :\r\n}}}\r\n\r\nWhich one is right?","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/1499Visual Haskell installer issue(s)2019-07-07T19:13:11ZSimon MarlowVisual Haskell installer issue(s)There appears to be one or more installer bugs in Visual Haskell 0.2, reported on glasgow-haskell-bugs:
- [http://www.haskell.org/pipermail/glasgow-haskell-bugs/2007-March/008721.html](http://www.haskell.org/pipermail/glasgow-haskell-bu...There appears to be one or more installer bugs in Visual Haskell 0.2, reported on glasgow-haskell-bugs:
- [http://www.haskell.org/pipermail/glasgow-haskell-bugs/2007-March/008721.html](http://www.haskell.org/pipermail/glasgow-haskell-bugs/2007-March/008721.html)
- [http://www.haskell.org/pipermail/glasgow-haskell-bugs/2007-March/008797.html](http://www.haskell.org/pipermail/glasgow-haskell-bugs/2007-March/008797.html)
- [http://www.haskell.org/pipermail/glasgow-haskell-bugs/2007-March/008888.html](http://www.haskell.org/pipermail/glasgow-haskell-bugs/2007-March/008888.html)
- [http://www.haskell.org/pipermail/glasgow-haskell-bugs/2007-March/008954.html](http://www.haskell.org/pipermail/glasgow-haskell-bugs/2007-March/008954.html)
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 6.6.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Visual Haskell |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Visual Haskell installer issue(s)","status":"New","operating_system":"","component":"Visual Haskell","related":[],"milestone":"6.10 branch","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.6.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"There appears to be one or more installer bugs in Visual Haskell 0.2, reported on glasgow-haskell-bugs:\r\n\r\n* [http://www.haskell.org/pipermail/glasgow-haskell-bugs/2007-March/008721.html]\r\n* [http://www.haskell.org/pipermail/glasgow-haskell-bugs/2007-March/008797.html]\r\n* [http://www.haskell.org/pipermail/glasgow-haskell-bugs/2007-March/008888.html]\r\n* [http://www.haskell.org/pipermail/glasgow-haskell-bugs/2007-March/008954.html]","type_of_failure":"OtherFailure","blocking":[]} -->Not GHChttps://gitlab.haskell.org/ghc/ghc/-/issues/1500NCG: shortcutBranch doesn't handle loops properly2019-07-07T19:13:11ZMichael D. AdamsNCG: shortcutBranch doesn't handle loops properlyThe following Cmm code causes GHC to go into an infinite loop when `-O` and `-fasm` are on.
```
foo {
L: goto L;
}
```
I do not know of any code that depends on this yet. I just tripped over it when writting tests for the CPS pass.
...The following Cmm code causes GHC to go into an infinite loop when `-O` and `-fasm` are on.
```
foo {
L: goto L;
}
```
I do not know of any code that depends on this yet. I just tripped over it when writting tests for the CPS pass.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 6.7 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler (NCG) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | Multiple |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Infinite loop caused by Cmm","status":"New","operating_system":"Multiple","component":"Compiler (NCG)","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.7","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"The following Cmm code causes GHC to go into an infinite loop when {{{-O}}} and {{{-fasm}}} are on.\r\n\r\n{{{\r\nfoo {\r\n L: goto L;\r\n}\r\n}}}\r\n\r\nI do not know of any code that depends on this yet. I just tripped over it when writting tests for the CPS pass.","type_of_failure":"OtherFailure","blocking":[]} -->6.12.3https://gitlab.haskell.org/ghc/ghc/-/issues/1501Panic in RegisterAlloc2019-07-07T19:13:10ZguestPanic in RegisterAllocThe following code causes a panic when compiling with the NCG (i.e. with `-fasm`).
```
stg_ap_0_fast {
bits32 y, x;
c7: y = bits32[x];
goto c7;
}
```
The panic is
```
ghc-6.7.20070620: panic! (the 'impossible' happened...The following code causes a panic when compiling with the NCG (i.e. with `-fasm`).
```
stg_ap_0_fast {
bits32 y, x;
c7: y = bits32[x];
goto c7;
}
```
The panic is
```
ghc-6.7.20070620: panic! (the 'impossible' happened)
(GHC version 6.7.20070620 for i386-unknown-linux):
RegisterAlloc.joinToTargets
```
I do not know of any code that depends on this yet. I just tripped over it when writting tests for the CPS pass.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 6.7 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler (NCG) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | Multiple |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Panic in RegisterAlloc","status":"New","operating_system":"Multiple","component":"Compiler (NCG)","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.7","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"The following code causes a panic when compiling with the NCG (i.e. with {{{-fasm}}}).\r\n\r\n{{{\r\nstg_ap_0_fast {\r\n bits32 y, x;\r\n c7: y = bits32[x];\r\n goto c7;\r\n}\r\n}}}\r\n\r\nThe panic is\r\n{{{\r\nghc-6.7.20070620: panic! (the 'impossible' happened)\r\n (GHC version 6.7.20070620 for i386-unknown-linux):\r\n RegisterAlloc.joinToTargets\r\n}}}\r\n\r\nI do not know of any code that depends on this yet. I just tripped over it when writting tests for the CPS pass.","type_of_failure":"OtherFailure","blocking":[]} -->6.12 branchbenlbenlhttps://gitlab.haskell.org/ghc/ghc/-/issues/1502GHC should integrate better with mingw2019-07-07T19:13:10ZeivuokkoGHC should integrate better with mingwWhen developing in Windows, it is very common to require many more tools than what's available with GHC. I have myself used
- strip
- nm
- reimp
- dlltool
- pexport
- windres
Also, when installing libraries/headers for mingw/msys and a...When developing in Windows, it is very common to require many more tools than what's available with GHC. I have myself used
- strip
- nm
- reimp
- dlltool
- pexport
- windres
Also, when installing libraries/headers for mingw/msys and are going to use them with GHC, the only way to get them linked is to copy them to GHC installation as well. So, I'd really like if I could tell GHC via flag or preferably via configuration file. But GHC would probably need to organize the includes and archives differently than it does now.
Configuring via files would also allow Cabal to make use of these tools without much extra fiddling.
<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":"GHC should integrate better with mingw","status":"New","operating_system":"Unknown","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.6.1","keywords":["windows"],"differentials":[],"test_case":"","architecture":"Unknown","cc":[""],"type":"FeatureRequest","description":"When developing in Windows, it is very common to require many more tools than what's available with GHC. I have myself used\r\n * strip\r\n * nm\r\n * reimp\r\n * dlltool\r\n * pexport\r\n * windres\r\n\r\nAlso, when installing libraries/headers for mingw/msys and are going to use them with GHC, the only way to get them linked is to copy them to GHC installation as well. So, I'd really like if I could tell GHC via flag or preferably via configuration file. But GHC would probably need to organize the includes and archives differently than it does now.\r\n\r\nConfiguring via files would also allow Cabal to make use of these tools without much extra fiddling.","type_of_failure":"OtherFailure","blocking":[]} -->6.12.1https://gitlab.haskell.org/ghc/ghc/-/issues/1503GHC doesn't respect monomorphism restrictions for non-type-class-restricted v...2019-07-07T19:13:10ZIsaac DupreeGHC doesn't respect monomorphism restrictions for non-type-class-restricted values that are boundApplicable in both 6.6.1 and 6.7.something.
This compiles as expected:
```
loop = read "foo"
int = show loop
req :: Int; req = loop
```
This fails to compile:
```
loop = undefined
int = show loop
req :: Int; req = loop
```
This comp...Applicable in both 6.6.1 and 6.7.something.
This compiles as expected:
```
loop = read "foo"
int = show loop
req :: Int; req = loop
```
This fails to compile:
```
loop = undefined
int = show loop
req :: Int; req = loop
```
This compiles with -fmono-pat-binds (the default setting), but not with -fno-mono-pat-binds:
```
(loop) = undefined
int = show loop
req :: Int; req = loop
```
This compiles unless we use both -fno-mono-pat-binds and -fno-monomorphism-restriction, as expected:
```
(loop) = read "foo"
int = show loop
req :: Int; req = loop
```
loop=undefined versus loop=loop doesn't make any difference.
This compiles even with -fno-mono-pat-binds -fno-monomorphism-restriction. I don't understand how/why/how much 'case' makes a monomorphic binding:
```
x = case undefined of
loop -> let int = show loop; req :: Int; req = loop in ()
```
Admittedly, this is an odd case where the Report's rationales for the M-R \<http://haskell.org/onlinereport/decls.html\#sect4.5.4\> aren't exactly applicable. "Rule 1 prevents computations from being unexpectedly repeated" -without typeclasses, no computations will be repeated. "Rule 1 prevents ambiguity" -well, true, but not in the strong way described by that point in the Report.
Encountered in the following, and I only recently figured out *why* it was not working.
```
{-# OPTIONS_GHC -fglasgow-exts -cpp #-}
{-# LANGUAGE CPP #-}
import Data.Typeable
#ifdef __GLASGOW_HASKELL__
import GHC.Prim ( unsafeCoerce# )
#endif
#ifdef __NHC__
import NonStdUnsafeCoerce (unsafeCoerce)
#endif
#ifdef __HUGS__
import Hugs.IOExts (unsafeCoerce)
#endif
#ifdef __GLASGOW_HASKELL__
unsafeCoerce :: a -> b
unsafeCoerce = unsafeCoerce#
#endif
data Dy = forall a. Dy !a !TypeRep
fromDyM :: Typeable a => Dy -> Maybe a
-- compiles:
fromDyM (Dy a typeRep) =
case unsafeCoerce a of
unsafeResult | typeRep == typeOf unsafeResult -> Just unsafeResult
| otherwise -> Nothing
--fails to compile:
fromDyM (Dy a typeRep) = result
where
unsafeResult = unsafeCoerce a
--(unsafeResult) = unsafeCoerce a --works because of mono-pat-binds
--unsafeResult = unsafeCoerce a `asTypeOfMaybe` result --was my earlier "fix"
result | typeRep == typeOf unsafeResult = Just unsafeResult
| otherwise = Nothing
asTypeOfMaybe :: a -> Maybe a -> a
asTypeOfMaybe a b = a
```
Testing the above examples in Hugs seems to be useless because Hugs's monomorphism is totally broken (it tries to find the monomorphic type too early in a way that depends on what order the declarations are in).
<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":"GHC doesn't respect monomorphism restrictions for non-type-class-restricted values that are bound","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":"Applicable in both 6.6.1 and 6.7.something.\r\n\r\nThis compiles as expected:\r\n{{{\r\nloop = read \"foo\"\r\nint = show loop\r\nreq :: Int; req = loop\r\n}}}\r\nThis fails to compile:\r\n{{{\r\nloop = undefined\r\nint = show loop\r\nreq :: Int; req = loop\r\n}}}\r\nThis compiles with -fmono-pat-binds (the default setting), but not with -fno-mono-pat-binds:\r\n{{{\r\n(loop) = undefined\r\nint = show loop\r\nreq :: Int; req = loop\r\n}}}\r\nThis compiles unless we use both -fno-mono-pat-binds and -fno-monomorphism-restriction, as expected:\r\n{{{\r\n(loop) = read \"foo\"\r\nint = show loop\r\nreq :: Int; req = loop\r\n}}}\r\nloop=undefined versus loop=loop doesn't make any difference. \r\n\r\nThis compiles even with -fno-mono-pat-binds -fno-monomorphism-restriction. I don't understand how/why/how much 'case' makes a monomorphic binding:\r\n{{{\r\nx = case undefined of\r\n loop -> let int = show loop; req :: Int; req = loop in ()\r\n}}}\r\n\r\nAdmittedly, this is an odd case where the Report's rationales for the M-R <http://haskell.org/onlinereport/decls.html#sect4.5.4> aren't exactly applicable. \"Rule 1 prevents computations from being unexpectedly repeated\" -without typeclasses, no computations will be repeated. \"Rule 1 prevents ambiguity\" -well, true, but not in the strong way described by that point in the Report.\r\n\r\nEncountered in the following, and I only recently figured out ''why'' it was not working.\r\n{{{\r\n{-# OPTIONS_GHC -fglasgow-exts -cpp #-}\r\n{-# LANGUAGE CPP #-}\r\n\r\nimport Data.Typeable\r\n\r\n#ifdef __GLASGOW_HASKELL__\r\nimport GHC.Prim ( unsafeCoerce# )\r\n#endif\r\n#ifdef __NHC__\r\nimport NonStdUnsafeCoerce (unsafeCoerce)\r\n#endif\r\n#ifdef __HUGS__\r\nimport Hugs.IOExts (unsafeCoerce)\r\n#endif\r\n#ifdef __GLASGOW_HASKELL__\r\nunsafeCoerce :: a -> b\r\nunsafeCoerce = unsafeCoerce#\r\n#endif\r\n\r\ndata Dy = forall a. Dy !a !TypeRep\r\n\r\nfromDyM :: Typeable a => Dy -> Maybe a\r\n\r\n-- compiles:\r\nfromDyM (Dy a typeRep) =\r\n case unsafeCoerce a of\r\n unsafeResult | typeRep == typeOf unsafeResult -> Just unsafeResult\r\n | otherwise -> Nothing\r\n\r\n--fails to compile:\r\nfromDyM (Dy a typeRep) = result\r\n where\r\n unsafeResult = unsafeCoerce a\r\n--(unsafeResult) = unsafeCoerce a --works because of mono-pat-binds\r\n--unsafeResult = unsafeCoerce a `asTypeOfMaybe` result --was my earlier \"fix\"\r\n result | typeRep == typeOf unsafeResult = Just unsafeResult\r\n | otherwise = Nothing\r\n\r\nasTypeOfMaybe :: a -> Maybe a -> a\r\nasTypeOfMaybe a b = a\r\n}}}\r\n\r\nTesting the above examples in Hugs seems to be useless because Hugs's monomorphism is totally broken (it tries to find the monomorphic type too early in a way that depends on what order the declarations are in).","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/1504existentials containing type-class(dictionaries) require more type-signatures...2019-07-07T19:13:10ZIsaac Dupreeexistentials containing type-class(dictionaries) require more type-signatures in 6.7I don't understand the "rules" well enough to know if this is actually a bug, or if the type signature is supposed to be required. (Also I need to update my build of HEAD... but before I forget,)
```
{-# LANGUAGE ExistentialQuantificati...I don't understand the "rules" well enough to know if this is actually a bug, or if the type signature is supposed to be required. (Also I need to update my build of HEAD... but before I forget,)
```
{-# LANGUAGE ExistentialQuantification #-}
module Test where
import Data.Typeable
data D = forall a. Typeable a => D a
--type signature only required in 6.7, not 6.6.1
fromD :: Typeable result => D -> result -> Bool
fromD (D a) def =
typeOf a == typeOf def
```
ghc 6.7's error message when the type signature is commented out:
```
ghc67tysigreg.hs:10:15:
Could not deduce (Typeable a) from the context (Typeable a1)
arising from a use of `typeOf' at ghc67tysigreg.hs:10:15-24
Possible fix:
add (Typeable a) to the context of the constructor `D'
In the second argument of `(==)', namely `typeOf def'
In the expression: (typeOf a) == (typeOf def)
In the definition of `fromD':
fromD (D a) def = (typeOf a) == (typeOf def)
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.7 |
| 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":"existentials containing type-class(dictionaries) require more type-signatures in 6.7","status":"New","operating_system":"Unknown","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.7","keywords":[],"differentials":[],"test_case":"","architecture":"Unknown","cc":[""],"type":"Bug","description":"I don't understand the \"rules\" well enough to know if this is actually a bug, or if the type signature is supposed to be required. (Also I need to update my build of HEAD... but before I forget,)\r\n\r\n{{{\r\n{-# LANGUAGE ExistentialQuantification #-}\r\nmodule Test where\r\n\r\nimport Data.Typeable\r\n\r\ndata D = forall a. Typeable a => D a\r\n\r\n--type signature only required in 6.7, not 6.6.1\r\nfromD :: Typeable result => D -> result -> Bool\r\nfromD (D a) def =\r\n typeOf a == typeOf def\r\n}}}\r\n\r\nghc 6.7's error message when the type signature is commented out:\r\n{{{\r\nghc67tysigreg.hs:10:15:\r\n Could not deduce (Typeable a) from the context (Typeable a1)\r\n arising from a use of `typeOf' at ghc67tysigreg.hs:10:15-24\r\n Possible fix:\r\n add (Typeable a) to the context of the constructor `D'\r\n In the second argument of `(==)', namely `typeOf def'\r\n In the expression: (typeOf a) == (typeOf def)\r\n In the definition of `fromD':\r\n fromD (D a) def = (typeOf a) == (typeOf def)\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/1505Leaks implementation details2019-07-07T19:13:10Ziampure@gmail.comLeaks implementation detailsDoing the following in ghci (6.7.20070705) with a module that imports A.B.C.D loaded
:break A.B.C.D
gives
- \*\* Exception: ghci/InteractiveUI.hs:(1641,0)-(1644,59): Non-exhaustive patterns in function breakByModule
It should just sa...Doing the following in ghci (6.7.20070705) with a module that imports A.B.C.D loaded
:break A.B.C.D
gives
- \*\* Exception: ghci/InteractiveUI.hs:(1641,0)-(1644,59): Non-exhaustive patterns in function breakByModule
It should just say: missing line number argument or something similar.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.7 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | lowest |
| Resolution | Unresolved |
| Component | GHCi |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | Unknown |
| Architecture | Unknown |
</details>
<!-- {"blocked_by":[],"summary":"Leaks implementation details","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":"Bug","description":"Doing the following in ghci (6.7.20070705) with a module that imports A.B.C.D loaded\r\n\r\n:break A.B.C.D\r\n\r\ngives\r\n\r\n*** Exception: ghci/InteractiveUI.hs:(1641,0)-(1644,59): Non-exhaustive patterns in function breakByModule\r\n\r\nIt should just say: missing line number argument or something similar.","type_of_failure":"OtherFailure","blocking":[]} -->6.8.1Simon MarlowSimon Marlowhttps://gitlab.haskell.org/ghc/ghc/-/issues/1506Case-insensitive char/string comparison2019-07-07T19:13:09ZEelisCase-insensitive char/string comparisonData.Char provides functions to convert case, but does not provide a function to perform case-insensitive char/string comparison. Note that such functionality cannot be obtained by simply comparing for equality after performing toUpper/t...Data.Char provides functions to convert case, but does not provide a function to perform case-insensitive char/string comparison. Note that such functionality cannot be obtained by simply comparing for equality after performing toUpper/toLower, because some languages have things like multiple lowercase characters corresponding to the same uppercase character.
For example, in Greek, converting either σ or ς to uppercase yields Σ, while the inverse always yields σ. Consequently, the convert-all-to-uppercase approach would produce a false positive when comparing σ to ς, and the convert-all-to-lowercase approach would produce a false negative when comparing Σ to ς.
<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":"Case-insensitive char/string comparison","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":"Data.Char provides functions to convert case, but does not provide a function to perform case-insensitive char/string comparison. Note that such functionality cannot be obtained by simply comparing for equality after performing toUpper/toLower, because some languages have things like multiple lowercase characters corresponding to the same uppercase character.\r\n\r\nFor example, in Greek, converting either σ or ς to uppercase yields Σ, while the inverse always yields σ. Consequently, the convert-all-to-uppercase approach would produce a false positive when comparing σ to ς, and the convert-all-to-lowercase approach would produce a false negative when comparing Σ to ς.","type_of_failure":"OtherFailure","blocking":[]} -->Not GHChttps://gitlab.haskell.org/ghc/ghc/-/issues/1507GHC documentation package download2019-07-07T19:13:09ZguestGHC documentation package downloadIt would be nice, given the fragile nature of the toolchains used to make docs, to have a compiled documentation tree available as a tar file to just drop into a locally-built GHC. For various reasons I can't use the binary kits provided...It would be nice, given the fragile nature of the toolchains used to make docs, to have a compiled documentation tree available as a tar file to just drop into a locally-built GHC. For various reasons I can't use the binary kits provided, and when I try to build the docs using the guidelines given the build fails horribly. This seems to break any use of haddock afterwards resulting in an unmaintainable mess. When it subsequently breaks, it complains about missing .haddock files under the installation tree. Having a readily un-tarrable distribution of the docs would do wonders in alleviating this problem.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 6.6.1 |
| Type | FeatureRequest |
| 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":"GHC documentation package download","status":"New","operating_system":"Unknown","component":"Build System","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.6.1","keywords":[],"differentials":[],"test_case":"","architecture":"Unknown","cc":[""],"type":"FeatureRequest","description":"It would be nice, given the fragile nature of the toolchains used to make docs, to have a compiled documentation tree available as a tar file to just drop into a locally-built GHC. For various reasons I can't use the binary kits provided, and when I try to build the docs using the guidelines given the build fails horribly. This seems to break any use of haddock afterwards resulting in an unmaintainable mess. When it subsequently breaks, it complains about missing .haddock files under the installation tree. Having a readily un-tarrable distribution of the docs would do wonders in alleviating this problem.","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/1508hasktags program needs replacement2019-07-07T19:13:08Ziampure@gmail.comhasktags program needs replacementThe following module yields
HaskTagsTest.hs,0
It should have included the identifier a, b, c and d in the TAGS file. My suggestion would be to remove it from the manual and stop distributing it or to replace it, since also on real code...The following module yields
HaskTagsTest.hs,0
It should have included the identifier a, b, c and d in the TAGS file. My suggestion would be to remove it from the manual and stop distributing it or to replace it, since also on real code it is of no help and only wastes time.
```
module Zork where
a = putStrLn "hi"
b = putStrLn "hi"
c = putStrLn "hi"
d = putStrLn "hi"
```
Priority should maybe be set to high, since navigating source trees is simplified via the TAGS files.https://gitlab.haskell.org/ghc/ghc/-/issues/1509Make unboxed tuples more supported2019-07-07T19:13:08ZguestMake unboxed tuples more supportedUnboxed tuples `(# a, b #)` do not have the same features as boxed tuples `( a, b )`. In particular:
1) There is no prefix form, `(#,#) a b` is not equivalent to `(# a, b #)`. We would have to define a collection of such functions in th...Unboxed tuples `(# a, b #)` do not have the same features as boxed tuples `( a, b )`. In particular:
1) There is no prefix form, `(#,#) a b` is not equivalent to `(# a, b #)`. We would have to define a collection of such functions in the Prelude (see Data.Tuple, for the (,,,,) functions). We'd have to do is to make the parser understand `(#,,,#)`.
2) Currently GHC does not allow `f :: (# a, b #) -> ...`, but there's no real reason why not; GHC could transform them away just before code generation.
<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 | ndmitchell@gmail.com |
| Operating system | Unknown |
| Architecture | Unknown |
</details>
<!-- {"blocked_by":[],"summary":"Make unboxed tuples more supported","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":["ndmitchell@gmail.com"],"type":"FeatureRequest","description":"Unboxed tuples {{{(# a, b #)}}} do not have the same features as boxed tuples {{{( a, b )}}}. In particular:\r\n\r\n1) There is no prefix form, {{{(#,#) a b}}} is not equivalent to {{{(# a, b #)}}}. We would have to define a collection of such functions in the Prelude (see Data.Tuple, for the (,,,,) functions). We'd have to do is to make the parser understand {{{(#,,,#)}}}.\r\n\r\n2) Currently GHC does not allow {{{f :: (# a, b #) -> ...}}}, but there's no real reason why not; GHC could transform them away just before code generation.","type_of_failure":"OtherFailure","blocking":[]} -->⊥https://gitlab.haskell.org/ghc/ghc/-/issues/1510Fix warning issued when using the -fhpc flag2019-07-07T19:13:08ZAndyGillFix warning issued when using the -fhpc flagWhen compiling multi-module code, -fhpc compiled code issues various warning of
the form
```
/Users/andy/darcs/ghc/ghc-quick-1/libraries/base/dist/build/GHC/Base.hi
Declaration for flip
Unfolding of GHC.Base.flip:
Iface id out of scop...When compiling multi-module code, -fhpc compiled code issues various warning of
the form
```
/Users/andy/darcs/ghc/ghc-quick-1/libraries/base/dist/build/GHC/Base.hi
Declaration for flip
Unfolding of GHC.Base.flip:
Iface id out of scope: {tick (base:GHC.Base, 95)}
```
They seem benign, but need investigated, and either removed or corrected.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------- |
| Version | 6.7 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Code Coverage |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | Unknown |
| Architecture | Unknown |
</details>
<!-- {"blocked_by":[],"summary":"Fix warning issued when using the -fhpc flag","status":"New","operating_system":"Unknown","component":"Code Coverage","related":[],"milestone":"6.8 branch","resolution":"Unresolved","owner":{"tag":"OwnedBy","contents":"andy@galois.com"},"version":"6.7","keywords":[],"differentials":[],"test_case":"","architecture":"Unknown","cc":[""],"type":"Bug","description":"When compiling multi-module code, -fhpc compiled code issues various warning of\r\nthe form\r\n\r\n{{{\r\n/Users/andy/darcs/ghc/ghc-quick-1/libraries/base/dist/build/GHC/Base.hi\r\nDeclaration for flip\r\nUnfolding of GHC.Base.flip:\r\n Iface id out of scope: {tick (base:GHC.Base, 95)}\r\n}}}\r\n\r\nThey seem benign, but need investigated, and either removed or corrected.","type_of_failure":"OtherFailure","blocking":[]} -->6.8.1andy@galois.comandy@galois.comhttps://gitlab.haskell.org/ghc/ghc/-/issues/1511GHCi can't load Text.Printf2019-07-07T19:13:08ZtomsGHCi can't load Text.PrintfI'm using the binary distribution.
I have no trouble to load e.g. Text.PrettyPrint. However, Text.Printf can't be found. Here's part of a GHCi session:
```
Prelude> :m Text.PrettyPrint
Prelude Text.PrettyPrint> :m Text.Printf
can't fin...I'm using the binary distribution.
I have no trouble to load e.g. Text.PrettyPrint. However, Text.Printf can't be found. Here's part of a GHCi session:
```
Prelude> :m Text.PrettyPrint
Prelude Text.PrettyPrint> :m Text.Printf
can't find module `Text.Printf'
Prelude Text.PrettyPrint>
```
Running Setup.lhs of Happy also causes this error:
```
$ ./Setup.lhs
./Setup.lhs:
Can't find module `Text.Printf'
(use -v to see a list of the files searched for)
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.6.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Build System |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"GHCi can't load Text.Printf","status":"New","operating_system":"","component":"Build System","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.6.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"I'm using the binary distribution.\r\n\r\nI have no trouble to load e.g. Text.PrettyPrint. However, Text.Printf can't be found. Here's part of a GHCi session:\r\n{{{\r\nPrelude> :m Text.PrettyPrint\r\nPrelude Text.PrettyPrint> :m Text.Printf\r\ncan't find module `Text.Printf'\r\nPrelude Text.PrettyPrint> \r\n}}}\r\nRunning Setup.lhs of Happy also causes this error:\r\n{{{\r\n$ ./Setup.lhs\r\n./Setup.lhs:\r\n Can't find module `Text.Printf'\r\n (use -v to see a list of the files searched for)\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/1512NCG to handle cyclic fixups for rematching register assignment for jump blocks2019-07-07T19:13:08ZguestNCG to handle cyclic fixups for rematching register assignment for jump blocksjoinToTargets in [RegisterAlloc.hs](http://darcs.haskell.org/ghc/compiler/nativeGen/RegisterAlloc.hs)
generates a jump to a particular target. On the first jump to a target, the virtual register assignment is associated with this target....joinToTargets in [RegisterAlloc.hs](http://darcs.haskell.org/ghc/compiler/nativeGen/RegisterAlloc.hs)
generates a jump to a particular target. On the first jump to a target, the virtual register assignment is associated with this target. All following jumps to the target must ensure that the current virtual register assignment matches that one of the target. If that's not the case, fixup code is generated before the branch instruction.
In rare cases, that occur when compiling the RTS on i386 in -fPIC -dynamic mode we have to generate cyclic fixup code. Here is one issue that comes from compiling PrimOps.cmm:
Assignment of target:
- virtual register A in real register A
- virtual register B in real register B.
Current assignment:
- virtual register A in real register B
- virtual register B in real register A.
Basically, we have to move A to B, and B to A. There is no move sequence that allows this without using a scratch register. [RegisterAlloc.hs](http://darcs.haskell.org/ghc/compiler/nativeGen/RegisterAlloc.hs) detects this by using stronglyConnCompR in joinToTargets (Line 869). At the moment, it does not provide a solution for this, it just fails.
My trivial approach would be:
```
handleComponent (CyclicSCC ((vreg,src,dsts):rest))
= let sccs = stronglyConnCompR rest
in [makeMove vreg src (InMem empty_spill)] ++
concatMap handleComponent sccs ++
map (makeMove vreg (InMem empty_spill)) dsts
```
I'm only having trouble to find empty_spill, namely an empty spill slot on the stack.
I have no clear idea what the (simulated) stack pointer is pointing at and whether it is save to assume that below (above?) is scratch space I can abuse for such a task.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | |
| 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":"NCG to handle cyclic fixups for rematching register assignment for jump blocks","status":"New","operating_system":"Unknown","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"","keywords":[],"differentials":[],"test_case":"","architecture":"Unknown","cc":[""],"type":"Bug","description":"joinToTargets in [http://darcs.haskell.org/ghc/compiler/nativeGen/RegisterAlloc.hs RegisterAlloc.hs] \r\ngenerates a jump to a particular target. On the first jump to a target, the virtual register assignment is associated with this target. All following jumps to the target must ensure that the current virtual register assignment matches that one of the target. If that's not the case, fixup code is generated before the branch instruction.\r\n\r\nIn rare cases, that occur when compiling the RTS on i386 in -fPIC -dynamic mode we have to generate cyclic fixup code. Here is one issue that comes from compiling PrimOps.cmm:\r\n\r\nAssignment of target: \r\n * virtual register A in real register A\r\n * virtual register B in real register B.\r\n\r\nCurrent assignment: \r\n * virtual register A in real register B\r\n * virtual register B in real register A.\r\n\r\nBasically, we have to move A to B, and B to A. There is no move sequence that allows this without using a scratch register. [http://darcs.haskell.org/ghc/compiler/nativeGen/RegisterAlloc.hs RegisterAlloc.hs] detects this by using stronglyConnCompR in joinToTargets (Line 869). At the moment, it does not provide a solution for this, it just fails.\r\n\r\nMy trivial approach would be:\r\n\r\n{{{\r\nhandleComponent (CyclicSCC ((vreg,src,dsts):rest)) \r\n = let sccs = stronglyConnCompR rest\r\n in [makeMove vreg src (InMem empty_spill)] ++\r\n concatMap handleComponent sccs ++\r\n map (makeMove vreg (InMem empty_spill)) dsts\r\n}}}\r\nI'm only having trouble to find empty_spill, namely an empty spill slot on the stack.\r\nI have no clear idea what the (simulated) stack pointer is pointing at and whether it is save to assume that below (above?) is scratch space I can abuse for such a task.","type_of_failure":"OtherFailure","blocking":[]} -->6.8.1https://gitlab.haskell.org/ghc/ghc/-/issues/1513odd panic with [()] >>> ()2019-07-07T19:13:07Zscook0@gmail.comodd panic with [()] >>> ()While messing around with arrows in GHCi, I was surprised to see the following (ill-typed) code cause a panic:
```
___ ___ _
/ _ \ /\ /\/ __(_)
/ /_\// /_/ / / | | GHC Interactive, version 6.6, for Haskell 98.
/ /_\...While messing around with arrows in GHCi, I was surprised to see the following (ill-typed) code cause a panic:
```
___ ___ _
/ _ \ /\ /\/ __(_)
/ /_\// /_/ / / | | GHC Interactive, version 6.6, for Haskell 98.
/ /_\\/ __ / /___| | http://www.haskell.org/ghc/
\____/\/ /_/\____/|_| Type :? for help.
Loading package base ... linking ... done.
Prelude> :m Control.Arrow
Prelude Control.Arrow> [1, 2] >>> pure (+1)
ghc-6.6: panic! (the 'impossible' happened)
(GHC version 6.6 for i386-unknown-linux):
nameModule it{v aIS}
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
```
Further experimentation revealed that
```
[] >>> ()
```
is a type-error as expected, whereas
```
[()] >>> ()
```
causes a panic.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.6 |
| 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":"odd panic with [()] >>> ()","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.6","keywords":["panic"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"While messing around with arrows in GHCi, I was surprised to see the following (ill-typed) code cause a panic:\r\n\r\n{{{\r\n ___ ___ _\r\n / _ \\ /\\ /\\/ __(_)\r\n / /_\\// /_/ / / | | GHC Interactive, version 6.6, for Haskell 98.\r\n/ /_\\\\/ __ / /___| | http://www.haskell.org/ghc/\r\n\\____/\\/ /_/\\____/|_| Type :? for help.\r\n\r\nLoading package base ... linking ... done.\r\nPrelude> :m Control.Arrow\r\nPrelude Control.Arrow> [1, 2] >>> pure (+1)\r\nghc-6.6: panic! (the 'impossible' happened)\r\n (GHC version 6.6 for i386-unknown-linux):\r\n nameModule it{v aIS}\r\n\r\nPlease report this as a GHC bug: http://www.haskell.org/ghc/reportabug\r\n}}}\r\n\r\nFurther experimentation revealed that\r\n{{{\r\n[] >>> ()\r\n}}}\r\nis a type-error as expected, whereas\r\n{{{\r\n[()] >>> ()\r\n}}}\r\ncauses a panic.","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/1514test2019-07-07T19:13:07Zguesttesttest
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.6.1 |
| Type | Bug |
| TypeOfFailure ...test
<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":"test","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":"test","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/1515Nightly installer does not setup .hs/.lhs icons property2019-07-07T19:13:07ZguestNightly installer does not setup .hs/.lhs icons propertyWhen I installed the 6.7 nightly I lost the pretty icons for .lhs/.hs files. I'm not sure if it failed to create the registry keys, or failed to copy the .ico file over.
I did this on another machine, and don't have disk space to test o...When I installed the 6.7 nightly I lost the pretty icons for .lhs/.hs files. I'm not sure if it failed to create the registry keys, or failed to copy the .ico file over.
I did this on another machine, and don't have disk space to test on any of my other machines. I'll add more detail to this bug report in a few days.
-- neil
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------------- |
| Version | 6.7 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Build System |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | ndmitchell@gmail.com |
| Operating system | |
| Architecture | Unknown |
</details>
<!-- {"blocked_by":[],"summary":"Nightly installer does not setup .hs/.lhs icons property","status":"New","operating_system":"","component":"Build System","related":[],"milestone":"6.8 branch","resolution":"Unresolved","owner":{"tag":"OwnedBy","contents":"neil"},"version":"6.7","keywords":[],"differentials":[],"test_case":"","architecture":"Unknown","cc":["ndmitchell@gmail.com"],"type":"Bug","description":"When I installed the 6.7 nightly I lost the pretty icons for .lhs/.hs files. I'm not sure if it failed to create the registry keys, or failed to copy the .ico file over.\r\n\r\nI did this on another machine, and don't have disk space to test on any of my other machines. I'll add more detail to this bug report in a few days.\r\n\r\n-- neil","type_of_failure":"OtherFailure","blocking":[]} -->6.8.1Ian Lynagh <igloo@earth.li>Ian Lynagh <igloo@earth.li>https://gitlab.haskell.org/ghc/ghc/-/issues/1516Add Data.Stream, a library for manipulating infinite lists, to base2019-07-07T19:13:07ZWouterSwierstraAdd Data.Stream, a library for manipulating infinite lists, to baseI'd propose to add a Data.Stream library to base. Data.Stream should be fairly uncontroversial. The module consists largely of a reimplimentation of several functions from Data.List to create, modify, and manipulate infinite lists. There...I'd propose to add a Data.Stream library to base. Data.Stream should be fairly uncontroversial. The module consists largely of a reimplimentation of several functions from Data.List to create, modify, and manipulate infinite lists. There is already a package on Hackage:
http://hackage.haskell.org/cgi-bin/hackage-scripts/package/Stream-0.1
I've tried to include Haddock-comments, very similar to those for Data.List. As working with infinite lists can be tricky, I've included warnings clearly stating which functions can diverge.
I am aware that the name may cause confusion with Data.List.Stream. I'd welcome suggestions to avoid causing confusion.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 6.6.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | libraries/base |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | Unknown |
| Architecture | Unknown |
</details>
<!-- {"blocked_by":[],"summary":"Add Data.Stream, a library for manipulating infinite lists, to base","status":"New","operating_system":"Unknown","component":"libraries/base","related":[],"milestone":"6.8 branch","resolution":"Unresolved","owner":{"tag":"OwnedBy","contents":"WouterSwierstra"},"version":"6.6.1","keywords":["infinite","lists","streams,"],"differentials":[],"test_case":"","architecture":"Unknown","cc":[""],"type":"Bug","description":"I'd propose to add a Data.Stream library to base. Data.Stream should be fairly uncontroversial. The module consists largely of a reimplimentation of several functions from Data.List to create, modify, and manipulate infinite lists. There is already a package on Hackage:\r\n\r\nhttp://hackage.haskell.org/cgi-bin/hackage-scripts/package/Stream-0.1\r\n\r\nI've tried to include Haddock-comments, very similar to those for Data.List. As working with infinite lists can be tricky, I've included warnings clearly stating which functions can diverge.\r\n\r\nI am aware that the name may cause confusion with Data.List.Stream. I'd welcome suggestions to avoid causing confusion.","type_of_failure":"OtherFailure","blocking":[]} -->Not GHCWouterSwierstraWouterSwierstrahttps://gitlab.haskell.org/ghc/ghc/-/issues/1517Ratio Int is not well ordered2019-07-07T19:13:07Zdbenbenn@gmail.comRatio Int is not well orderedRatio Int is declared to be in class Ord, which means (according to http://haskell.org/ghc/docs/latest/html/libraries/base/Data-Ord.html\#t%3AOrd) that \< should be a total ordering. Yet consider the following interactive session in GHCI...Ratio Int is declared to be in class Ord, which means (according to http://haskell.org/ghc/docs/latest/html/libraries/base/Data-Ord.html\#t%3AOrd) that \< should be a total ordering. Yet consider the following interactive session in GHCI (on a 32 bit computer!):
```
Prelude> :m + Ratio
Prelude Ratio> let a = 1 % (2 :: Int)
Prelude Ratio> let b = 883177231 % (662415279 :: Int)
Prelude Ratio> let c = 1616076535 % (430549561 :: Int)
Prelude Ratio> a < b && b < c
True
Prelude Ratio> a < c
False
```
The problem is that overflow occurs in Real.lhs (from the GHC source code), in the definition
```
(x:%y) < (x':%y') = x * y' < x' * y
```
That works for unbounded types (such as Integer). But to define a total order on bounded types, a more complicated method is necessary.
See http://boost.cvs.sourceforge.net/boost/boost/boost/rational.hpp?revision=1.21&view=markup, line 374, for a correct implementation in C++.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 6.6.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | libraries/base |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | Multiple |
| Architecture | Multiple |
</details>
<!-- {"blocked_by":[],"summary":"Ratio Int is not well ordered","status":"New","operating_system":"Multiple","component":"libraries/base","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.6.1","keywords":[],"differentials":[],"test_case":"","architecture":"Multiple","cc":[""],"type":"Bug","description":"Ratio Int is declared to be in class Ord, which means (according to http://haskell.org/ghc/docs/latest/html/libraries/base/Data-Ord.html#t%3AOrd) that < should be a total ordering. Yet consider the following interactive session in GHCI (on a 32 bit computer!):\r\n\r\n{{{\r\nPrelude> :m + Ratio\r\nPrelude Ratio> let a = 1 % (2 :: Int)\r\nPrelude Ratio> let b = 883177231 % (662415279 :: Int)\r\nPrelude Ratio> let c = 1616076535 % (430549561 :: Int)\r\nPrelude Ratio> a < b && b < c\r\nTrue\r\nPrelude Ratio> a < c\r\nFalse\r\n}}}\r\n\r\nThe problem is that overflow occurs in Real.lhs (from the GHC source code), in the definition\r\n\r\n{{{\r\n(x:%y) < (x':%y') = x * y' < x' * y\r\n}}}\r\n\r\nThat works for unbounded types (such as Integer). But to define a total order on bounded types, a more complicated method is necessary.\r\n\r\nSee http://boost.cvs.sourceforge.net/boost/boost/boost/rational.hpp?revision=1.21&view=markup, line 374, for a correct implementation in C++.","type_of_failure":"OtherFailure","blocking":[]} -->