GHC issueshttps://gitlab.haskell.org/ghc/ghc/-/issues2019-07-07T18:27:35Zhttps://gitlab.haskell.org/ghc/ghc/-/issues/12120GHC accepts invalid Haskell: `class Eq (a Int) => C a where`2019-07-07T18:27:35ZthomieGHC accepts invalid Haskell: `class Eq (a Int) => C a where`From the Haskell 2010 report [chapter 4](https://www.haskell.org/onlinereport/haskell2010/haskellch4.html),
- Class and instance declarations:
```
| class [scontext =>] ...
| instance [scontext =>] ...
```
- Normal type signatures:
```
vars :: [context =>] ...
```
Notice the difference between `scontext` (//with// `s`) and `context` (without `s`).
```
scontext → simpleclass
| ( simpleclass1 , … , simpleclassn ) (n ≥ 0)
simpleclass → qtycls tyvar
```
```
context → class
| ( class1 , … , classn ) (n ≥ 0)
class → qtycls tyvar
| qtycls ( tyvar atype1 … atypen ) (n ≥ 1)
```
GHC seems to ignore this difference, and happily accepts `class Eq (a Int) => C a where`. Hugs (Version: September 2006) reports for that same example:
```
Illegal Haskell 98 class constraint in class declaration
*** Constraint : Eq (a Int)
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.0.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | lowest |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"GHC accepts invalid Haskell: `class Eq (a Int) => C a where`","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.0.1","keywords":["report-impact"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"From the Haskell 2010 report [https://www.haskell.org/onlinereport/haskell2010/haskellch4.html chapter 4],\r\n\r\n* Class and instance declarations:\r\n{{{\r\n| \tclass [scontext =>] ...\r\n| \tinstance [scontext =>] ...\r\n}}}\r\n\r\n* Normal type signatures:\r\n{{{\r\n\tvars :: [context =>] ...\r\n}}}\r\n\r\nNotice the difference between `scontext` (//with// `s`) and `context` (without `s`).\r\n\r\n{{{\r\nscontext \t→ \tsimpleclass\r\n\t| \t( simpleclass1 , … , simpleclassn ) \t (n ≥ 0)\r\nsimpleclass \t→ \tqtycls tyvar\r\n}}}\r\n\r\n{{{\r\ncontext \t→ \tclass\r\n\t| \t( class1 , … , classn ) \t (n ≥ 0)\r\nclass \t→ \tqtycls tyvar\r\n\t| \tqtycls ( tyvar atype1 … atypen ) \t (n ≥ 1)\r\n\r\n}}}\r\n\r\nGHC seems to ignore this difference, and happily accepts `class Eq (a Int) => C a where`. Hugs (Version: September 2006) reports for that same example:\r\n{{{\r\nIllegal Haskell 98 class constraint in class declaration\r\n*** Constraint : Eq (a Int)\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->From the Haskell 2010 report [chapter 4](https://www.haskell.org/onlinereport/haskell2010/haskellch4.html),
- Class and instance declarations:
```
| class [scontext =>] ...
| instance [scontext =>] ...
```
- Normal type signatures:
```
vars :: [context =>] ...
```
Notice the difference between `scontext` (//with// `s`) and `context` (without `s`).
```
scontext → simpleclass
| ( simpleclass1 , … , simpleclassn ) (n ≥ 0)
simpleclass → qtycls tyvar
```
```
context → class
| ( class1 , … , classn ) (n ≥ 0)
class → qtycls tyvar
| qtycls ( tyvar atype1 … atypen ) (n ≥ 1)
```
GHC seems to ignore this difference, and happily accepts `class Eq (a Int) => C a where`. Hugs (Version: September 2006) reports for that same example:
```
Illegal Haskell 98 class constraint in class declaration
*** Constraint : Eq (a Int)
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.0.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | lowest |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"GHC accepts invalid Haskell: `class Eq (a Int) => C a where`","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.0.1","keywords":["report-impact"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"From the Haskell 2010 report [https://www.haskell.org/onlinereport/haskell2010/haskellch4.html chapter 4],\r\n\r\n* Class and instance declarations:\r\n{{{\r\n| \tclass [scontext =>] ...\r\n| \tinstance [scontext =>] ...\r\n}}}\r\n\r\n* Normal type signatures:\r\n{{{\r\n\tvars :: [context =>] ...\r\n}}}\r\n\r\nNotice the difference between `scontext` (//with// `s`) and `context` (without `s`).\r\n\r\n{{{\r\nscontext \t→ \tsimpleclass\r\n\t| \t( simpleclass1 , … , simpleclassn ) \t (n ≥ 0)\r\nsimpleclass \t→ \tqtycls tyvar\r\n}}}\r\n\r\n{{{\r\ncontext \t→ \tclass\r\n\t| \t( class1 , … , classn ) \t (n ≥ 0)\r\nclass \t→ \tqtycls tyvar\r\n\t| \tqtycls ( tyvar atype1 … atypen ) \t (n ≥ 1)\r\n\r\n}}}\r\n\r\nGHC seems to ignore this difference, and happily accepts `class Eq (a Int) => C a where`. Hugs (Version: September 2006) reports for that same example:\r\n{{{\r\nIllegal Haskell 98 class constraint in class declaration\r\n*** Constraint : Eq (a Int)\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->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/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/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/11170(read ".9") :: Double unable to parse2019-07-07T18:31:39Zvarosi(read ".9") :: Double unable to parseFor most languages ".9" is a floating point number equal to 0.9, but in GHC this is unparsable. I don't know if it is by design, but it was unexpected by me. I think that it is good this to be valid parsable to Double string.
What do you think of?
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 7.10.2 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Prelude |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | Windows |
| Architecture | x86_64 (amd64) |
</details>
<!-- {"blocked_by":[],"summary":"(read \".9\") :: Double unable to parse","status":"New","operating_system":"Windows","component":"Prelude","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.10.2","keywords":["Read"],"differentials":[],"test_case":"","architecture":"x86_64 (amd64)","cc":[""],"type":"Bug","description":"For most languages \".9\" is a floating point number equal to 0.9, but in GHC this is unparsable. I don't know if it is by design, but it was unexpected by me. I think that it is good this to be valid parsable to Double string.\r\n\r\nWhat do you think of?","type_of_failure":"OtherFailure","blocking":[]} -->For most languages ".9" is a floating point number equal to 0.9, but in GHC this is unparsable. I don't know if it is by design, but it was unexpected by me. I think that it is good this to be valid parsable to Double string.
What do you think of?
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 7.10.2 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Prelude |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | Windows |
| Architecture | x86_64 (amd64) |
</details>
<!-- {"blocked_by":[],"summary":"(read \".9\") :: Double unable to parse","status":"New","operating_system":"Windows","component":"Prelude","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.10.2","keywords":["Read"],"differentials":[],"test_case":"","architecture":"x86_64 (amd64)","cc":[""],"type":"Bug","description":"For most languages \".9\" is a floating point number equal to 0.9, but in GHC this is unparsable. I don't know if it is by design, but it was unexpected by me. I think that it is good this to be valid parsable to Double string.\r\n\r\nWhat do you think of?","type_of_failure":"OtherFailure","blocking":[]} -->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/10444Text.Read.Lex.lex broken2019-07-07T18:35:53ZstrakeText.Read.Lex.lex broken```
Prelude> lex "&) = mempty"
[("&",") = mempty")]
Prelude> lex "∘) = mempty"
[]
```
I traced this problem to Text.Read.Lex.lex```
Prelude> lex "&) = mempty"
[("&",") = mempty")]
Prelude> lex "∘) = mempty"
[]
```
I traced this problem to Text.Read.Lex.lex8.0.1Edward KmettEdward Kmetthttps://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/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/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/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/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/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/9573Add warning for invalid digits in integer literals2019-07-07T18:39:58ZvlopezAdd warning for invalid digits in integer literalsIn its latest version, GHC can parse binary (with `-XBinaryLiterals`), octal and hexadecimal literals:
```hs
> 0b101010
> 0o52
> 0x2A
```
Currently, the parser/lexer reads digits from the input as long as they are valid for the specified radix. All subsequent digits are interpreted as a new, separate token.
If the user uses a digit which isn't valid for the radix, it may be reported with a non-obvious error message, or interpreted in surprising ways:
```hs
> :t 0o567
0o576 :: Num a => a
> :t 0o5678
0o5678 :: (Num (a -> t), Num a) => t
> :t 0x1bfah
<interactive>:1:7: Not in scope: ‘h’
> replicate 0o5678
[8,8,8,8,8,8,8...
```
We suggest warning the user when a literal of this sort is written, while respecting any other error messages and the original behaviour.
More specifically, the parser or lexer would give a warning if a token starting with an alphanumeric character is found immediately after a numeric literal, without a blank between them.In its latest version, GHC can parse binary (with `-XBinaryLiterals`), octal and hexadecimal literals:
```hs
> 0b101010
> 0o52
> 0x2A
```
Currently, the parser/lexer reads digits from the input as long as they are valid for the specified radix. All subsequent digits are interpreted as a new, separate token.
If the user uses a digit which isn't valid for the radix, it may be reported with a non-obvious error message, or interpreted in surprising ways:
```hs
> :t 0o567
0o576 :: Num a => a
> :t 0o5678
0o5678 :: (Num (a -> t), Num a) => t
> :t 0x1bfah
<interactive>:1:7: Not in scope: ‘h’
> replicate 0o5678
[8,8,8,8,8,8,8...
```
We suggest warning the user when a literal of this sort is written, while respecting any other error messages and the original behaviour.
More specifically, the parser or lexer would give a warning if a token starting with an alphanumeric character is found immediately after a numeric literal, without a blank between them.8.0.1vlopezvlopezhttps://gitlab.haskell.org/ghc/ghc/-/issues/9550Add uncons to Data.List2019-07-07T18:40:03ZDavid FeuerAdd uncons to Data.ListThis was [discussed on the libraries list](http://www.haskell.org/pipermail/libraries/2014-July/023314.html) and favourably receivedThis was [discussed on the libraries list](http://www.haskell.org/pipermail/libraries/2014-July/023314.html) and favourably received7.10.1https://gitlab.haskell.org/ghc/ghc/-/issues/9532Expose new CLZ/CTZ primops via `Data.Bits` interface2019-07-07T18:40:08ZHerbert Valerio Riedelhvr@gnu.orgExpose new CLZ/CTZ primops via `Data.Bits` interfaceGHC now provides optimized CLZ/CTZ primops (see #9340), this ticket is about exposing those in a more convenient way.
This was proposed as
> http://www.haskell.org/pipermail/libraries/2014-August/023567.html
and passed (see also [proposal summary](http://www.haskell.org/pipermail/libraries/2014-August/023657.html))GHC now provides optimized CLZ/CTZ primops (see #9340), this ticket is about exposing those in a more convenient way.
This was proposed as
> http://www.haskell.org/pipermail/libraries/2014-August/023567.html
and passed (see also [proposal summary](http://www.haskell.org/pipermail/libraries/2014-August/023657.html))7.10.1Herbert Valerio Riedelhvr@gnu.orgHerbert Valerio Riedelhvr@gnu.org