GHC issueshttps://gitlab.haskell.org/ghc/ghc/-/issues2019-07-07T18:34:11Zhttps://gitlab.haskell.org/ghc/ghc/-/issues/10751Implement Phase 1 of MonadFail Proposal (MFP)2019-07-07T18:34:11ZHerbert Valerio Riedelhvr@gnu.orgImplement Phase 1 of MonadFail Proposal (MFP)See also
- https://www.reddit.com/r/haskell/comments/3a1o06/monadfail_proposal_mfp/
TODO: At this point this ticket is mostly a reminder that stuff may need to be done for GHC 7.12
David Luposchainsky [says that he plans to work on i...See also
- https://www.reddit.com/r/haskell/comments/3a1o06/monadfail_proposal_mfp/
TODO: At this point this ticket is mostly a reminder that stuff may need to be done for GHC 7.12
David Luposchainsky [says that he plans to work on it](https://mail.haskell.org/pipermail/ghc-devs/2015-August/009664.html).8.0.1quchenquchenhttps://gitlab.haskell.org/ghc/ghc/-/issues/10113Re-export (<$>) and (<$) from Prelude2019-07-07T18:37:27ZHerbert Valerio Riedelhvr@gnu.orgRe-export (<$>) and (<$) from PreludeSee http://thread.gmane.org/gmane.comp.lang.haskell.libraries/24161 for details
decision is still outstanding, but this needs to go into RC3 unless there's good reasons not to
<details><summary>Trac metadata</summary>
| Trac field ...See http://thread.gmane.org/gmane.comp.lang.haskell.libraries/24161 for details
decision is still outstanding, but this needs to go into RC3 unless there's good reasons not to
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------------------- |
| Version | 7.10.1-rc2 |
| Type | FeatureRequest |
| TypeOfFailure | OtherFailure |
| Priority | highest |
| Resolution | Unresolved |
| Component | libraries/base |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | ekmett, hvr, thoughtpolice |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Re-export (<$>) from Prelude","status":"New","operating_system":"","component":"libraries/base","related":[],"milestone":"7.10.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.10.1-rc2","keywords":["AMP"],"differentials":[],"test_case":"","architecture":"","cc":["ekmett","hvr","thoughtpolice"],"type":"FeatureRequest","description":"See http://thread.gmane.org/gmane.comp.lang.haskell.libraries/24161 for details\r\n\r\ndecision is still outstanding, but this needs to go into RC3 unless there's good reasons not to","type_of_failure":"OtherFailure","blocking":[]} -->7.10.1https://gitlab.haskell.org/ghc/ghc/-/issues/10365Implement Semigroup as a superclass of Monoid Proposal (Phase 1)2019-07-07T18:36:23ZgidynImplement Semigroup as a superclass of Monoid Proposal (Phase 1)More details in prime:Libraries/Proposals/SemigroupMonoid
### Phase 1 (GHC 7.12)
Phase 1 consists in (at the very least) moving `Data.Semigroup` and `Data.List.NonEmpty` into `base` for GHC 7.12 (aka 8.0).
If there's enough time we wi...More details in prime:Libraries/Proposals/SemigroupMonoid
### Phase 1 (GHC 7.12)
Phase 1 consists in (at the very least) moving `Data.Semigroup` and `Data.List.NonEmpty` into `base` for GHC 7.12 (aka 8.0).
If there's enough time we will also implement a warning as part of the first phase:
> Add a warning about definitions of an operator named `(<>)` that indicate it will be coming into Prelude in 7.14. We should warn about missing Semigroup instances at any use site of `(<>)` as they'll break in 7.14.8.0.1quchenquchenhttps://gitlab.haskell.org/ghc/ghc/-/issues/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 sim...(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/4834Implement Functor => Applicative => Monad Hierarchy (aka AMP phase 3)2021-11-02T09:27:32ZgidynImplement Functor => Applicative => Monad Hierarchy (aka AMP phase 3)The standard class hierarchy is a consequence of Haskell's historical development, rather than logic. I would therefore like to propose a reform of the Functor, Applicative, and Monad type classes. The new hierarchy is logical, eliminate...The standard class hierarchy is a consequence of Haskell's historical development, rather than logic. I would therefore like to propose a reform of the Functor, Applicative, and Monad type classes. The new hierarchy is logical, eliminates many duplicate names from the standard type class definitions, and removes the need for boilerplate Monad -\> Applicative instance declarations.
The proposal is detailed in [the wiki](http://haskell.org/haskellwiki/Functor-Applicative-Monad_Proposal), along with an example of a legacy module to provide some backwards-compatibility.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 7.0.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | libraries/base |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"New Functor => Applicative => Monad Hierarchy","status":"New","operating_system":"","component":"libraries/base","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.0.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"The standard class hierarchy is a consequence of Haskell's historical development, rather than logic. I would therefore like to propose a reform of the Functor, Applicative, and Monad type classes. The new hierarchy is logical, eliminates many duplicate names from the standard type class definitions, and removes the need for boilerplate Monad -> Applicative instance declarations.\r\n\r\nThe proposal is detailed in [http://haskell.org/haskellwiki/Functor-Applicative-Monad_Proposal the wiki], along with an example of a legacy module to provide some backwards-compatibility. ","type_of_failure":"OtherFailure","blocking":[]} -->7.10.1https://gitlab.haskell.org/ghc/ghc/-/issues/1990Add 'subsequences' and 'permutations' to Data.List2021-12-07T11:13:18ZtwanvlAdd 'subsequences' and 'permutations' to Data.ListHaskell 1.3 included the functions 'subsequences' and 'permutations'. I think these functions are quite useful, and I don't know why they were ever removed. This is a proposal to add these two functions to Data.List. The implementation i...Haskell 1.3 included the functions 'subsequences' and 'permutations'. I think these functions are quite useful, and I don't know why they were ever removed. This is a proposal to add these two functions to Data.List. The implementation is taken directly from the Haskell 1.3 report (http://haskell.cs.yale.edu/haskell-report/List.html).
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 6.8.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | libraries/base |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | Unknown |
| Architecture | Unknown |
</details>
<!-- {"blocked_by":[],"summary":"Add 'subsequences' and 'permutations' to Data.List","status":"New","operating_system":"Unknown","component":"libraries/base","related":[],"milestone":"Not GHC","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.8.1","keywords":[],"differentials":[],"test_case":"","architecture":"Unknown","cc":[""],"type":"Bug","description":"Haskell 1.3 included the functions 'subsequences' and 'permutations'. I think these functions are quite useful, and I don't know why they were ever removed. This is a proposal to add these two functions to Data.List. The implementation is taken directly from the Haskell 1.3 report (http://haskell.cs.yale.edu/haskell-report/List.html).","type_of_failure":"OtherFailure","blocking":[]} -->6.10 branchIan Lynagh <igloo@earth.li>Ian Lynagh <igloo@earth.li>https://gitlab.haskell.org/ghc/ghc/-/issues/18252What fixity does `~` has?2020-10-12T14:05:50ZOleg GrenrusWhat fixity does `~` has?```haskell
Prelude Data.Type.Equality> :i :~:
...
infix 4 :~:
```
yet
```haskell
Prelude Data.Type.Equality> :i (~)
...
-- says nothing
```
I'd expect them to have similar fixity.
Having `~` bind less tight then e.g. `GHC.TypeLits.+`...```haskell
Prelude Data.Type.Equality> :i :~:
...
infix 4 :~:
```
yet
```haskell
Prelude Data.Type.Equality> :i (~)
...
-- says nothing
```
I'd expect them to have similar fixity.
Having `~` bind less tight then e.g. `GHC.TypeLits.+` (`infixl 6`) would be very nice.
```haskell
Prelude Data.Type.Equality GHC.TypeLits> :kind! 5 + 5 :~: 10
5 + 5 :~: 10 :: *
= 10 :~: 10
Prelude Data.Type.Equality GHC.TypeLits> :kind! 5 + 5 ~ 10
<interactive>:1:5: error:
• Expected kind ‘Nat’, but ‘5 ~ 10’ has kind ‘Constraint’
• In the second argument of ‘(+)’, namely ‘5 ~ 10’
In the type ‘5 + 5 ~ 10’
````9.0.1https://gitlab.haskell.org/ghc/ghc/-/issues/18251@ sensitivity breaks modules without any extensions enabled.2023-01-24T18:20:24ZOleg Grenrus@ sensitivity breaks modules without any extensions enabled.We got [a patch](https://github.com/haskell/cabal/pull/6844) to `cabal-install` which does
```diff
-finalparams @ (DepResolverParams
+finalparams@(DepResolverParams
```
in a file without any extensions enabled.
Please revert the chang...We got [a patch](https://github.com/haskell/cabal/pull/6844) to `cabal-install` which does
```diff
-finalparams @ (DepResolverParams
+finalparams@(DepResolverParams
```
in a file without any extensions enabled.
Please revert the change for 8.12. This kind of whitespace sensitivity in no-extensions enabled code is non-sense.
EDIT: [Proposal 229](https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0229-whitespace-bang-patterns.rst) should mention `@` in the title. Reading https://gitlab.haskell.org/ghc/ghc/-/wikis/migration/8.12, can I now define `(@)` function in GHC, even it's a reserved-op in Haskell Report?
https://gitlab.haskell.org/ghc/ghc/-/issues/18158Lexer is confused by suzhou numeral2023-06-13T18:41:07ZOleg GrenrusLexer is confused by suzhou numeral```haskell
main :: IO ()
main =
let 〥 = 5 in print 〥
```
fails to compile with
```
suzhou.hs:3:7: error: lexical error at character ' '
|
3 | let 〥 = 5 in print 〥
| ^
```
[suzhou.hs](/uploads/fa53490e3a20c230c5320d696d1...```haskell
main :: IO ()
main =
let 〥 = 5 in print 〥
```
fails to compile with
```
suzhou.hs:3:7: error: lexical error at character ' '
|
3 | let 〥 = 5 in print 〥
| ^
```
[suzhou.hs](/uploads/fa53490e3a20c230c5320d696d1202e7/suzhou.hs)
https://gitlab.haskell.org/ghc/ghc/issues/4373 might be related.
The below doesn't work either:
```haskell
main :: IO ()
main =
let ₂ = 2 in print ₂
```
```haskell
main :: IO ()
main =
let x = ₂ in print x
```
---
Haskell2010 defines
```
digit → ascDigit | uniDigit
decimal → digit{digit} (Numeric literals)
```
This says that last example `let x = ₂ in print x` should be acccepted, yet the text says
> Integer literals may be given in decimal (the default), ...
It feels that the grammar should be `decimal → ascDigit{ascDigit}` as `uniDigit` doesn't make sense in literals, yet non `ascDigit` digits could be IMO treated as "small letters".https://gitlab.haskell.org/ghc/ghc/-/issues/18151Eta-expansion of a left-section2021-01-12T23:04:49ZRichard Eisenbergrae@richarde.devEta-expansion of a left-sectionIf I say
```hs
x = seq (True `undefined`) ()
```
what should I get when evaluating `x`?
According to my understanding of the Haskell Report, I should get `()`. And according to my understanding of GHC's source code (in `GHC.Tc.Gen.Exp...If I say
```hs
x = seq (True `undefined`) ()
```
what should I get when evaluating `x`?
According to my understanding of the Haskell Report, I should get `()`. And according to my understanding of GHC's source code (in `GHC.Tc.Gen.Expr`), I should get `()`. But I get an exception.
Why?
NB: `-XPostfixOperators` is off. If it were on, the exception would be expected.
Spun off from https://github.com/ghc-proposals/ghc-proposals/pull/275#issuecomment-6242820229.0.1Vladislav ZavialovVladislav Zavialovhttps://gitlab.haskell.org/ghc/ghc/-/issues/17894Parsing of values and functions is not consistent2023-02-23T19:52:25ZDaniel TaskoffParsing of values and functions is not consistent## Motivation
It's very strange to me, that in the following snippet `f` gets parsed as a single `FunBind`, while `y` gets parsed as two `FunBind`s (and fails to compile afterwards).
```hs
f x | True = 42
f x = 0
y | True = 42
y = 0
`...## Motivation
It's very strange to me, that in the following snippet `f` gets parsed as a single `FunBind`, while `y` gets parsed as two `FunBind`s (and fails to compile afterwards).
```hs
f x | True = 42
f x = 0
y | True = 42
y = 0
```
I think this is useful in `let` blocks.
## Proposal
Parse such values and functions in the same way.https://gitlab.haskell.org/ghc/ghc/-/issues/11609Document unicode report deviations2019-07-07T18:29:37ZThomas MiedemaDocument 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 l...\@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 yo...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 t...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:53ZMatthew Farkas-DyckText.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...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:08ZThomas MiedemaRegression 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,...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 |
| ---------------------- | -------------...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 he...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.u...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 Kmett