GHC issueshttps://gitlab.haskell.org/ghc/ghc/-/issues2019-07-07T18:15:27Zhttps://gitlab.haskell.org/ghc/ghc/-/issues/14818Provide highestOneBit function in Data.Bits module2019-07-07T18:15:27ZkostmoProvide highestOneBit function in Data.Bits moduleThis function yields the [largest power of 2 less than or equal to the given number](https://stackoverflow.com/a/17379704/105137).
Relative to the Java standard library, which [provides this function](https://docs.oracle.com/javase/7/do...This function yields the [largest power of 2 less than or equal to the given number](https://stackoverflow.com/a/17379704/105137).
Relative to the Java standard library, which [provides this function](https://docs.oracle.com/javase/7/docs/api/java/lang/Integer.html#highestOneBit(int)), there is a gap in the Haskell library, even though the Haskell docs [describe a method to calculate logBase2 via the \`countLeadingZeros\` function](https://hackage.haskell.org/package/base-4.10.1.0/docs/Data-Bits.html#v:countLeadingZeros).
From the Java documentation:
> The implementations of the "bit twiddling" methods (such as `highestOneBit` and `numberOfTrailingZeros`) are based on material from Henry S. Warren, Jr.'s ''Hacker's Delight'', (Addison Wesley, 2002).
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 8.2.2 |
| Type | FeatureRequest |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | libraries/base |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Provide highestOneBit function in Data.Bits module","status":"New","operating_system":"","component":"libraries/base","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.2.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"FeatureRequest","description":"This function yields the [https://stackoverflow.com/a/17379704/105137 largest power of 2 less than or equal to the given number].\r\n\r\n\r\nRelative to the Java standard library, which [https://docs.oracle.com/javase/7/docs/api/java/lang/Integer.html#highestOneBit(int) provides this function], there is a gap in the Haskell library, even though the Haskell docs [https://hackage.haskell.org/package/base-4.10.1.0/docs/Data-Bits.html#v:countLeadingZeros describe a method to calculate logBase2 via the `countLeadingZeros` function].\r\n\r\nFrom the Java documentation:\r\n\r\n> The implementations of the \"bit twiddling\" methods (such as `highestOneBit` and `numberOfTrailingZeros`) are based on material from Henry S. Warren, Jr.'s ''Hacker's Delight'', (Addison Wesley, 2002).","type_of_failure":"OtherFailure","blocking":[]} -->7.10.1https://gitlab.haskell.org/ghc/ghc/-/issues/10142Documentation for Ix is contradictory around minimal definition2019-07-07T18:37:21ZRichard Eisenbergrae@richarde.devDocumentation for Ix is contradictory around minimal definitionThe Haddock documentation for `Ix` [here](http://hackage.haskell.org/package/base-4.7.0.2/docs/Data-Ix.html) says that the minimal definition requires `range`, `index`, and `inRange`. But then it says that the minimal definition requires...The Haddock documentation for `Ix` [here](http://hackage.haskell.org/package/base-4.7.0.2/docs/Data-Ix.html) says that the minimal definition requires `range`, `index`, and `inRange`. But then it says that the minimal definition requires `range` and `inRange`. It seems that Haddock is inferring a `MINIMAL` definition where none is in the code. Perhaps a `MINIMAL` should be added.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------------------------------ |
| Version | 7.8.4 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Core Libraries |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | core-libraries-committee@haskell.org |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Documentation for Ix is contradictory around minimal definition","status":"New","operating_system":"","component":"Core Libraries","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"OwnedBy","contents":"ekmett"},"version":"7.8.4","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["core-libraries-committee@haskell.org"],"type":"Bug","description":"The Haddock documentation for `Ix` [http://hackage.haskell.org/package/base-4.7.0.2/docs/Data-Ix.html here] says that the minimal definition requires `range`, `index`, and `inRange`. But then it says that the minimal definition requires `range` and `inRange`. It seems that Haddock is inferring a `MINIMAL` definition where none is in the code. Perhaps a `MINIMAL` should be added.","type_of_failure":"OtherFailure","blocking":[]} -->7.10.1Herbert Valerio Riedelhvr@gnu.orgHerbert Valerio Riedelhvr@gnu.orghttps://gitlab.haskell.org/ghc/ghc/-/issues/10128Data.List.transpose needs more docs2019-07-07T18:37:23ZJoachim Breitnermail@joachim-breitner.deData.List.transpose needs more docsas mentioned by Doug McIlroy on haskell-prime.
My preference in the interest of brevity would be to not include the equations that Doug mentioned and simply add his nicely constructed educating example to the docs:
> The transpose func...as mentioned by Doug McIlroy on haskell-prime.
My preference in the interest of brevity would be to not include the equations that Doug mentioned and simply add his nicely constructed educating example to the docs:
> The transpose function transposes the rows and columns of its argument. For example,
>
> ```
> transpose [[1,2,3],[4,5,6]] == [[1,4],[2,5],[3,6]]
> ```
>
> If some of the rows are shorter than the following rows, their elements are skipped:
>
> ```
> transpose [[10,11],[20],[],[30,31,32]] == [[10,20,30],[11,31],[32]]
> ```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------------------------------ |
| Version | 7.8.4 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Core Libraries |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | core-libraries-committee@haskell.org |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Data.List.transpose needs more docs","status":"New","operating_system":"","component":"Core Libraries","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"OwnedBy","contents":"ekmett"},"version":"7.8.4","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["core-libraries-committee@haskell.org"],"type":"Bug","description":"as mentioned by Doug McIlroy on haskell-prime.\r\n\r\nMy preference in the interest of brevity would be to not include the equations that Doug mentioned and simply add his nicely constructed educating example to the docs:\r\n\r\n> The transpose function transposes the rows and columns of its argument. For example,\r\n> \r\n> {{{\r\n> transpose [[1,2,3],[4,5,6]] == [[1,4],[2,5],[3,6]]\r\n> }}}\r\n> \r\n> If some of the rows are shorter than the following rows, their elements are skipped:\r\n> \r\n> {{{\r\n> transpose [[10,11],[20],[],[30,31,32]] == [[10,20,30],[11,31],[32]]\r\n> }}}\r\n\r\n","type_of_failure":"OtherFailure","blocking":[]} -->7.10.1Edward KmettEdward Kmetthttps://gitlab.haskell.org/ghc/ghc/-/issues/10113Re-export (<$>) and (<$) from Prelude2019-07-07T18:37:27ZHerbert Valerio Riedelhvr@gnu.orgRe-export (<$>) and (<$) from PreludeSee http://thread.gmane.org/gmane.comp.lang.haskell.libraries/24161 for details
decision is still outstanding, but this needs to go into RC3 unless there's good reasons not to
<details><summary>Trac metadata</summary>
| Trac field ...See http://thread.gmane.org/gmane.comp.lang.haskell.libraries/24161 for details
decision is still outstanding, but this needs to go into RC3 unless there's good reasons not to
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------------------- |
| Version | 7.10.1-rc2 |
| Type | FeatureRequest |
| TypeOfFailure | OtherFailure |
| Priority | highest |
| Resolution | Unresolved |
| Component | libraries/base |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | ekmett, hvr, thoughtpolice |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Re-export (<$>) from Prelude","status":"New","operating_system":"","component":"libraries/base","related":[],"milestone":"7.10.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.10.1-rc2","keywords":["AMP"],"differentials":[],"test_case":"","architecture":"","cc":["ekmett","hvr","thoughtpolice"],"type":"FeatureRequest","description":"See http://thread.gmane.org/gmane.comp.lang.haskell.libraries/24161 for details\r\n\r\ndecision is still outstanding, but this needs to go into RC3 unless there's good reasons not to","type_of_failure":"OtherFailure","blocking":[]} -->7.10.1https://gitlab.haskell.org/ghc/ghc/-/issues/10088Broken link in Data.Ix documentation2019-07-07T18:37:36ZDavid FeuerBroken link in Data.Ix documentationThe Haddock documentation for `Data.Ix` includes the following line:
> For single-constructor datatypes, the derived instance declarations are as shown for tuples in Figure 1 http://www.haskell.org/onlinelibrary/ix.html\#prelude-index....The Haddock documentation for `Data.Ix` includes the following line:
> For single-constructor datatypes, the derived instance declarations are as shown for tuples in Figure 1 http://www.haskell.org/onlinelibrary/ix.html\#prelude-index.
This link is dead.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------------------------------ |
| Version | 7.11 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Core Libraries |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | core-libraries-committee@haskell.org |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Broken link in Data.Ix documentation","status":"New","operating_system":"","component":"Core Libraries","related":[],"milestone":"7.10.1","resolution":"Unresolved","owner":{"tag":"OwnedBy","contents":"ekmett"},"version":"7.11","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["core-libraries-committee@haskell.org"],"type":"Bug","description":"The Haddock documentation for `Data.Ix` includes the following line:\r\n\r\n For single-constructor datatypes, the derived instance declarations are as shown for tuples in Figure 1 http://www.haskell.org/onlinelibrary/ix.html#prelude-index.\r\n\r\nThis link is dead.","type_of_failure":"OtherFailure","blocking":[]} -->7.10.1Edward KmettEdward Kmetthttps://gitlab.haskell.org/ghc/ghc/-/issues/10011The Data instance for Ratio violates internal invariants.2019-07-07T18:37:56ZEdward KmettThe Data instance for Ratio violates internal invariants.I found this when Simon was cleaning up unused dependencies in
https://phabricator.haskell.org/rGHCc409b6f30373535b6eed92e55d4695688d32be9e#10730
The Data instance for Ratio just uses the raw `(:%)` constructor and doesn't check that t...I found this when Simon was cleaning up unused dependencies in
https://phabricator.haskell.org/rGHCc409b6f30373535b6eed92e55d4695688d32be9e#10730
The Data instance for Ratio just uses the raw `(:%)` constructor and doesn't check that the result is reduced to normal form.
It strikes me that the fix is to add back the Integral constraint on the Data instance and to use `(%)` rather than `(:%)` in the `gfoldl` and `gunfold` code.
This restores the invariant and matches the behavior of "virtual constructors" we've used to patch up such problems elsewhere.7.10.1https://gitlab.haskell.org/ghc/ghc/-/issues/9984Show, Read, Eq, Ord instances for Control.Applicative.Const2019-07-07T18:38:03ZFumiaki KinoshitaShow, Read, Eq, Ord instances for Control.Applicative.ConstAs mentioned in https://www.haskell.org/pipermail/libraries/2013-October/021531.html, the following instances can be derived clearly:
- `Show a => Show (Const a b)`
- `Read a => Read (Const a b)`
- `Eq a => Eq (Const a b)`
- `Ord a => O...As mentioned in https://www.haskell.org/pipermail/libraries/2013-October/021531.html, the following instances can be derived clearly:
- `Show a => Show (Const a b)`
- `Read a => Read (Const a b)`
- `Eq a => Eq (Const a b)`
- `Ord a => Ord (Const a b)`
The absence of these instances makes debugging harder.
I suggest handcrafted Show/Read instances for neat representation.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 7.8.4 |
| Type | FeatureRequest |
| TypeOfFailure | OtherFailure |
| Priority | low |
| Resolution | Unresolved |
| Component | libraries/base |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | ekmett, hvr |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Show, Read, Eq, Ord instances for Control.Applicative.Const","status":"New","operating_system":"","component":"libraries/base","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.8.4","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["ekmett","hvr"],"type":"FeatureRequest","description":"As mentioned in https://www.haskell.org/pipermail/libraries/2013-October/021531.html, the following instances can be derived clearly:\r\n\r\n* `Show a => Show (Const a b)`\r\n* `Read a => Read (Const a b)`\r\n* `Eq a => Eq (Const a b)`\r\n* `Ord a => Ord (Const a b)`\r\n\r\nThe absence of these instances makes debugging harder.\r\n\r\nI suggest handcrafted Show/Read instances for neat representation.","type_of_failure":"OtherFailure","blocking":[]} -->7.10.1https://gitlab.haskell.org/ghc/ghc/-/issues/9949zipWith too strict in second argument in GHC-7.10.02019-07-07T18:38:15ZLemmingzipWith too strict in second argument in GHC-7.10.0correct:
```
$ ghci-7.8.4 -Wall
Prelude> zipWith (==) "" undefined
[]
```
incorrect:
```
$ ghci-7.10.0.20141227 -Wall
Prelude> zipWith (==) "" undefined
*** Exception: Prelude.undefined
```
<details><summary>Trac metadata</summary>
...correct:
```
$ ghci-7.8.4 -Wall
Prelude> zipWith (==) "" undefined
[]
```
incorrect:
```
$ ghci-7.10.0.20141227 -Wall
Prelude> zipWith (==) "" undefined
*** Exception: Prelude.undefined
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------------------------------ |
| Version | 7.10.1-rc1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Core Libraries |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | core-libraries-committee@haskell.org |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"zipWith too strict in second argument in GHC-7.10.0","status":"New","operating_system":"","component":"Core Libraries","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"OwnedBy","contents":"ekmett"},"version":"7.10.1-rc1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["core-libraries-committee@haskell.org"],"type":"Bug","description":"correct:\r\n{{{\r\n$ ghci-7.8.4 -Wall\r\nPrelude> zipWith (==) \"\" undefined\r\n[]\r\n}}}\r\n\r\nincorrect:\r\n{{{\r\n$ ghci-7.10.0.20141227 -Wall\r\nPrelude> zipWith (==) \"\" undefined\r\n*** Exception: Prelude.undefined\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->7.10.1Edward KmettEdward Kmetthttps://gitlab.haskell.org/ghc/ghc/-/issues/9934Typo in GHC.RTS.Flags2019-07-07T18:38:22ZRyan ScottTypo in GHC.RTS.FlagsCurrently, the `GCFlags` data type in the `GHC.RTS.Flags` module of `base-4.8.0.0` has a field named `heapSizeSuggesionAuto` (without a `t` in `Suggesion`). Given that the corresponding struct field in `rts/Flags.h` is named `heapSizeSug...Currently, the `GCFlags` data type in the `GHC.RTS.Flags` module of `base-4.8.0.0` has a field named `heapSizeSuggesionAuto` (without a `t` in `Suggesion`). Given that the corresponding struct field in `rts/Flags.h` is named `heapSizeSuggestionAuto`, this is probably a typo.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 7.10.1-rc1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | libraries/base |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | ekmett, hvr |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Typo in GHC.RTS.Flags","status":"New","operating_system":"","component":"libraries/base","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.10.1-rc1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["ekmett","hvr"],"type":"Bug","description":"Currently, the {{{GCFlags}}} data type in the {{{GHC.RTS.Flags}}} module of {{{base-4.8.0.0}}} has a field named {{{heapSizeSuggesionAuto}}} (without a {{{t}}} in {{{Suggesion}}}). Given that the corresponding struct field in {{{rts/Flags.h}}} is named {{{heapSizeSuggestionAuto}}}, this is probably a typo.","type_of_failure":"OtherFailure","blocking":[]} -->7.10.1https://gitlab.haskell.org/ghc/ghc/-/issues/9859Implement `calloc{,Bytes,Array,Array0}` allocators2019-07-07T18:38:44ZifesdjeenImplement `calloc{,Bytes,Array,Array0}` allocatorsAdd zero-initialising versions of malloc{,Bytes,Array,Array0}
- Add calloc and callocBytes to Foreign.Marshal.Alloc.
- Add callocArray and callocArray0 to Foreign.Marshal.Array.
Proposal Discussion: https://www.haskell.org/pipermail/li...Add zero-initialising versions of malloc{,Bytes,Array,Array0}
- Add calloc and callocBytes to Foreign.Marshal.Alloc.
- Add callocArray and callocArray0 to Foreign.Marshal.Array.
Proposal Discussion: https://www.haskell.org/pipermail/libraries/2014-November/024421.html7.10.1https://gitlab.haskell.org/ghc/ghc/-/issues/9836Facility to mitigate double-breakage due to Data.Version.versionTag Deprecation2019-07-07T18:38:51ZHerbert Valerio Riedelhvr@gnu.orgFacility to mitigate double-breakage due to Data.Version.versionTag DeprecationSee https://groups.google.com/forum/\#!topic/haskell-core-libraries/q9H-QlL_gnE
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version ...See https://groups.google.com/forum/\#!topic/haskell-core-libraries/q9H-QlL_gnE
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | |
| Type | Task |
| TypeOfFailure | OtherFailure |
| Priority | high |
| Resolution | Unresolved |
| Component | libraries/base |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | ekmett, hvr |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Facility to mitigate double-breakage due to Data.Version.versionTag Deprecation","status":"New","operating_system":"","component":"libraries/base","related":[],"milestone":"7.10.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"","keywords":["Data.Version"],"differentials":[],"test_case":"","architecture":"","cc":["ekmett","hvr"],"type":"Task","description":"\r\nSee https://groups.google.com/forum/#!topic/haskell-core-libraries/q9H-QlL_gnE","type_of_failure":"OtherFailure","blocking":[]} -->7.10.1https://gitlab.haskell.org/ghc/ghc/-/issues/9827void does not use <$2019-07-07T18:38:54ZDavid Feuervoid does not use <$`Data.Functor.void` is currently defined as
```hs
void = fmap (const ())
```
Some `Functor` instances have an optimized `<$`, so this should be
```hs
void x = () <$ x
```
<details><summary>Trac metadata</summary>
| Trac field ...`Data.Functor.void` is currently defined as
```hs
void = fmap (const ())
```
Some `Functor` instances have an optimized `<$`, so this should be
```hs
void x = () <$ x
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------------------------------ |
| Version | 7.9 |
| Type | Task |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Core Libraries |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | core-libraries-committee@haskell.org |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"void does not use <$","status":"New","operating_system":"","component":"Core Libraries","related":[],"milestone":"7.10.1","resolution":"Unresolved","owner":{"tag":"OwnedBy","contents":"dfeuer"},"version":"7.9","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["core-libraries-committee@haskell.org"],"type":"Task","description":"`Data.Functor.void` is currently defined as\r\n\r\n{{{#!hs\r\nvoid = fmap (const ())\r\n}}}\r\n\r\nSome `Functor` instances have an optimized `<$`, so this should be\r\n\r\n{{{#!hs\r\nvoid x = () <$ x\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->7.10.1David FeuerDavid Feuerhttps://gitlab.haskell.org/ghc/ghc/-/issues/9826add Storable Complex and Ratio instance to base library2019-07-07T18:38:54ZCarter Schonwaldadd Storable Complex and Ratio instance to base libraryper the libraries discussion + core libraries committee OK,
I'm putting a phab differential up for adding Storable instances for Complex and Ratio
(and then noticing that theres basically NO tests for Storable except indirectly)
the li...per the libraries discussion + core libraries committee OK,
I'm putting a phab differential up for adding Storable instances for Complex and Ratio
(and then noticing that theres basically NO tests for Storable except indirectly)
the libraries thread for Complex and Ratio
https://www.haskell.org/pipermail/libraries/2014-November/024064.html
the thread on the CLC list https://groups.google.com/forum/\#!topic/haskell-core-libraries/mjBSo2CQ3LU7.10.1Carter SchonwaldCarter Schonwaldhttps://gitlab.haskell.org/ghc/ghc/-/issues/9822Add displayException to Exception typeclass2023-02-21T20:57:05ZMichael Snoymanmichael@snoyman.comAdd displayException to Exception typeclassDiscussed on the libraries list at:
https://www.haskell.org/pipermail/libraries/2014-November/024176.html
I am only implementing part (1) of this proposal due to lack of consensus on part (2).
<details><summary>Trac metadata</summary>...Discussed on the libraries list at:
https://www.haskell.org/pipermail/libraries/2014-November/024176.html
I am only implementing part (1) of this proposal due to lack of consensus on part (2).
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 7.9 |
| Type | FeatureRequest |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | libraries/base |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | ekmett, hvr |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Add displayException to Exception typeclass","status":"New","operating_system":"","component":"libraries/base","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"OwnedBy","contents":"snoyberg"},"version":"7.9","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["ekmett","hvr"],"type":"FeatureRequest","description":"Discussed on the libraries list at:\r\n\r\nhttps://www.haskell.org/pipermail/libraries/2014-November/024176.html\r\n\r\nI am only implementing part (1) of this proposal due to lack of consensus on part (2).","type_of_failure":"OtherFailure","blocking":[]} -->7.10.1Michael Snoymanmichael@snoyman.comMichael Snoymanmichael@snoyman.comhttps://gitlab.haskell.org/ghc/ghc/-/issues/9818Add `Natural` number type to `base`2019-07-07T18:38:56ZHerbert Valerio Riedelhvr@gnu.orgAdd `Natural` number type to `base`See original proposal at
> http://thread.gmane.org/gmane.comp.lang.haskell.libraries/23300
which was generally met with unanimous support for adding such a type.
Request for CLC-arbitration (and its conclusion) on two more or less con...See original proposal at
> http://thread.gmane.org/gmane.comp.lang.haskell.libraries/23300
which was generally met with unanimous support for adding such a type.
Request for CLC-arbitration (and its conclusion) on two more or less controversial details lacking consensus:
> https://groups.google.com/forum/\#!msg/haskell-core-libraries/CVylSkkHCWE/Cqn7VEgR24sJ
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | |
| Type | FeatureRequest |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | #3650 |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Add `Natural` number type to `base`","status":"New","operating_system":"","component":"Compiler","related":[3650],"milestone":"7.10.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"FeatureRequest","description":"See original proposal at\r\n\r\n http://thread.gmane.org/gmane.comp.lang.haskell.libraries/23300\r\n\r\nwhich was generally met with unanimous support for adding such a type.\r\n\r\nRequest for CLC-arbitration (and its conclusion) on two more or less controversial details lacking consensus:\r\n\r\n https://groups.google.com/forum/#!msg/haskell-core-libraries/CVylSkkHCWE/Cqn7VEgR24sJ","type_of_failure":"OtherFailure","blocking":[]} -->7.10.1Herbert Valerio Riedelhvr@gnu.orgHerbert Valerio Riedelhvr@gnu.orghttps://gitlab.haskell.org/ghc/ghc/-/issues/9816Add function for size-checked conversion of Integral types2019-07-07T18:38:56ZsplAdd function for size-checked conversion of Integral typesBased on the discussion in [this thread](http://thread.gmane.org/gmane.comp.lang.haskell.libraries/23338), I would like to add a function to the `base` library that is similar to `fromIntegral` but only successful if the argument fits in...Based on the discussion in [this thread](http://thread.gmane.org/gmane.comp.lang.haskell.libraries/23338), I would like to add a function to the `base` library that is similar to `fromIntegral` but only successful if the argument fits in the result type.
If possible, I would like to get this into 7.10. My apologies for running late on it. Hopefully, since it is a relatively small change overall, the "only" controversy will be bikeshedding.
I have concluded that adding \@hvr's `intCastMaybe` from [int-cast](http://hackage.haskell.org/package/int-cast) is the best possible option. Previously, I thought a `Bounded`-based version was also useful; however, I realized that it did not deal optimally with conversions like `Int<->Word`/`Int8<->Word8`/etc. as well as `intCastMaybe` does and would need specialized versions that `intCastMaybe` provides automatically.7.10.1https://gitlab.haskell.org/ghc/ghc/-/issues/9814Add Data.Void to base2019-07-07T18:38:57ZshachafAdd Data.Void to baseLast year I [proposed](http://thread.gmane.org/gmane.comp.lang.haskell.libraries/19867) adding `Data.Void`, with a canonical uninhabited type `Void`, to base. This would replace the module of the same name in Edwardk Kmett's [void](http:...Last year I [proposed](http://thread.gmane.org/gmane.comp.lang.haskell.libraries/19867) adding `Data.Void`, with a canonical uninhabited type `Void`, to base. This would replace the module of the same name in Edwardk Kmett's [void](http://hackage.haskell.org/package/void) package (and in turn he'll update his package to reëxport the module from base).
The response to the proposal was mostly positive; there were a couple of objections to the name, but `Void` is so standard by now that it seems pointless to change it, and no better name was suggested. Unfortunately I never did anything about it at the end of the discussion period. Recently several people have asked me to move this proposal along, and I'm finally getting around to making the ticket. Hopefully it can happen before the 7.10 freeze.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------------------------------ |
| Version | 7.8.3 |
| Type | FeatureRequest |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Core Libraries |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | core-libraries-committee@haskell.org |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Add Data.Void to base","status":"New","operating_system":"","component":"Core Libraries","related":[],"milestone":"7.10.1","resolution":"Unresolved","owner":{"tag":"OwnedBy","contents":"ekmett"},"version":"7.8.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["core-libraries-committee@haskell.org"],"type":"FeatureRequest","description":"Last year I [http://thread.gmane.org/gmane.comp.lang.haskell.libraries/19867 proposed] adding `Data.Void`, with a canonical uninhabited type `Void`, to base. This would replace the module of the same name in Edwardk Kmett's [http://hackage.haskell.org/package/void void] package (and in turn he'll update his package to reëxport the module from base).\r\n\r\nThe response to the proposal was mostly positive; there were a couple of objections to the name, but `Void` is so standard by now that it seems pointless to change it, and no better name was suggested. Unfortunately I never did anything about it at the end of the discussion period. Recently several people have asked me to move this proposal along, and I'm finally getting around to making the ticket. Hopefully it can happen before the 7.10 freeze.","type_of_failure":"OtherFailure","blocking":[]} -->7.10.1Herbert Valerio Riedelhvr@gnu.orgHerbert Valerio Riedelhvr@gnu.orghttps://gitlab.haskell.org/ghc/ghc/-/issues/9801Make listArray fuse2019-07-07T18:39:00ZDavid FeuerMake listArray fuse`GHC.Arr.listArray` does not currently fuse with a good list producer. Let's make that happen.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -----...`GHC.Arr.listArray` does not currently fuse with a good list producer. Let's make that happen.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------------------------------ |
| Version | 7.9 |
| Type | Task |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Core Libraries |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | core-libraries-committee@haskell.org |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Make listArray fuse","status":"New","operating_system":"","component":"Core Libraries","related":[],"milestone":"7.10.1","resolution":"Unresolved","owner":{"tag":"OwnedBy","contents":"dfeuer"},"version":"7.9","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["core-libraries-committee@haskell.org"],"type":"Task","description":"`GHC.Arr.listArray` does not currently fuse with a good list producer. Let's make that happen.","type_of_failure":"OtherFailure","blocking":[]} -->7.10.1David FeuerDavid Feuerhttps://gitlab.haskell.org/ghc/ghc/-/issues/9796Implement amap/coerce rule for `Array`2019-07-07T18:39:01ZDavid FeuerImplement amap/coerce rule for `Array`We have `map/coerce`; there's no reason not to have `amap/coerce` as well.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------------------...We have `map/coerce`; there's no reason not to have `amap/coerce` as well.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------------------------------ |
| Version | 7.9 |
| Type | Task |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Core Libraries |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | core-libraries-committee@haskell.org |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Implement amap/coerce rule for `Array`","status":"New","operating_system":"","component":"Core Libraries","related":[],"milestone":"7.10.1","resolution":"Unresolved","owner":{"tag":"OwnedBy","contents":"dfeuer"},"version":"7.9","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["core-libraries-committee@haskell.org"],"type":"Task","description":"We have `map/coerce`; there's no reason not to have `amap/coerce` as well.","type_of_failure":"OtherFailure","blocking":[]} -->7.10.1David FeuerDavid Feuerhttps://gitlab.haskell.org/ghc/ghc/-/issues/9781Make list monad operations fuse2019-07-07T18:39:04ZDavid FeuerMake list monad operations fuseWe like to think that `do {x <- xs; y <- f x ; return g y}` is the same as `[g y | x <- xs, y <- f x]`, but the former does not fuse nearly as well. Let's fix that.
<details><summary>Trac metadata</summary>
| Trac field | V...We like to think that `do {x <- xs; y <- f x ; return g y}` is the same as `[g y | x <- xs, y <- f x]`, but the former does not fuse nearly as well. Let's fix that.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------------------------------ |
| Version | 7.9 |
| Type | Task |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Core Libraries |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | core-libraries-committee@haskell.org |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Make list monad operations fuse","status":"New","operating_system":"","component":"Core Libraries","related":[],"milestone":"7.10.1","resolution":"Unresolved","owner":{"tag":"OwnedBy","contents":"dfeuer"},"version":"7.9","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["core-libraries-committee@haskell.org"],"type":"Task","description":"We like to think that `do {x <- xs; y <- f x ; return g y}` is the same as `[g y | x <- xs, y <- f x]`, but the former does not fuse nearly as well. Let's fix that.","type_of_failure":"OtherFailure","blocking":[]} -->7.10.1David FeuerDavid Feuer