GHC issueshttps://gitlab.haskell.org/ghc/ghc/-/issues2019-07-07T18:39:08Zhttps://gitlab.haskell.org/ghc/ghc/-/issues/9767Add isSubsequenceOf to Data.List2019-07-07T18:39:08ZbernalexAdd isSubsequenceOf to Data.ListNiklas Hambüchen suggested that we add the dual of subsequences,
isSubsequenceOf (like isPrefixOf to inits & isSuffixOf to tails)\[1\]. It
was a simple and noncontroversial proposal which received unanimous +1s.
\[1\]
> https://www.haskell.org/pipermail/libraries/2014-November/024063.html
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 7.8.3 |
| 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 isSubsequenceOf to Data.List","status":"New","operating_system":"","component":"libraries/base","related":[],"milestone":"7.10.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.8.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["ekmett","hvr"],"type":"FeatureRequest","description":"Niklas Hambüchen suggested that we add the dual of subsequences, \r\nisSubsequenceOf (like isPrefixOf to inits & isSuffixOf to tails)[1]. It \r\nwas a simple and noncontroversial proposal which received unanimous +1s.\r\n\r\n[1]\r\n https://www.haskell.org/pipermail/libraries/2014-November/024063.html","type_of_failure":"OtherFailure","blocking":[]} -->Niklas Hambüchen suggested that we add the dual of subsequences,
isSubsequenceOf (like isPrefixOf to inits & isSuffixOf to tails)\[1\]. It
was a simple and noncontroversial proposal which received unanimous +1s.
\[1\]
> https://www.haskell.org/pipermail/libraries/2014-November/024063.html
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 7.8.3 |
| 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 isSubsequenceOf to Data.List","status":"New","operating_system":"","component":"libraries/base","related":[],"milestone":"7.10.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.8.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["ekmett","hvr"],"type":"FeatureRequest","description":"Niklas Hambüchen suggested that we add the dual of subsequences, \r\nisSubsequenceOf (like isPrefixOf to inits & isSuffixOf to tails)[1]. It \r\nwas a simple and noncontroversial proposal which received unanimous +1s.\r\n\r\n[1]\r\n https://www.haskell.org/pipermail/libraries/2014-November/024063.html","type_of_failure":"OtherFailure","blocking":[]} -->7.10.1https://gitlab.haskell.org/ghc/ghc/-/issues/9664Add identity functor to base2019-07-07T18:39:36ZHerbert Valerio Riedelhvr@gnu.orgAdd identity functor to base`base` already provides a `Const`ant functor, but the even more useful `Id`entity (or `Identity`) functor does not exist in `base` yet.
This was already [proposed to the CLC back in early 2013](https://groups.google.com/forum/#!msg/haskell-core-libraries/_nReDCbROew/Mdmf0zIloysJ), and already missed inclusion in GHC 7.8
However, in order to implement this, coordination with `transformers` is desirable, as `transformers` currently provides a non-transforming `Data.Functor.Identity`, and we'd like to avoid name clashes.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | --------------------- |
| Version | |
| Type | Task |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Core Libraries |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | ekmett, ross, simonpj |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Add identity functor to base","status":"New","operating_system":"","component":"Core Libraries","related":[],"milestone":"7.10.1","resolution":"Unresolved","owner":{"tag":"OwnedBy","contents":"ekmett"},"version":"","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["ekmett","ross","simonpj"],"type":"Task","description":"`base` already provides a `Const`ant functor, but the even more useful `Id`entity (or `Identity`) functor does not exist in `base` yet.\r\n\r\nThis was already [https://groups.google.com/forum/#!msg/haskell-core-libraries/_nReDCbROew/Mdmf0zIloysJ proposed to the CLC back in early 2013], and already missed inclusion in GHC 7.8\r\n\r\nHowever, in order to implement this, coordination with `transformers` is desirable, as `transformers` currently provides a non-transforming `Data.Functor.Identity`, and we'd like to avoid name clashes.","type_of_failure":"OtherFailure","blocking":[]} -->`base` already provides a `Const`ant functor, but the even more useful `Id`entity (or `Identity`) functor does not exist in `base` yet.
This was already [proposed to the CLC back in early 2013](https://groups.google.com/forum/#!msg/haskell-core-libraries/_nReDCbROew/Mdmf0zIloysJ), and already missed inclusion in GHC 7.8
However, in order to implement this, coordination with `transformers` is desirable, as `transformers` currently provides a non-transforming `Data.Functor.Identity`, and we'd like to avoid name clashes.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | --------------------- |
| Version | |
| Type | Task |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Core Libraries |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | ekmett, ross, simonpj |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Add identity functor to base","status":"New","operating_system":"","component":"Core Libraries","related":[],"milestone":"7.10.1","resolution":"Unresolved","owner":{"tag":"OwnedBy","contents":"ekmett"},"version":"","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["ekmett","ross","simonpj"],"type":"Task","description":"`base` already provides a `Const`ant functor, but the even more useful `Id`entity (or `Identity`) functor does not exist in `base` yet.\r\n\r\nThis was already [https://groups.google.com/forum/#!msg/haskell-core-libraries/_nReDCbROew/Mdmf0zIloysJ proposed to the CLC back in early 2013], and already missed inclusion in GHC 7.8\r\n\r\nHowever, in order to implement this, coordination with `transformers` is desirable, as `transformers` currently provides a non-transforming `Data.Functor.Identity`, and we'd like to avoid name clashes.","type_of_failure":"OtherFailure","blocking":[]} -->7.10.1Edward KmettEdward Kmetthttps://gitlab.haskell.org/ghc/ghc/-/issues/9590AMP breaks `haskell2010` package2019-07-07T18:39:54ZHerbert Valerio Riedelhvr@gnu.orgAMP breaks `haskell2010` package(and probably also `haskell98`)
I hate to be the one pointing this out, but the AMP has one ugly side-effect:
As of now, GHC HEAD rejects Haskell2010 programs (which know nothing about the `Applicative` class). Moreover, there's no simple way to access the `Applicative` class in order to write an instance to satisfy non-standard superclass requirement, so it's impossible to define custom `Monad` instances.
For instance, consider the following session which worked in GHC 7.6.3 (albeit with an AMP warning):
```
$ inplace/bin/ghc-stage2 --interactive -XHaskell2010 -hide-all-packages -package haskell2010
GHCi, version 7.9.20140914: http://www.haskell.org/ghc/ :? for help
Loading package ghc-prim-0.3.1.0 ... linking ... done.
Loading package integer-gmp-0.5.1.0 ... linking ... done.
Loading package base-4.8.0.0 ... linking ... done.
Loading package array-0.5.0.1 ... linking ... done.
Loading package haskell2010-1.1.2.1 ... linking ... done.
λ:2> data Identity a = Identity a
data Identity a = Identity a
λ:3> instance Monad Identity
<interactive>:3:10:
No instance for (base-4.8.0.0:GHC.Base.Applicative Identity) arising from the superclasses of an instance declaration
In the instance declaration for ‘Monad Identity’
λ:4> :info Monad
class base-4.8.0.0:GHC.Base.Applicative m => Monad (m :: * -> *) where
(>>=) :: m a -> (a -> m b) -> m b
(>>) :: m a -> m b -> m b
return :: a -> m a
fail :: String -> m a
-- Defined in ‘base-4.8.0.0:GHC.Base’
instance Monad (Either e) -- Defined in ‘base-4.8.0.0:Data.Either’
instance Monad Maybe -- Defined in ‘base-4.8.0.0:Data.Maybe’
instance Monad [] -- Defined in ‘base-4.8.0.0:GHC.Base’
instance Monad IO -- Defined in ‘base-4.8.0.0:GHC.Base’
instance Monad ((->) r) -- Defined in ‘base-4.8.0.0:GHC.Base’
λ:5>
```(and probably also `haskell98`)
I hate to be the one pointing this out, but the AMP has one ugly side-effect:
As of now, GHC HEAD rejects Haskell2010 programs (which know nothing about the `Applicative` class). Moreover, there's no simple way to access the `Applicative` class in order to write an instance to satisfy non-standard superclass requirement, so it's impossible to define custom `Monad` instances.
For instance, consider the following session which worked in GHC 7.6.3 (albeit with an AMP warning):
```
$ inplace/bin/ghc-stage2 --interactive -XHaskell2010 -hide-all-packages -package haskell2010
GHCi, version 7.9.20140914: http://www.haskell.org/ghc/ :? for help
Loading package ghc-prim-0.3.1.0 ... linking ... done.
Loading package integer-gmp-0.5.1.0 ... linking ... done.
Loading package base-4.8.0.0 ... linking ... done.
Loading package array-0.5.0.1 ... linking ... done.
Loading package haskell2010-1.1.2.1 ... linking ... done.
λ:2> data Identity a = Identity a
data Identity a = Identity a
λ:3> instance Monad Identity
<interactive>:3:10:
No instance for (base-4.8.0.0:GHC.Base.Applicative Identity) arising from the superclasses of an instance declaration
In the instance declaration for ‘Monad Identity’
λ:4> :info Monad
class base-4.8.0.0:GHC.Base.Applicative m => Monad (m :: * -> *) where
(>>=) :: m a -> (a -> m b) -> m b
(>>) :: m a -> m b -> m b
return :: a -> m a
fail :: String -> m a
-- Defined in ‘base-4.8.0.0:GHC.Base’
instance Monad (Either e) -- Defined in ‘base-4.8.0.0:Data.Either’
instance Monad Maybe -- Defined in ‘base-4.8.0.0:Data.Maybe’
instance Monad [] -- Defined in ‘base-4.8.0.0:GHC.Base’
instance Monad IO -- Defined in ‘base-4.8.0.0:GHC.Base’
instance Monad ((->) r) -- Defined in ‘base-4.8.0.0:GHC.Base’
λ:5>
```7.10.1Edward KmettEdward Kmetthttps://gitlab.haskell.org/ghc/ghc/-/issues/9588Add `MonadPlus (Either e)` and `Alternative (Either e)` instances2019-07-07T18:39:54ZHerbert Valerio Riedelhvr@gnu.orgAdd `MonadPlus (Either e)` and `Alternative (Either e)` instancesThe following 2 instances are currently Orphans in `transformers` but could be defined in `base` without instead:
```hs
instance Error e => MonadPlus (Either e)
instance Error e => Alterantive (Either e)
```
This would, however, require us to move `Error` from `transformers` into base, which may be a controversial move.The following 2 instances are currently Orphans in `transformers` but could be defined in `base` without instead:
```hs
instance Error e => MonadPlus (Either e)
instance Error e => Alterantive (Either e)
```
This would, however, require us to move `Error` from `transformers` into base, which may be a controversial move.⊥Herbert Valerio Riedelhvr@gnu.orgHerbert Valerio Riedelhvr@gnu.orghttps://gitlab.haskell.org/ghc/ghc/-/issues/9586Implement Traversable/Foldable-Burning-Bridges Proposal2019-07-07T18:39:55ZHerbert Valerio Riedelhvr@gnu.orgImplement Traversable/Foldable-Burning-Bridges ProposalMore details to follow. I've created this ticket to be able to refer to from related preparatory commits.
In a nutshell the FTP (Foldable/Traversable-Proposal) sub-goal of the BBP (Burning-Bridges-Proposal) includes to be able to compile code like the following w/o errors (due to conflicting definitions):
```hs
module XPrelude (module X) where
import Data.Foldable as X
import Data.Traversable as X
import Data.List as X
import Control.Monad as X
import Prelude as X
```
Other goals include to generalise/weaken type-signatures where possible w/o breaking (much) compatibility with existing code. An in-depth design-document is in the works.More details to follow. I've created this ticket to be able to refer to from related preparatory commits.
In a nutshell the FTP (Foldable/Traversable-Proposal) sub-goal of the BBP (Burning-Bridges-Proposal) includes to be able to compile code like the following w/o errors (due to conflicting definitions):
```hs
module XPrelude (module X) where
import Data.Foldable as X
import Data.Traversable as X
import Data.List as X
import Control.Monad as X
import Prelude as X
```
Other goals include to generalise/weaken type-signatures where possible w/o breaking (much) compatibility with existing code. An in-depth design-document is in the works.7.10.1Herbert Valerio Riedelhvr@gnu.orgHerbert Valerio Riedelhvr@gnu.orghttps://gitlab.haskell.org/ghc/ghc/-/issues/9573Add warning for invalid digits in integer literals2019-07-07T18:39:58ZvlopezAdd warning for invalid digits in integer literalsIn its latest version, GHC can parse binary (with `-XBinaryLiterals`), octal and hexadecimal literals:
```hs
> 0b101010
> 0o52
> 0x2A
```
Currently, the parser/lexer reads digits from the input as long as they are valid for the specified radix. All subsequent digits are interpreted as a new, separate token.
If the user uses a digit which isn't valid for the radix, it may be reported with a non-obvious error message, or interpreted in surprising ways:
```hs
> :t 0o567
0o576 :: Num a => a
> :t 0o5678
0o5678 :: (Num (a -> t), Num a) => t
> :t 0x1bfah
<interactive>:1:7: Not in scope: ‘h’
> replicate 0o5678
[8,8,8,8,8,8,8...
```
We suggest warning the user when a literal of this sort is written, while respecting any other error messages and the original behaviour.
More specifically, the parser or lexer would give a warning if a token starting with an alphanumeric character is found immediately after a numeric literal, without a blank between them.In its latest version, GHC can parse binary (with `-XBinaryLiterals`), octal and hexadecimal literals:
```hs
> 0b101010
> 0o52
> 0x2A
```
Currently, the parser/lexer reads digits from the input as long as they are valid for the specified radix. All subsequent digits are interpreted as a new, separate token.
If the user uses a digit which isn't valid for the radix, it may be reported with a non-obvious error message, or interpreted in surprising ways:
```hs
> :t 0o567
0o576 :: Num a => a
> :t 0o5678
0o5678 :: (Num (a -> t), Num a) => t
> :t 0x1bfah
<interactive>:1:7: Not in scope: ‘h’
> replicate 0o5678
[8,8,8,8,8,8,8...
```
We suggest warning the user when a literal of this sort is written, while respecting any other error messages and the original behaviour.
More specifically, the parser or lexer would give a warning if a token starting with an alphanumeric character is found immediately after a numeric literal, without a blank between them.8.0.1vlopezvlopezhttps://gitlab.haskell.org/ghc/ghc/-/issues/9550Add uncons to Data.List2019-07-07T18:40:03ZDavid FeuerAdd uncons to Data.ListThis was [discussed on the libraries list](http://www.haskell.org/pipermail/libraries/2014-July/023314.html) and favourably receivedThis was [discussed on the libraries list](http://www.haskell.org/pipermail/libraries/2014-July/023314.html) and favourably received7.10.1https://gitlab.haskell.org/ghc/ghc/-/issues/9532Expose new CLZ/CTZ primops via `Data.Bits` interface2019-07-07T18:40:08ZHerbert Valerio Riedelhvr@gnu.orgExpose new CLZ/CTZ primops via `Data.Bits` interfaceGHC now provides optimized CLZ/CTZ primops (see #9340), this ticket is about exposing those in a more convenient way.
This was proposed as
> http://www.haskell.org/pipermail/libraries/2014-August/023567.html
and passed (see also [proposal summary](http://www.haskell.org/pipermail/libraries/2014-August/023657.html))GHC now provides optimized CLZ/CTZ primops (see #9340), this ticket is about exposing those in a more convenient way.
This was proposed as
> http://www.haskell.org/pipermail/libraries/2014-August/023567.html
and passed (see also [proposal summary](http://www.haskell.org/pipermail/libraries/2014-August/023657.html))7.10.1Herbert Valerio Riedelhvr@gnu.orgHerbert Valerio Riedelhvr@gnu.orghttps://gitlab.haskell.org/ghc/ghc/-/issues/9531Implement Prelude.Word Proposal2019-07-07T18:40:08ZHerbert Valerio Riedelhvr@gnu.orgImplement Prelude.Word ProposalThis was proposed on the libraries list and succeeded by vote majority as well as by explicit
confirmation from the core libraries committee.
See [proposal summary](http://www.haskell.org/pipermail/libraries/2014-August/023658.html) for details.This was proposed on the libraries list and succeeded by vote majority as well as by explicit
confirmation from the core libraries committee.
See [proposal summary](http://www.haskell.org/pipermail/libraries/2014-August/023658.html) for details.7.10.1Herbert Valerio Riedelhvr@gnu.orgHerbert Valerio Riedelhvr@gnu.orghttps://gitlab.haskell.org/ghc/ghc/-/issues/9385Additions to Control.Monad2019-07-07T18:40:37ZolfAdditions to Control.MonadI'd like to propose the following additions/changes to Control.Monad:
`mfilter` can be generalised:
```hs
gen_mfilter :: Monad m => (a -> m ()) -> m a -> m a
gen_mfilter f ma = (\a -> liftM (const a) (f a)) =<< ma
```
Now we obtain the old `mfilter` as
```hs
gen_mfilter.(guard.)
```
Further, `m ()` is a monoid for every monad, which would cause conflicts for `[()]`, to name one example. (The usual monoid instance of `[()]` is addition of natural numbers, while the monadic monoid instance is multiplication.) More generally, the monoid `m ()` acts on every type `m a` in the following way:
```hs
mtimes :: Monad m => m () -> m a -> m a
mtimes = gen_mfilter.const = liftM2 (flip const)
when = mtimes.guard
```
For example, each element of a list can be duplicated like this:
```hs
mtimes [(),()]
```
To see why these functions are useful, consider the `DDist` monad of the ProbabilityMonads package: Since `DDist ()` is essentially the monoid of real numbers with multiplication, `gen_mfilter f` updates a distribution by multiplying the weight of `x` by `f x`.
Another example is the state monad `ST s`, where type `(a -> ST s ())` is essentially `a -> s -> s`, so these functions encode changes that, when used with `gen_mfilter` alter state, not the value.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 7.8.2 |
| 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":"Additions to Control.Monad","status":"New","operating_system":"","component":"libraries/base","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.8.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["ekmett","hvr"],"type":"FeatureRequest","description":"I'd like to propose the following additions/changes to Control.Monad:\r\n`mfilter` can be generalised: \r\n{{{#!hs\r\ngen_mfilter :: Monad m => (a -> m ()) -> m a -> m a\r\ngen_mfilter f ma = (\\a -> liftM (const a) (f a)) =<< ma\r\n}}}\r\nNow we obtain the old `mfilter` as \r\n{{{#!hs\r\ngen_mfilter.(guard.)\r\n}}}\r\nFurther, `m ()` is a monoid for every monad, which would cause conflicts for `[()]`, to name one example. (The usual monoid instance of `[()]` is addition of natural numbers, while the monadic monoid instance is multiplication.) More generally, the monoid `m ()` acts on every type `m a` in the following way:\r\n{{{#!hs\r\nmtimes :: Monad m => m () -> m a -> m a\r\nmtimes = gen_mfilter.const = liftM2 (flip const)\r\nwhen = mtimes.guard\r\n}}}\r\nFor example, each element of a list can be duplicated like this: \r\n{{{#!hs\r\nmtimes [(),()]\r\n}}}\r\nTo see why these functions are useful, consider the `DDist` monad of the ProbabilityMonads package: Since `DDist ()` is essentially the monoid of real numbers with multiplication, `gen_mfilter f` updates a distribution by multiplying the weight of `x` by `f x`. \r\nAnother example is the state monad `ST s`, where type `(a -> ST s ())` is essentially `a -> s -> s`, so these functions encode changes that, when used with `gen_mfilter` alter state, not the value.","type_of_failure":"OtherFailure","blocking":[]} -->I'd like to propose the following additions/changes to Control.Monad:
`mfilter` can be generalised:
```hs
gen_mfilter :: Monad m => (a -> m ()) -> m a -> m a
gen_mfilter f ma = (\a -> liftM (const a) (f a)) =<< ma
```
Now we obtain the old `mfilter` as
```hs
gen_mfilter.(guard.)
```
Further, `m ()` is a monoid for every monad, which would cause conflicts for `[()]`, to name one example. (The usual monoid instance of `[()]` is addition of natural numbers, while the monadic monoid instance is multiplication.) More generally, the monoid `m ()` acts on every type `m a` in the following way:
```hs
mtimes :: Monad m => m () -> m a -> m a
mtimes = gen_mfilter.const = liftM2 (flip const)
when = mtimes.guard
```
For example, each element of a list can be duplicated like this:
```hs
mtimes [(),()]
```
To see why these functions are useful, consider the `DDist` monad of the ProbabilityMonads package: Since `DDist ()` is essentially the monoid of real numbers with multiplication, `gen_mfilter f` updates a distribution by multiplying the weight of `x` by `f x`.
Another example is the state monad `ST s`, where type `(a -> ST s ())` is essentially `a -> s -> s`, so these functions encode changes that, when used with `gen_mfilter` alter state, not the value.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 7.8.2 |
| 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":"Additions to Control.Monad","status":"New","operating_system":"","component":"libraries/base","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.8.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["ekmett","hvr"],"type":"FeatureRequest","description":"I'd like to propose the following additions/changes to Control.Monad:\r\n`mfilter` can be generalised: \r\n{{{#!hs\r\ngen_mfilter :: Monad m => (a -> m ()) -> m a -> m a\r\ngen_mfilter f ma = (\\a -> liftM (const a) (f a)) =<< ma\r\n}}}\r\nNow we obtain the old `mfilter` as \r\n{{{#!hs\r\ngen_mfilter.(guard.)\r\n}}}\r\nFurther, `m ()` is a monoid for every monad, which would cause conflicts for `[()]`, to name one example. (The usual monoid instance of `[()]` is addition of natural numbers, while the monadic monoid instance is multiplication.) More generally, the monoid `m ()` acts on every type `m a` in the following way:\r\n{{{#!hs\r\nmtimes :: Monad m => m () -> m a -> m a\r\nmtimes = gen_mfilter.const = liftM2 (flip const)\r\nwhen = mtimes.guard\r\n}}}\r\nFor example, each element of a list can be duplicated like this: \r\n{{{#!hs\r\nmtimes [(),()]\r\n}}}\r\nTo see why these functions are useful, consider the `DDist` monad of the ProbabilityMonads package: Since `DDist ()` is essentially the monoid of real numbers with multiplication, `gen_mfilter f` updates a distribution by multiplying the weight of `x` by `f x`. \r\nAnother example is the state monad `ST s`, where type `(a -> ST s ())` is essentially `a -> s -> s`, so these functions encode changes that, when used with `gen_mfilter` alter state, not the value.","type_of_failure":"OtherFailure","blocking":[]} -->Edward KmettEdward Kmetthttps://gitlab.haskell.org/ghc/ghc/-/issues/9099Add strict fmap2019-07-07T18:41:55ZquchenAdd strict fmapAdd a strict version of fmap to the standard libraries.
```
infixl 4 <$!>
(<$!>) :: Monad m => (a -> b) -> m a -> m b
f <$!> m = do x <- m
return $! f x
{-# INLINE (<$!>) #-}
```
Libraries discussions:
Take 1: http://www.haskell.org/pipermail/libraries/2013-November/021728.html
Take 3: http://www.haskell.org/pipermail/libraries/2014-April/022864.html
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 7.8.2 |
| Type | FeatureRequest |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | None |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Add strict fmap","status":"New","operating_system":"","component":"None","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.8.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"FeatureRequest","description":"Add a strict version of fmap to the standard libraries.\r\n\r\n{{{\r\ninfixl 4 <$!>\r\n \r\n(<$!>) :: Monad m => (a -> b) -> m a -> m b\r\nf <$!> m = do x <- m\r\n return $! f x\r\n{-# INLINE (<$!>) #-}\r\n}}}\r\n\r\nLibraries discussions:\r\n\r\nTake 1: http://www.haskell.org/pipermail/libraries/2013-November/021728.html\r\nTake 3: http://www.haskell.org/pipermail/libraries/2014-April/022864.html","type_of_failure":"OtherFailure","blocking":[]} -->Add a strict version of fmap to the standard libraries.
```
infixl 4 <$!>
(<$!>) :: Monad m => (a -> b) -> m a -> m b
f <$!> m = do x <- m
return $! f x
{-# INLINE (<$!>) #-}
```
Libraries discussions:
Take 1: http://www.haskell.org/pipermail/libraries/2013-November/021728.html
Take 3: http://www.haskell.org/pipermail/libraries/2014-April/022864.html
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 7.8.2 |
| Type | FeatureRequest |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | None |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Add strict fmap","status":"New","operating_system":"","component":"None","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.8.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"FeatureRequest","description":"Add a strict version of fmap to the standard libraries.\r\n\r\n{{{\r\ninfixl 4 <$!>\r\n \r\n(<$!>) :: Monad m => (a -> b) -> m a -> m b\r\nf <$!> m = do x <- m\r\n return $! f x\r\n{-# INLINE (<$!>) #-}\r\n}}}\r\n\r\nLibraries discussions:\r\n\r\nTake 1: http://www.haskell.org/pipermail/libraries/2013-November/021728.html\r\nTake 3: http://www.haskell.org/pipermail/libraries/2014-April/022864.html","type_of_failure":"OtherFailure","blocking":[]} -->7.10.1https://gitlab.haskell.org/ghc/ghc/-/issues/9016Add System.Exit.die2019-07-07T18:42:18ZSimonHengelAdd System.Exit.die(as per the proposal/discussion on haskell-libraries, I just posted a summary that "awaits moderator approval")
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 7.8.2 |
| Type | FeatureRequest |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | libraries/base |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | hvr |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Add System.Exit.die","status":"New","operating_system":"","component":"libraries/base","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.8.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["hvr"],"type":"FeatureRequest","description":"(as per the proposal/discussion on haskell-libraries, I just posted a summary that \"awaits moderator approval\")","type_of_failure":"OtherFailure","blocking":[]} -->(as per the proposal/discussion on haskell-libraries, I just posted a summary that "awaits moderator approval")
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 7.8.2 |
| Type | FeatureRequest |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | libraries/base |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | hvr |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Add System.Exit.die","status":"New","operating_system":"","component":"libraries/base","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.8.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["hvr"],"type":"FeatureRequest","description":"(as per the proposal/discussion on haskell-libraries, I just posted a summary that \"awaits moderator approval\")","type_of_failure":"OtherFailure","blocking":[]} -->7.10.1https://gitlab.haskell.org/ghc/ghc/-/issues/9008Data.Function: Add reverse application operator2019-07-07T18:42:20ZbernalexData.Function: Add reverse application operator<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 7.8.2 |
| Type | FeatureRequest |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | libraries/base |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | hvr |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Data.Function: Add reverse application operator","status":"New","operating_system":"","component":"libraries/base","related":[],"milestone":"7.10.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.8.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["hvr"],"type":"FeatureRequest","description":"","type_of_failure":"OtherFailure","blocking":[]} --><details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 7.8.2 |
| Type | FeatureRequest |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | libraries/base |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | hvr |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Data.Function: Add reverse application operator","status":"New","operating_system":"","component":"libraries/base","related":[],"milestone":"7.10.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.8.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["hvr"],"type":"FeatureRequest","description":"","type_of_failure":"OtherFailure","blocking":[]} -->7.10.1https://gitlab.haskell.org/ghc/ghc/-/issues/9004Add sortOn function to Data.List2019-07-07T18:42:21ZJohnWiegleyAdd sortOn function to Data.ListThe following passed for two weeks on the libraries mailing list without any dissenting votes.
The request is to add the following function to Data.List:
```
-- | Sort a list by comparing the results of a key function applied to each
-- element. @sortOn f@ is equivalent to @sortBy . comparing f@, but has the
-- performance advantage of only evaluating @f@ once for each element in the
-- input list. This is called the decorate-sort-undecorate paradigm, or
-- Schwartzian transform.
sortOn :: Ord b => (a -> b) -> [a] -> [a]
sortOn f = map snd . sortBy (comparing fst)
. map (\x -> let y = f x in y `seq` (y, x))
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 7.8.2 |
| Type | FeatureRequest |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | libraries/base |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | hvr |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Add sortOn function to Data.List","status":"New","operating_system":"","component":"libraries/base","related":[],"milestone":"7.10.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.8.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["hvr"],"type":"FeatureRequest","description":"The following passed for two weeks on the libraries mailing list without any dissenting votes.\r\n\r\nThe request is to add the following function to Data.List:\r\n\r\n{{{\r\n-- | Sort a list by comparing the results of a key function applied to each\r\n-- element. @sortOn f@ is equivalent to @sortBy . comparing f@, but has the\r\n-- performance advantage of only evaluating @f@ once for each element in the\r\n-- input list. This is called the decorate-sort-undecorate paradigm, or\r\n-- Schwartzian transform.\r\nsortOn :: Ord b => (a -> b) -> [a] -> [a]\r\nsortOn f = map snd . sortBy (comparing fst)\r\n . map (\\x -> let y = f x in y `seq` (y, x))\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->The following passed for two weeks on the libraries mailing list without any dissenting votes.
The request is to add the following function to Data.List:
```
-- | Sort a list by comparing the results of a key function applied to each
-- element. @sortOn f@ is equivalent to @sortBy . comparing f@, but has the
-- performance advantage of only evaluating @f@ once for each element in the
-- input list. This is called the decorate-sort-undecorate paradigm, or
-- Schwartzian transform.
sortOn :: Ord b => (a -> b) -> [a] -> [a]
sortOn f = map snd . sortBy (comparing fst)
. map (\x -> let y = f x in y `seq` (y, x))
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 7.8.2 |
| Type | FeatureRequest |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | libraries/base |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | hvr |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Add sortOn function to Data.List","status":"New","operating_system":"","component":"libraries/base","related":[],"milestone":"7.10.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.8.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["hvr"],"type":"FeatureRequest","description":"The following passed for two weeks on the libraries mailing list without any dissenting votes.\r\n\r\nThe request is to add the following function to Data.List:\r\n\r\n{{{\r\n-- | Sort a list by comparing the results of a key function applied to each\r\n-- element. @sortOn f@ is equivalent to @sortBy . comparing f@, but has the\r\n-- performance advantage of only evaluating @f@ once for each element in the\r\n-- input list. This is called the decorate-sort-undecorate paradigm, or\r\n-- Schwartzian transform.\r\nsortOn :: Ord b => (a -> b) -> [a] -> [a]\r\nsortOn f = map snd . sortBy (comparing fst)\r\n . map (\\x -> let y = f x in y `seq` (y, x))\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->7.10.1https://gitlab.haskell.org/ghc/ghc/-/issues/8302Add 'bool' to Data.Bool2019-07-07T18:45:39ZOllie CharlesAdd 'bool' to Data.BoolAs mentioned in http://www.haskell.org/pipermail/libraries/2013-September/020492.html I propose we add the 'bool' function to 'Data.Bool'.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 7.6.3 |
| 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":"Add 'bool' to Data.Bool","status":"New","operating_system":"","component":"libraries/base","related":[],"milestone":"7.8.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.6.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"FeatureRequest","description":"As mentioned in http://www.haskell.org/pipermail/libraries/2013-September/020492.html I propose we add the 'bool' function to 'Data.Bool'.","type_of_failure":"OtherFailure","blocking":[]} -->As mentioned in http://www.haskell.org/pipermail/libraries/2013-September/020492.html I propose we add the 'bool' function to 'Data.Bool'.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 7.6.3 |
| 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":"Add 'bool' to Data.Bool","status":"New","operating_system":"","component":"libraries/base","related":[],"milestone":"7.8.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.6.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"FeatureRequest","description":"As mentioned in http://www.haskell.org/pipermail/libraries/2013-September/020492.html I propose we add the 'bool' function to 'Data.Bool'.","type_of_failure":"OtherFailure","blocking":[]} -->7.8.1https://gitlab.haskell.org/ghc/ghc/-/issues/7817Moving basic functions2019-07-07T18:47:58ZquchenMoving basic functions**1.** Add the `infixl 4` operator `($>) = flip (<$)` to Data.Functor.
**2.** Move `Control.Monad.void` to `Data.Functor`, and re-export it from `Control.Monad` for compatibility. In addition, replace the deprecated `Foreign.Marshal.Error.void` with a re-export as well.
The mailing list discussion is here:
http://markmail.org/message/cqdlle4l6npxs3jn
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 7.6.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":"Moving basic functions","status":"New","operating_system":"","component":"libraries/base","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.6.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"FeatureRequest","description":"'''1.''' Add the `infixl 4` operator `($>) = flip (<$)` to Data.Functor.\r\n\r\n'''2.''' Move `Control.Monad.void` to `Data.Functor`, and re-export it from `Control.Monad` for compatibility. In addition, replace the deprecated `Foreign.Marshal.Error.void` with a re-export as well.\r\n\r\nThe mailing list discussion is here:\r\nhttp://markmail.org/message/cqdlle4l6npxs3jn","type_of_failure":"OtherFailure","blocking":[]} -->**1.** Add the `infixl 4` operator `($>) = flip (<$)` to Data.Functor.
**2.** Move `Control.Monad.void` to `Data.Functor`, and re-export it from `Control.Monad` for compatibility. In addition, replace the deprecated `Foreign.Marshal.Error.void` with a re-export as well.
The mailing list discussion is here:
http://markmail.org/message/cqdlle4l6npxs3jn
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 7.6.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":"Moving basic functions","status":"New","operating_system":"","component":"libraries/base","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.6.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"FeatureRequest","description":"'''1.''' Add the `infixl 4` operator `($>) = flip (<$)` to Data.Functor.\r\n\r\n'''2.''' Move `Control.Monad.void` to `Data.Functor`, and re-export it from `Control.Monad` for compatibility. In addition, replace the deprecated `Foreign.Marshal.Error.void` with a re-export as well.\r\n\r\nThe mailing list discussion is here:\r\nhttp://markmail.org/message/cqdlle4l6npxs3jn","type_of_failure":"OtherFailure","blocking":[]} -->7.8.1https://gitlab.haskell.org/ghc/ghc/-/issues/7530Proposal: Add isLeft/isRight to Data.Either2019-07-07T18:49:20ZSimonHengelProposal: Add isLeft/isRight to Data.EitherI propose to add `isLeft`/`isRight` to `Data.Either`. The corresponding thread on `haskell-liraries` is here: http://www.haskell.org/pipermail/libraries/2012-November/018976.html
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.6.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Proposal: Add isLeft/isRight to Data.Either","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.6.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"I propose to add {{{isLeft}}}/{{{isRight}}} to {{{Data.Either}}}. The corresponding thread on {{{haskell-liraries}}} is here: http://www.haskell.org/pipermail/libraries/2012-November/018976.html","type_of_failure":"OtherFailure","blocking":[]} -->I propose to add `isLeft`/`isRight` to `Data.Either`. The corresponding thread on `haskell-liraries` is here: http://www.haskell.org/pipermail/libraries/2012-November/018976.html
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.6.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Proposal: Add isLeft/isRight to Data.Either","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.6.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"I propose to add {{{isLeft}}}/{{{isRight}}} to {{{Data.Either}}}. The corresponding thread on {{{haskell-liraries}}} is here: http://www.haskell.org/pipermail/libraries/2012-November/018976.html","type_of_failure":"OtherFailure","blocking":[]} -->7.8.1https://gitlab.haskell.org/ghc/ghc/-/issues/7425Add method to Data.Bits for creating zeroed values.2019-07-07T18:49:47ZAninhumerAdd method to Data.Bits for creating zeroed values.The removal of the Num superclass from Data.Bits now means there is no simple way to create a value in which all bits are set to zero. There are obviously a variety of ways such a value can be constructed with the existing methods, but nonetheless it seems like an odd omission.
The new method could be given an implementation in terms of the existing ones for backwards compatibility.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 7.6.1 |
| Type | FeatureRequest |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | libraries/base |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Add method to Data.Bits for creating zeroed values.","status":"New","operating_system":"","component":"libraries/base","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.6.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"FeatureRequest","description":"The removal of the Num superclass from Data.Bits now means there is no simple way to create a value in which all bits are set to zero. There are obviously a variety of ways such a value can be constructed with the existing methods, but nonetheless it seems like an odd omission.\r\n\r\nThe new method could be given an implementation in terms of the existing ones for backwards compatibility.","type_of_failure":"OtherFailure","blocking":[]} -->The removal of the Num superclass from Data.Bits now means there is no simple way to create a value in which all bits are set to zero. There are obviously a variety of ways such a value can be constructed with the existing methods, but nonetheless it seems like an odd omission.
The new method could be given an implementation in terms of the existing ones for backwards compatibility.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 7.6.1 |
| Type | FeatureRequest |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | libraries/base |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Add method to Data.Bits for creating zeroed values.","status":"New","operating_system":"","component":"libraries/base","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.6.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"FeatureRequest","description":"The removal of the Num superclass from Data.Bits now means there is no simple way to create a value in which all bits are set to zero. There are obviously a variety of ways such a value can be constructed with the existing methods, but nonetheless it seems like an odd omission.\r\n\r\nThe new method could be given an implementation in terms of the existing ones for backwards compatibility.","type_of_failure":"OtherFailure","blocking":[]} -->7.8.1https://gitlab.haskell.org/ghc/ghc/-/issues/7424Add Data.Bits instance for Bool2019-07-07T18:49:48ZAninhumerAdd Data.Bits instance for BoolGiven the common use cases for Data.Bits, it seems strange that there is no instance for Bool. Previously, the Num superclass was a reason not to include one, as there are valid objections to a Num Bool instance. However, this superclass requirement has now been removed, so I think adding a Bits Bool instance would be a good idea.
I have attached a local implementation which I am using, but it may not entirely match the intended semantics of Bits.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 7.6.1 |
| Type | FeatureRequest |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | libraries/base |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Add Data.Bits instance for Bool","status":"New","operating_system":"","component":"libraries/base","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.6.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"FeatureRequest","description":"Given the common use cases for Data.Bits, it seems strange that there is no instance for Bool. Previously, the Num superclass was a reason not to include one, as there are valid objections to a Num Bool instance. However, this superclass requirement has now been removed, so I think adding a Bits Bool instance would be a good idea.\r\n\r\nI have attached a local implementation which I am using, but it may not entirely match the intended semantics of Bits.","type_of_failure":"OtherFailure","blocking":[]} -->Given the common use cases for Data.Bits, it seems strange that there is no instance for Bool. Previously, the Num superclass was a reason not to include one, as there are valid objections to a Num Bool instance. However, this superclass requirement has now been removed, so I think adding a Bits Bool instance would be a good idea.
I have attached a local implementation which I am using, but it may not entirely match the intended semantics of Bits.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 7.6.1 |
| Type | FeatureRequest |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | libraries/base |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Add Data.Bits instance for Bool","status":"New","operating_system":"","component":"libraries/base","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.6.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"FeatureRequest","description":"Given the common use cases for Data.Bits, it seems strange that there is no instance for Bool. Previously, the Num superclass was a reason not to include one, as there are valid objections to a Num Bool instance. However, this superclass requirement has now been removed, so I think adding a Bits Bool instance would be a good idea.\r\n\r\nI have attached a local implementation which I am using, but it may not entirely match the intended semantics of Bits.","type_of_failure":"OtherFailure","blocking":[]} -->7.8.1https://gitlab.haskell.org/ghc/ghc/-/issues/7077Add an order-reversing newtype to Data.Ord2019-07-07T18:51:30ZAzelAdd an order-reversing newtype to Data.OrdThis is proposal to add an order-reversing newtype to Data.Ord by adding GHC.Exts's one, Down.
You'll find attached a patch implementing this re-export and the conversation thread may be found [here](http://haskell.1045720.n5.nabble.com/Proposal-add-an-order-reversing-newtype-to-Data-Ord-td5714005.html).
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | |
| 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":"Add an order-reversing newtype to Data.Ord","status":"New","operating_system":"","component":"libraries/base","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"","keywords":["ord"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"FeatureRequest","description":"This is proposal to add an order-reversing newtype to Data.Ord by adding GHC.Exts's one, Down.\r\n\r\nYou'll find attached a patch implementing this re-export and the conversation thread may be found [http://haskell.1045720.n5.nabble.com/Proposal-add-an-order-reversing-newtype-to-Data-Ord-td5714005.html here].","type_of_failure":"OtherFailure","blocking":[]} -->This is proposal to add an order-reversing newtype to Data.Ord by adding GHC.Exts's one, Down.
You'll find attached a patch implementing this re-export and the conversation thread may be found [here](http://haskell.1045720.n5.nabble.com/Proposal-add-an-order-reversing-newtype-to-Data-Ord-td5714005.html).
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | |
| 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":"Add an order-reversing newtype to Data.Ord","status":"New","operating_system":"","component":"libraries/base","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"","keywords":["ord"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"FeatureRequest","description":"This is proposal to add an order-reversing newtype to Data.Ord by adding GHC.Exts's one, Down.\r\n\r\nYou'll find attached a patch implementing this re-export and the conversation thread may be found [http://haskell.1045720.n5.nabble.com/Proposal-add-an-order-reversing-newtype-to-Data-Ord-td5714005.html here].","type_of_failure":"OtherFailure","blocking":[]} -->7.6.1pcapriottipcapriotti