GHC issueshttps://gitlab.haskell.org/ghc/ghc/-/issues2019-07-07T18:42:20Zhttps://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/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/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/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/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/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/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/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/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/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/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/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/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/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/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/10092lex doesn't handle binary literals2019-07-07T18:37:35ZRyan Scottlex doesn't handle binary literalsThe `lex` function from `Text.Read.Lex` (on which the `Read` instance for `Lexeme` is based) can't read binary literals on GHC 7.10.1-rc2:
```
$ ghci -XBinaryLiterals
GHCi, version 7.10.0.20150123: http://www.haskell.org/ghc/ :? for help
λ> 0b101010
42
λ> import Text.Read.Lex
λ> read "0b101010" :: Lexeme
*** Exception: Prelude.read: no parse
```
This should be a simple fix, but I'm not sure if this is the intended behavior or not, since `BinaryLiterals` isn't a part of the Haskell 2010 standard (and I'm not sure how closely `lex` adheres to that).
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 7.10.1-rc2 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | libraries/base |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | ekmett, hvr |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"lex doesn't handle binary literals","status":"New","operating_system":"","component":"libraries/base","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.10.1-rc2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["ekmett","hvr"],"type":"Bug","description":"The {{{lex}}} function from {{{Text.Read.Lex}}} (on which the {{{Read}}} instance for {{{Lexeme}}} is based) can't read binary literals on GHC 7.10.1-rc2:\r\n\r\n{{{\r\n$ ghci -XBinaryLiterals\r\nGHCi, version 7.10.0.20150123: http://www.haskell.org/ghc/ :? for help\r\nλ> 0b101010\r\n42\r\nλ> import Text.Read.Lex\r\nλ> read \"0b101010\" :: Lexeme\r\n*** Exception: Prelude.read: no parse\r\n}}}\r\n\r\nThis should be a simple fix, but I'm not sure if this is the intended behavior or not, since {{{BinaryLiterals}}} isn't a part of the Haskell 2010 standard (and I'm not sure how closely {{{lex}}} adheres to that).","type_of_failure":"OtherFailure","blocking":[]} -->The `lex` function from `Text.Read.Lex` (on which the `Read` instance for `Lexeme` is based) can't read binary literals on GHC 7.10.1-rc2:
```
$ ghci -XBinaryLiterals
GHCi, version 7.10.0.20150123: http://www.haskell.org/ghc/ :? for help
λ> 0b101010
42
λ> import Text.Read.Lex
λ> read "0b101010" :: Lexeme
*** Exception: Prelude.read: no parse
```
This should be a simple fix, but I'm not sure if this is the intended behavior or not, since `BinaryLiterals` isn't a part of the Haskell 2010 standard (and I'm not sure how closely `lex` adheres to that).
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 7.10.1-rc2 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | libraries/base |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | ekmett, hvr |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"lex doesn't handle binary literals","status":"New","operating_system":"","component":"libraries/base","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.10.1-rc2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["ekmett","hvr"],"type":"Bug","description":"The {{{lex}}} function from {{{Text.Read.Lex}}} (on which the {{{Read}}} instance for {{{Lexeme}}} is based) can't read binary literals on GHC 7.10.1-rc2:\r\n\r\n{{{\r\n$ ghci -XBinaryLiterals\r\nGHCi, version 7.10.0.20150123: http://www.haskell.org/ghc/ :? for help\r\nλ> 0b101010\r\n42\r\nλ> import Text.Read.Lex\r\nλ> read \"0b101010\" :: Lexeme\r\n*** Exception: Prelude.read: no parse\r\n}}}\r\n\r\nThis should be a simple fix, but I'm not sure if this is the intended behavior or not, since {{{BinaryLiterals}}} isn't a part of the Haskell 2010 standard (and I'm not sure how closely {{{lex}}} adheres to that).","type_of_failure":"OtherFailure","blocking":[]} -->Edward KmettEdward Kmetthttps://gitlab.haskell.org/ghc/ghc/-/issues/10113Re-export (<$>) and (<$) from Prelude2019-07-07T18:37:27ZHerbert Valerio Riedelhvr@gnu.orgRe-export (<$>) and (<$) from PreludeSee http://thread.gmane.org/gmane.comp.lang.haskell.libraries/24161 for details
decision is still outstanding, but this needs to go into RC3 unless there's good reasons not to
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------------------- |
| Version | 7.10.1-rc2 |
| Type | FeatureRequest |
| TypeOfFailure | OtherFailure |
| Priority | highest |
| Resolution | Unresolved |
| Component | libraries/base |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | ekmett, hvr, thoughtpolice |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Re-export (<$>) from Prelude","status":"New","operating_system":"","component":"libraries/base","related":[],"milestone":"7.10.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.10.1-rc2","keywords":["AMP"],"differentials":[],"test_case":"","architecture":"","cc":["ekmett","hvr","thoughtpolice"],"type":"FeatureRequest","description":"See http://thread.gmane.org/gmane.comp.lang.haskell.libraries/24161 for details\r\n\r\ndecision is still outstanding, but this needs to go into RC3 unless there's good reasons not to","type_of_failure":"OtherFailure","blocking":[]} -->See http://thread.gmane.org/gmane.comp.lang.haskell.libraries/24161 for details
decision is still outstanding, but this needs to go into RC3 unless there's good reasons not to
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------------------- |
| Version | 7.10.1-rc2 |
| Type | FeatureRequest |
| TypeOfFailure | OtherFailure |
| Priority | highest |
| Resolution | Unresolved |
| Component | libraries/base |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | ekmett, hvr, thoughtpolice |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Re-export (<$>) from Prelude","status":"New","operating_system":"","component":"libraries/base","related":[],"milestone":"7.10.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.10.1-rc2","keywords":["AMP"],"differentials":[],"test_case":"","architecture":"","cc":["ekmett","hvr","thoughtpolice"],"type":"FeatureRequest","description":"See http://thread.gmane.org/gmane.comp.lang.haskell.libraries/24161 for details\r\n\r\ndecision is still outstanding, but this needs to go into RC3 unless there's good reasons not to","type_of_failure":"OtherFailure","blocking":[]} -->7.10.1https://gitlab.haskell.org/ghc/ghc/-/issues/10190Add a Monad instance for ((,) w)2019-07-07T18:37:10ZFumiaki KinoshitaAdd a Monad instance for ((,) w)Now Monoid is defined in GHC.Base; We can define a reasonable Monad instance for `(,) w`, as a writer monad.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 7.8.4 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | libraries/base |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | ekmett, hvr |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Add a Monad instance for ((,) w)","status":"New","operating_system":"","component":"libraries/base","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.8.4","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["ekmett","hvr"],"type":"Bug","description":"Now Monoid is defined in GHC.Base; We can define a reasonable Monad instance for `(,) w`, as a writer monad.","type_of_failure":"OtherFailure","blocking":[]} -->Now Monoid is defined in GHC.Base; We can define a reasonable Monad instance for `(,) w`, as a writer monad.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 7.8.4 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | libraries/base |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | ekmett, hvr |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Add a Monad instance for ((,) w)","status":"New","operating_system":"","component":"libraries/base","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.8.4","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["ekmett","hvr"],"type":"Bug","description":"Now Monoid is defined in GHC.Base; We can define a reasonable Monad instance for `(,) w`, as a writer monad.","type_of_failure":"OtherFailure","blocking":[]} -->8.0.1Fumiaki KinoshitaFumiaki Kinoshitahttps://gitlab.haskell.org/ghc/ghc/-/issues/10196Regression regarding Unicode subscript characters in identifiers2019-07-07T18:37:08ZthomieRegression regarding Unicode subscript characters in identifiersAs reported by both hvr as user Yongqian Li:
The \[changeset:d4fd16801bc59034abdc6214e60fcce2b21af9c8 Unicode 7.0 update\] in GHC 7.10 had the side effect of breaking code making use of subscript symbols that did compile with GHC 7.8.4, but won't anymore with GHC 7.10.1:
For instance, GHCi 7.8.4 accepts
```hs
let xᵦ = 1
let xᵤ = 1
let xᵩ = 1
let xᵢ = 1
let xᵪ = 1
let xᵣ = 1
let xₙ = 1
```
whereas GHC 7.10.1RC fails parsing those with a lexical error. (NB: GHC 7.8 does not accept *all* latin subscript letters either).As reported by both hvr as user Yongqian Li:
The \[changeset:d4fd16801bc59034abdc6214e60fcce2b21af9c8 Unicode 7.0 update\] in GHC 7.10 had the side effect of breaking code making use of subscript symbols that did compile with GHC 7.8.4, but won't anymore with GHC 7.10.1:
For instance, GHCi 7.8.4 accepts
```hs
let xᵦ = 1
let xᵤ = 1
let xᵩ = 1
let xᵢ = 1
let xᵪ = 1
let xᵣ = 1
let xₙ = 1
```
whereas GHC 7.10.1RC fails parsing those with a lexical error. (NB: GHC 7.8 does not accept *all* latin subscript letters either).7.10.2https://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 Kmett