GHC issueshttps://gitlab.haskell.org/ghc/ghc/-/issues2019-07-07T19:15:15Zhttps://gitlab.haskell.org/ghc/ghc/-/issues/1103Japanese Unicode2019-07-07T19:15:15ZhumasectJapanese UnicodeUsing Japanese characters (either katakana or hiragana) in identifiers rules this:
Source/Hehe.hs:12:0: lexical error at character '\\12390'
There is no issue with Haskell98 for upper/lower case identifiers and type constructor identification with the two complimenting Japanese character sets. Using -fglasgow-exts along with other Unicode characters for various operators which work great.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------- |
| Version | 6.6 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler (Parser) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | MacOS X |
| Architecture | Unknown |
</details>
<!-- {"blocked_by":[],"summary":"Japanese Unicode","status":"New","operating_system":"MacOS X","component":"Compiler (Parser)","related":[],"milestone":"6.6.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.6","keywords":["-fglasgow-exts","japanese","lexical","unicode"],"differentials":[],"test_case":"","architecture":"Unknown","cc":[""],"type":"Bug","description":"Using Japanese characters (either katakana or hiragana) in identifiers rules this:\r\n\r\nSource/Hehe.hs:12:0: lexical error at character '\\12390'\r\n\r\nThere is no issue with Haskell98 for upper/lower case identifiers and type constructor identification with the two complimenting Japanese character sets. Using -fglasgow-exts along with other Unicode characters for various operators which work great.","type_of_failure":"OtherFailure","blocking":[]} -->Using Japanese characters (either katakana or hiragana) in identifiers rules this:
Source/Hehe.hs:12:0: lexical error at character '\\12390'
There is no issue with Haskell98 for upper/lower case identifiers and type constructor identification with the two complimenting Japanese character sets. Using -fglasgow-exts along with other Unicode characters for various operators which work great.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------- |
| Version | 6.6 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler (Parser) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | MacOS X |
| Architecture | Unknown |
</details>
<!-- {"blocked_by":[],"summary":"Japanese Unicode","status":"New","operating_system":"MacOS X","component":"Compiler (Parser)","related":[],"milestone":"6.6.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.6","keywords":["-fglasgow-exts","japanese","lexical","unicode"],"differentials":[],"test_case":"","architecture":"Unknown","cc":[""],"type":"Bug","description":"Using Japanese characters (either katakana or hiragana) in identifiers rules this:\r\n\r\nSource/Hehe.hs:12:0: lexical error at character '\\12390'\r\n\r\nThere is no issue with Haskell98 for upper/lower case identifiers and type constructor identification with the two complimenting Japanese character sets. Using -fglasgow-exts along with other Unicode characters for various operators which work great.","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/11609Document unicode report deviations2019-07-07T18:29:37ZthomieDocument unicode report deviations\@nomeata mentions in #10196:
The report specifies “Haskell compilers are expected to make use of new versions of Unicode as they are made available.” So if we deviate from that, we should make sure that
- the user’s guide explicitly lists all deviations from the report [in this section](https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/bugs-and-infelicities.html#infelicities-lexical), and
- that the Haskell prime committee is going to be aware of these (sensible) deviations, so that they can become official.
Certain deviations are (there might be more):
- `OtherLetter` are treated as lowercase (#1103), and thus allowed in identifiers.
- `ModifierLetter` (#10196), `OtherNumber` (#4373) and `NonSpacingMark` (#7650) are allowed in identifiers, but only starting from the second character.
- `$decdigit = $ascdigit -- for now, should really be $digit (ToDo)` (see compiler/parser/Lexer.x)\@nomeata mentions in #10196:
The report specifies “Haskell compilers are expected to make use of new versions of Unicode as they are made available.” So if we deviate from that, we should make sure that
- the user’s guide explicitly lists all deviations from the report [in this section](https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/bugs-and-infelicities.html#infelicities-lexical), and
- that the Haskell prime committee is going to be aware of these (sensible) deviations, so that they can become official.
Certain deviations are (there might be more):
- `OtherLetter` are treated as lowercase (#1103), and thus allowed in identifiers.
- `ModifierLetter` (#10196), `OtherNumber` (#4373) and `NonSpacingMark` (#7650) are allowed in identifiers, but only starting from the second character.
- `$decdigit = $ascdigit -- for now, should really be $digit (ToDo)` (see compiler/parser/Lexer.x)https://gitlab.haskell.org/ghc/ghc/-/issues/10755Add `MonadPlus IO` and `Alternative IO` instances2019-07-07T18:34:09ZHerbert Valerio Riedelhvr@gnu.orgAdd `MonadPlus IO` and `Alternative IO` instancesCloned and adapted from #9588:
----
The following 2 instances are currently Orphans in `transformers` but shall be defined in `base` instead:
```hs
instance MonadPlus IO
instance Alternative IO
```
This proposal by SPJ already passed the CLC back in April and only needs implementing. I'll submit a patch shortly to Phab
----
This needs coordination w/ Ross as `transformers` must not define the same instances for new enough `base` versions.
<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 | core-libraries-committee@haskell.org, ekmett, hvr, simonpj |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Add `MonadPlus IO` and `Alternative IO` instances","status":"New","operating_system":"","component":"Core Libraries","related":[],"milestone":"7.12.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"","keywords":["report-impact"],"differentials":[],"test_case":"","architecture":"","cc":["core-libraries-committee@haskell.org","ekmett","hvr","simonpj"],"type":"Task","description":"Cloned and adapted from #9588:\r\n----\r\nThe following 2 instances are currently Orphans in `transformers` but shall be defined in `base` instead:\r\n\r\n{{{#!hs\r\ninstance MonadPlus IO\r\ninstance Alternative IO\r\n}}}\r\n\r\nThis proposal by SPJ already passed the CLC back in April and only needs implementing. I'll submit a patch shortly to Phab\r\n\r\n----\r\n\r\nThis needs coordination w/ Ross as `transformers` must not define the same instances for new enough `base` versions.","type_of_failure":"OtherFailure","blocking":[]} -->Cloned and adapted from #9588:
----
The following 2 instances are currently Orphans in `transformers` but shall be defined in `base` instead:
```hs
instance MonadPlus IO
instance Alternative IO
```
This proposal by SPJ already passed the CLC back in April and only needs implementing. I'll submit a patch shortly to Phab
----
This needs coordination w/ Ross as `transformers` must not define the same instances for new enough `base` versions.
<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 | core-libraries-committee@haskell.org, ekmett, hvr, simonpj |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Add `MonadPlus IO` and `Alternative IO` instances","status":"New","operating_system":"","component":"Core Libraries","related":[],"milestone":"7.12.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"","keywords":["report-impact"],"differentials":[],"test_case":"","architecture":"","cc":["core-libraries-committee@haskell.org","ekmett","hvr","simonpj"],"type":"Task","description":"Cloned and adapted from #9588:\r\n----\r\nThe following 2 instances are currently Orphans in `transformers` but shall be defined in `base` instead:\r\n\r\n{{{#!hs\r\ninstance MonadPlus IO\r\ninstance Alternative IO\r\n}}}\r\n\r\nThis proposal by SPJ already passed the CLC back in April and only needs implementing. I'll submit a patch shortly to Phab\r\n\r\n----\r\n\r\nThis needs coordination w/ Ross as `transformers` must not define the same instances for new enough `base` versions.","type_of_failure":"OtherFailure","blocking":[]} -->8.0.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/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/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/5593Proposal: Remove Num superclass of Bits2019-07-07T18:54:35ZbasvandijkProposal: Remove Num superclass of BitsThis ticket summarizes the [discussion](http://www.haskell.org/pipermail/libraries/2011-October/016899.html) on the proposal to remove the `Num` superclass of the `Bits` type class.
The proposal is to:
- Remove the `Num` superclass of the `Bits` type class.
- Remove the default implementations of `bit`, `testBit` and `popCount` since they use methods of `Num`.
- Export the following convenience functions from `Data.Bits`:
```
bitDefault :: (Bits a, Num a) => Int -> a
bitDefault i = 1 `shiftL` i
testBitDefault :: (Bits a, Num a) => a -> Int -> Bool
testBitDefault x i = (x .&. bit i) /= 0
popCountDefault :: (Bits a, Num a) => a -> Int
popCountDefault = go 0
where
go !c 0 = c
go c w = go (c+1) (w .&. w - 1) -- clear the least significant
```
Attached are tickets for `base` and `ghc`.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 7.2.1 |
| Type | Task |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | libraries/base |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Proposal: Remove Num superclass of Bits","status":"New","operating_system":"","component":"libraries/base","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.2.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Task","description":"This ticket summarizes the [http://www.haskell.org/pipermail/libraries/2011-October/016899.html discussion] on the proposal to remove the `Num` superclass of the `Bits` type class.\r\n\r\nThe proposal is to:\r\n\r\n * Remove the `Num` superclass of the `Bits` type class.\r\n\r\n * Remove the default implementations of `bit`, `testBit` and `popCount` since they use methods of `Num`.\r\n\r\n * Export the following convenience functions from `Data.Bits`:\r\n\r\n{{{\r\nbitDefault :: (Bits a, Num a) => Int -> a\r\nbitDefault i = 1 `shiftL` i\r\n\r\ntestBitDefault :: (Bits a, Num a) => a -> Int -> Bool\r\ntestBitDefault x i = (x .&. bit i) /= 0\r\n\r\npopCountDefault :: (Bits a, Num a) => a -> Int\r\npopCountDefault = go 0\r\n where\r\n go !c 0 = c\r\n go c w = go (c+1) (w .&. w - 1) -- clear the least significant\r\n}}}\r\n\r\nAttached are tickets for `base` and `ghc`.","type_of_failure":"OtherFailure","blocking":[]} -->This ticket summarizes the [discussion](http://www.haskell.org/pipermail/libraries/2011-October/016899.html) on the proposal to remove the `Num` superclass of the `Bits` type class.
The proposal is to:
- Remove the `Num` superclass of the `Bits` type class.
- Remove the default implementations of `bit`, `testBit` and `popCount` since they use methods of `Num`.
- Export the following convenience functions from `Data.Bits`:
```
bitDefault :: (Bits a, Num a) => Int -> a
bitDefault i = 1 `shiftL` i
testBitDefault :: (Bits a, Num a) => a -> Int -> Bool
testBitDefault x i = (x .&. bit i) /= 0
popCountDefault :: (Bits a, Num a) => a -> Int
popCountDefault = go 0
where
go !c 0 = c
go c w = go (c+1) (w .&. w - 1) -- clear the least significant
```
Attached are tickets for `base` and `ghc`.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 7.2.1 |
| Type | Task |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | libraries/base |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Proposal: Remove Num superclass of Bits","status":"New","operating_system":"","component":"libraries/base","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.2.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Task","description":"This ticket summarizes the [http://www.haskell.org/pipermail/libraries/2011-October/016899.html discussion] on the proposal to remove the `Num` superclass of the `Bits` type class.\r\n\r\nThe proposal is to:\r\n\r\n * Remove the `Num` superclass of the `Bits` type class.\r\n\r\n * Remove the default implementations of `bit`, `testBit` and `popCount` since they use methods of `Num`.\r\n\r\n * Export the following convenience functions from `Data.Bits`:\r\n\r\n{{{\r\nbitDefault :: (Bits a, Num a) => Int -> a\r\nbitDefault i = 1 `shiftL` i\r\n\r\ntestBitDefault :: (Bits a, Num a) => a -> Int -> Bool\r\ntestBitDefault x i = (x .&. bit i) /= 0\r\n\r\npopCountDefault :: (Bits a, Num a) => a -> Int\r\npopCountDefault = go 0\r\n where\r\n go !c 0 = c\r\n go c w = go (c+1) (w .&. w - 1) -- clear the least significant\r\n}}}\r\n\r\nAttached are tickets for `base` and `ghc`.","type_of_failure":"OtherFailure","blocking":[]} -->7.6.1https://gitlab.haskell.org/ghc/ghc/-/issues/17894Parsing of values and functions is not consistent2020-03-15T16:31:26ZDaniel TaskoffParsing of values and functions is not consistent## Motivation
It's very strange to me, that in the following snippet `f` gets parsed as a single `FunBind`, while `y` gets parsed as two `FunBind`s (and fails to compile afterwards).
```hs
f x | True = 42
f x = 0
y | True = 42
y = 0
```
I think this is useful in `let` blocks.
## Proposal
Parse such values and functions in the same way.## Motivation
It's very strange to me, that in the following snippet `f` gets parsed as a single `FunBind`, while `y` gets parsed as two `FunBind`s (and fails to compile afterwards).
```hs
f x | True = 42
f x = 0
y | True = 42
y = 0
```
I think this is useful in `let` blocks.
## Proposal
Parse such values and functions in the same way.https://gitlab.haskell.org/ghc/ghc/-/issues/11012Support for unicode primes on identifiers.2019-07-07T18:32:40ZghartshawSupport for unicode primes on identifiers.GHC should allow the (single/double/triple/quadruple) prime characters in Unicode to be allowed in identifiers. This would make them consistent with the ASCII apostrophe, which is usually used in place of a single prime. The current workaround for primes (using one or more apostrophes) is unwieldy for higher primes (e.g. `a'''` and `a''''`).
All of the following identifiers should be valid.
```
a' // U+0027 APOSTROPHE
a′ // U+2032 PRIME
a″ // U+2033 DOUBLE PRIME
a‴ // U+2034 TRIPLE PRIME
a⁗ // U+2057 QUADRUPLE PRIME
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------- |
| Version | 7.10.2 |
| Type | FeatureRequest |
| TypeOfFailure | OtherFailure |
| Priority | low |
| Resolution | Unresolved |
| Component | Compiler (Parser) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Support for unicode primes on identifiers.","status":"New","operating_system":"","component":"Compiler (Parser)","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.10.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"FeatureRequest","description":"GHC should allow the (single/double/triple/quadruple) prime characters in Unicode to be allowed in identifiers. This would make them consistent with the ASCII apostrophe, which is usually used in place of a single prime. The current workaround for primes (using one or more apostrophes) is unwieldy for higher primes (e.g. {{{a'''}}} and {{{a''''}}}).\r\n\r\nAll of the following identifiers should be valid.\r\n{{{\r\na' // U+0027 APOSTROPHE\r\na′ // U+2032 PRIME\r\na″ // U+2033 DOUBLE PRIME\r\na‴ // U+2034 TRIPLE PRIME\r\na⁗ // U+2057 QUADRUPLE PRIME\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->GHC should allow the (single/double/triple/quadruple) prime characters in Unicode to be allowed in identifiers. This would make them consistent with the ASCII apostrophe, which is usually used in place of a single prime. The current workaround for primes (using one or more apostrophes) is unwieldy for higher primes (e.g. `a'''` and `a''''`).
All of the following identifiers should be valid.
```
a' // U+0027 APOSTROPHE
a′ // U+2032 PRIME
a″ // U+2033 DOUBLE PRIME
a‴ // U+2034 TRIPLE PRIME
a⁗ // U+2057 QUADRUPLE PRIME
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------- |
| Version | 7.10.2 |
| Type | FeatureRequest |
| TypeOfFailure | OtherFailure |
| Priority | low |
| Resolution | Unresolved |
| Component | Compiler (Parser) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Support for unicode primes on identifiers.","status":"New","operating_system":"","component":"Compiler (Parser)","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.10.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"FeatureRequest","description":"GHC should allow the (single/double/triple/quadruple) prime characters in Unicode to be allowed in identifiers. This would make them consistent with the ASCII apostrophe, which is usually used in place of a single prime. The current workaround for primes (using one or more apostrophes) is unwieldy for higher primes (e.g. {{{a'''}}} and {{{a''''}}}).\r\n\r\nAll of the following identifiers should be valid.\r\n{{{\r\na' // U+0027 APOSTROPHE\r\na′ // U+2032 PRIME\r\na″ // U+2033 DOUBLE PRIME\r\na‴ // U+2034 TRIPLE PRIME\r\na⁗ // U+2057 QUADRUPLE PRIME\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/10365Implement Semigroup as a superclass of Monoid Proposal (Phase 1)2019-07-07T18:36:23ZgidynImplement Semigroup as a superclass of Monoid Proposal (Phase 1)More details in prime:Libraries/Proposals/SemigroupMonoid
### Phase 1 (GHC 7.12)
Phase 1 consists in (at the very least) moving `Data.Semigroup` and `Data.List.NonEmpty` into `base` for GHC 7.12 (aka 8.0).
If there's enough time we will also implement a warning as part of the first phase:
> Add a warning about definitions of an operator named `(<>)` that indicate it will be coming into Prelude in 7.14. We should warn about missing Semigroup instances at any use site of `(<>)` as they'll break in 7.14.More details in prime:Libraries/Proposals/SemigroupMonoid
### Phase 1 (GHC 7.12)
Phase 1 consists in (at the very least) moving `Data.Semigroup` and `Data.List.NonEmpty` into `base` for GHC 7.12 (aka 8.0).
If there's enough time we will also implement a warning as part of the first phase:
> Add a warning about definitions of an operator named `(<>)` that indicate it will be coming into Prelude in 7.14. We should warn about missing Semigroup instances at any use site of `(<>)` as they'll break in 7.14.8.0.1quchenquchenhttps://gitlab.haskell.org/ghc/ghc/-/issues/10364Feature request: Add support for FMA2019-07-07T18:36:23ZLevent ErkökFeature request: Add support for FMAFMA (fused-multiply-add) has been around for quite some-time, and is natively supported by many of the newer processors. It's an operation that is heavily used in HPC applications. I think it's time for Haskell to have native support for it as well.
Ideally, it should be added to the `Num` class as a method. Assuming that is a possibility, we would have the following signature and default definition:
```hs
class Num a where
...
fma :: a -> a -> a -> a
fma x y z = x * y + z
```
Except of course the `Float` and `Double` instances would ensure that the rounding is done only once.
If adding it to the `Num` class is not an option, then `RealFloat` class would be the next best place; and perhaps that's arguably also a better place because those types are the ones one usually has in mind when using FMA.
I think either `Num` or `RealFloat` would be fine choices.
Implementation:
- If the underlying architecture supports it (which is very common), directly emit FMA instruction
- Otherwise, FFI out to C and use `fma` and `fmaf` from the math library
A direct software implementation might also be possible for platforms where neither choice above is an option, but that bridge can be crossed when we get there.
As a final note; while supporting these functions might seem going-out-of-our-way; it is indeed a big selling point in HPC applications. Furthermore, hardware manufacturers are putting big resources to make these supported natively in the instruction sets. Supporting FMA right out of the box would be a very good step in wider adaptation of Haskell in the HPC community.FMA (fused-multiply-add) has been around for quite some-time, and is natively supported by many of the newer processors. It's an operation that is heavily used in HPC applications. I think it's time for Haskell to have native support for it as well.
Ideally, it should be added to the `Num` class as a method. Assuming that is a possibility, we would have the following signature and default definition:
```hs
class Num a where
...
fma :: a -> a -> a -> a
fma x y z = x * y + z
```
Except of course the `Float` and `Double` instances would ensure that the rounding is done only once.
If adding it to the `Num` class is not an option, then `RealFloat` class would be the next best place; and perhaps that's arguably also a better place because those types are the ones one usually has in mind when using FMA.
I think either `Num` or `RealFloat` would be fine choices.
Implementation:
- If the underlying architecture supports it (which is very common), directly emit FMA instruction
- Otherwise, FFI out to C and use `fma` and `fmaf` from the math library
A direct software implementation might also be possible for platforms where neither choice above is an option, but that bridge can be crossed when we get there.
As a final note; while supporting these functions might seem going-out-of-our-way; it is indeed a big selling point in HPC applications. Furthermore, hardware manufacturers are putting big resources to make these supported natively in the instruction sets. Supporting FMA right out of the box would be a very good step in wider adaptation of Haskell in the HPC community.Edward KmettEdward Kmetthttps://gitlab.haskell.org/ghc/ghc/-/issues/10039Make Const (Control.Applicative) kind polymorphic in its second argument2019-07-07T18:37:50ZIcelandjackMake Const (Control.Applicative) kind polymorphic in its second argumentIs there any reason why `Const` isn't kind polymorphic?
```hs
newtype Const a (b :: k) = Const { getConst :: a }
deriving (Generic, Generic1)
```
An example where I need it is for [interpreting typed PHOAS](http://wiki.ocharles.org.uk/Name%20Binding%20in%20EDSLs), the following fails to compile complaining that `The first argument of ‘PTerm’ should have kind ‘Ty -> *’, but ‘Const Char’ has kind ‘* -> *’`:
```hs
{-# LANGUAGE DataKinds, KindSignatures, GADTs, RankNTypes, PolyKinds #-}
import Control.Applicative
data Ty = TyBool | TyArr Ty Ty
data PTerm :: (Ty -> *) -> Ty -> * where
Var :: v t -> PTerm v t
Tru :: PTerm v 'TyBool
Fals :: PTerm v 'TyBool
App :: PTerm v ('TyArr t1 t2) -> PTerm v t1 -> PTerm v t2
Abs :: (v t1 -> PTerm v t2) -> PTerm v ('TyArr t1 t2)
newtype Term t = Term (forall v. PTerm v t)
showT :: Term t -> String
showT (Term pterm) = show' 'a' pterm
where
show' :: Char -> PTerm (Const Char) t -> String
show' _ (Var (Const c)) = [c]
show' _ Tru = "True"
show' _ Fals = "False"
show' s (App x y) = "(" ++ show' s x ++ ") " ++ show' s y
show' s (Abs f) = [s] ++ ". " ++ show' (succ s) (f (Const s))
```
but it compiles if one defines a bespoke form of `Const` with kind `* -> Ty -> *` (or the more general suggestion at the beginning of the ticket), I implemented all the related instances from `Control.Applicative` and it compiled without a hitch. Relevant discussion: a [question on StackOverflow](http://stackoverflow.com/questions/2023052/haskell-specifying-kind-in-data-declaration) that predates the `PolyKinds` extension effectively wants to define `type Const' (a :: * -> *) = Const Integer a` which would be possible if it were kind polymorphic.Is there any reason why `Const` isn't kind polymorphic?
```hs
newtype Const a (b :: k) = Const { getConst :: a }
deriving (Generic, Generic1)
```
An example where I need it is for [interpreting typed PHOAS](http://wiki.ocharles.org.uk/Name%20Binding%20in%20EDSLs), the following fails to compile complaining that `The first argument of ‘PTerm’ should have kind ‘Ty -> *’, but ‘Const Char’ has kind ‘* -> *’`:
```hs
{-# LANGUAGE DataKinds, KindSignatures, GADTs, RankNTypes, PolyKinds #-}
import Control.Applicative
data Ty = TyBool | TyArr Ty Ty
data PTerm :: (Ty -> *) -> Ty -> * where
Var :: v t -> PTerm v t
Tru :: PTerm v 'TyBool
Fals :: PTerm v 'TyBool
App :: PTerm v ('TyArr t1 t2) -> PTerm v t1 -> PTerm v t2
Abs :: (v t1 -> PTerm v t2) -> PTerm v ('TyArr t1 t2)
newtype Term t = Term (forall v. PTerm v t)
showT :: Term t -> String
showT (Term pterm) = show' 'a' pterm
where
show' :: Char -> PTerm (Const Char) t -> String
show' _ (Var (Const c)) = [c]
show' _ Tru = "True"
show' _ Fals = "False"
show' s (App x y) = "(" ++ show' s x ++ ") " ++ show' s y
show' s (Abs f) = [s] ++ ". " ++ show' (succ s) (f (Const s))
```
but it compiles if one defines a bespoke form of `Const` with kind `* -> Ty -> *` (or the more general suggestion at the beginning of the ticket), I implemented all the related instances from `Control.Applicative` and it compiled without a hitch. Relevant discussion: a [question on StackOverflow](http://stackoverflow.com/questions/2023052/haskell-specifying-kind-in-data-declaration) that predates the `PolyKinds` extension effectively wants to define `type Const' (a :: * -> *) = Const Integer a` which would be possible if it were kind polymorphic.8.0.1Edward KmettEdward Kmetthttps://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 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.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/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/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.1