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.1vlopezvlopezhttps://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/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/9588Add `MonadPlus (Either e)` and `Alternative (Either e)` instances2024-03-05T11:10:26ZHerbert 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, requir...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/7077Add an order-reversing newtype to Data.Ord2019-07-07T18:51:30ZAzelAdd an order-reversing newtype to Data.OrdThis is proposal to add an order-reversing newtype to Data.Ord by adding GHC.Exts's one, Down.
You'll find attached a patch implementing this re-export and the conversation thread may be found [here](http://haskell.1045720.n5.nabble.com...This is proposal to add an order-reversing newtype to Data.Ord by adding GHC.Exts's one, Down.
You'll find attached a patch implementing this re-export and the conversation thread may be found [here](http://haskell.1045720.n5.nabble.com/Proposal-add-an-order-reversing-newtype-to-Data-Ord-td5714005.html).
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | |
| Type | FeatureRequest |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | libraries/base |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Add an order-reversing newtype to Data.Ord","status":"New","operating_system":"","component":"libraries/base","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"","keywords":["ord"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"FeatureRequest","description":"This is proposal to add an order-reversing newtype to Data.Ord by adding GHC.Exts's one, Down.\r\n\r\nYou'll find attached a patch implementing this re-export and the conversation thread may be found [http://haskell.1045720.n5.nabble.com/Proposal-add-an-order-reversing-newtype-to-Data-Ord-td5714005.html here].","type_of_failure":"OtherFailure","blocking":[]} -->7.6.1pcapriottipcapriottihttps://gitlab.haskell.org/ghc/ghc/-/issues/5593Proposal: Remove Num superclass of Bits2019-07-07T18:54:35ZbasvandijkProposal: Remove Num superclass of BitsThis ticket summarizes the [discussion](http://www.haskell.org/pipermail/libraries/2011-October/016899.html) on the proposal to remove the `Num` superclass of the `Bits` type class.
The proposal is to:
- Remove the `Num` superclass of ...This ticket summarizes the [discussion](http://www.haskell.org/pipermail/libraries/2011-October/016899.html) on the proposal to remove the `Num` superclass of the `Bits` type class.
The proposal is to:
- Remove the `Num` superclass of the `Bits` type class.
- Remove the default implementations of `bit`, `testBit` and `popCount` since they use methods of `Num`.
- Export the following convenience functions from `Data.Bits`:
```
bitDefault :: (Bits a, Num a) => Int -> a
bitDefault i = 1 `shiftL` i
testBitDefault :: (Bits a, Num a) => a -> Int -> Bool
testBitDefault x i = (x .&. bit i) /= 0
popCountDefault :: (Bits a, Num a) => a -> Int
popCountDefault = go 0
where
go !c 0 = c
go c w = go (c+1) (w .&. w - 1) -- clear the least significant
```
Attached are tickets for `base` and `ghc`.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 7.2.1 |
| Type | Task |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | libraries/base |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Proposal: Remove Num superclass of Bits","status":"New","operating_system":"","component":"libraries/base","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.2.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Task","description":"This ticket summarizes the [http://www.haskell.org/pipermail/libraries/2011-October/016899.html discussion] on the proposal to remove the `Num` superclass of the `Bits` type class.\r\n\r\nThe proposal is to:\r\n\r\n * Remove the `Num` superclass of the `Bits` type class.\r\n\r\n * Remove the default implementations of `bit`, `testBit` and `popCount` since they use methods of `Num`.\r\n\r\n * Export the following convenience functions from `Data.Bits`:\r\n\r\n{{{\r\nbitDefault :: (Bits a, Num a) => Int -> a\r\nbitDefault i = 1 `shiftL` i\r\n\r\ntestBitDefault :: (Bits a, Num a) => a -> Int -> Bool\r\ntestBitDefault x i = (x .&. bit i) /= 0\r\n\r\npopCountDefault :: (Bits a, Num a) => a -> Int\r\npopCountDefault = go 0\r\n where\r\n go !c 0 = c\r\n go c w = go (c+1) (w .&. w - 1) -- clear the least significant\r\n}}}\r\n\r\nAttached are tickets for `base` and `ghc`.","type_of_failure":"OtherFailure","blocking":[]} -->7.6.1https://gitlab.haskell.org/ghc/ghc/-/issues/5414Add unsafeShift to Data.Bits2019-07-07T18:55:28ZtibbeAdd unsafeShift to Data.Bits`shiftL` and `shiftR` introduce an extra branch to check for overflows (i.e. shifts with an amount larger than 32/64). This branch gets removed if the shift amount is statically known, but otherwise leaves a branch in the optimized code,...`shiftL` and `shiftR` introduce an extra branch to check for overflows (i.e. shifts with an amount larger than 32/64). This branch gets removed if the shift amount is statically known, but otherwise leaves a branch in the optimized code, slowing down bit manipulation code.
`unsafeShiftL` and `unsafeShiftR` translate directly to the underlying hardware operation (which is undefined for shift amount larger than the architectures word size).
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 7.2.1 |
| Type | FeatureRequest |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | libraries/base |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Add unsafeShift to Data.Bits","status":"New","operating_system":"","component":"libraries/base","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"OwnedBy","contents":"simonmar"},"version":"7.2.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"FeatureRequest","description":"`shiftL` and `shiftR` introduce an extra branch to check for overflows (i.e. shifts with an amount larger than 32/64). This branch gets removed if the shift amount is statically known, but otherwise leaves a branch in the optimized code, slowing down bit manipulation code.\r\n\r\n`unsafeShiftL` and `unsafeShiftR` translate directly to the underlying hardware operation (which is undefined for shift amount larger than the architectures word size).\r\n","type_of_failure":"OtherFailure","blocking":[]} -->7.4.1Simon MarlowSimon Marlowhttps://gitlab.haskell.org/ghc/ghc/-/issues/4865Deprecate and remove Prelude.catch and System.IO.Error.{catch,try}2019-07-07T18:58:09ZIan Lynagh <igloo@earth.li>Deprecate and remove Prelude.catch and System.IO.Error.{catch,try}`Prelude` and `System.IO.Error` both export an old version of `catch`, which only catches `IOError`s, and `System.IO.Error` additionally exports `try` with the same problem.
These exports are annoying for people who want to use the mode...`Prelude` and `System.IO.Error` both export an old version of `catch`, which only catches `IOError`s, and `System.IO.Error` additionally exports `try` with the same problem.
These exports are annoying for people who want to use the modern exception handling functions in `Control.Exception`, as you need to explicitly either import the `Prelude` with `catch` hidden, or give the module of the function you want to use.
They may also be confusing for beginners, who may not expect to have to use anything other than the `catch` function in the default scope to catch all exceptions.
I believe these functions are only there for historical reasons, and are old cruft that we should tidy up, so I propose that in the `base` package that comes with GHC 7.2 we deprecate these old functions, and in 7.4 we remove them.
Suggested deadline: 24 Jan 2011.
<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":"Deprecate and remove Prelude.catch and System.IO.Error.{catch,try}","status":"New","operating_system":"","component":"libraries/base","related":[],"milestone":"Not GHC","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.0.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"`Prelude` and `System.IO.Error` both export an old version of `catch`, which only catches `IOError`s, and `System.IO.Error` additionally exports `try` with the same problem.\r\n\r\nThese exports are annoying for people who want to use the modern exception handling functions in `Control.Exception`, as you need to explicitly either import the `Prelude` with `catch` hidden, or give the module of the function you want to use.\r\n\r\nThey may also be confusing for beginners, who may not expect to have to use anything other than the `catch` function in the default scope to catch all exceptions.\r\n\r\nI believe these functions are only there for historical reasons, and are old cruft that we should tidy up, so I propose that in the `base` package that comes with GHC 7.2 we deprecate these old functions, and in 7.4 we remove them.\r\n\r\nSuggested deadline: 24 Jan 2011.\r\n","type_of_failure":"OtherFailure","blocking":[]} -->Not GHChttps://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/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/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/12120GHC accepts invalid Haskell: `class Eq (a Int) => C a where`2019-07-07T18:27:35ZThomas MiedemaGHC 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:
...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/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)