GHC issueshttps://gitlab.haskell.org/ghc/ghc/-/issues2023-01-24T18:20:24Zhttps://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/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)https://gitlab.haskell.org/ghc/ghc/-/issues/11012Support for unicode primes on identifiers.2022-09-20T12:03:01ZghartshawSupport 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 work...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/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/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/3676realToFrac doesn't sanely convert between floating types2019-07-07T19:02:50ZdraconxrealToFrac doesn't sanely convert between floating typesAs far as I can tell, the only way to convert between floating types in Haskell is to use realToFrac. Unfortunately, this function does some insane mangling of values when converting. Some examples:
```
realToFrac (0/0 :: Double) :: Dou...As far as I can tell, the only way to convert between floating types in Haskell is to use realToFrac. Unfortunately, this function does some insane mangling of values when converting. Some examples:
```
realToFrac (0/0 :: Double) :: Double
--> -Infinity
realToFrac (-1/0 :: Float) :: Double
--> -3.402823669209385e38
realToFrac (-0 :: Double) :: CDouble
--> 0.0
```
The last item illustrates an important point: it is impossible to convert a value from Double to CDouble without potentially changing it. This makes it difficult or impossible to use the FFI to call any functions with floating point parameters/return values.
Using a combination of unsafeCoerce (to shoehorn Double values in/out of CDoubles) and some functions written in C (to perform float\<=\>double), I was able to work around these problems, but that hardly seems like a nice solution.Edward KmettEdward Kmett