GHC issueshttps://gitlab.haskell.org/ghc/ghc/-/issues2019-07-07T18:34:09Zhttps://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/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/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/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/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/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 Kmetthttps://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 specifi...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.1vlopezvlopez