GHC issueshttps://gitlab.haskell.org/ghc/ghc/-/issues2019-07-07T18:31:39Zhttps://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/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/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/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/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...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/5071GHCi crashes on large alloca/allocaBytes requests2021-07-15T20:21:03ZguestGHCi crashes on large alloca/allocaBytes requestsGHCi, and ghc, seems to exit (crash?) on certain types of memory allocation exceptions.
The FFI addendum says that the allocation functions should be able to return null:
http://www.cse.unsw.edu.au/\~chak/haskell/ffi/ffi/ffise5.html\#x8...GHCi, and ghc, seems to exit (crash?) on certain types of memory allocation exceptions.
The FFI addendum says that the allocation functions should be able to return null:
http://www.cse.unsw.edu.au/\~chak/haskell/ffi/ffi/ffise5.html\#x8-230005
Section 5.8 says this:
> If any of the allocation functions fails, a value of Ptr.nullPtr is produced. If free or reallocBytes is applied to a memory area that has been allocated with alloca or allocaBytes, the behaviour is undefined. Any further access to memory areas allocated with alloca or allocaBytes, after the computation that was passed to the allocation function has terminated, leads to undefined behaviour. Any further access to the memory area referenced by a pointer passed to realloc, reallocBytes, or free entails undefined behaviour.
In practice, code examples and documentation appear to rely on `alloca` **NOT** returning a `nullPtr`:
- http://en.wikibooks.org/wiki/Haskell/FFI
- http://www.haskell.org/haskellwiki/HSFFIG/Examples
- http://book.realworldhaskell.org/read/interfacing-with-c-the-ffi.html
I reported this on the libraries list, and offered a documentation tweak, and I was asked to create a ticket:
http://www.haskell.org/pipermail/libraries/2011-March/016117.html
That email has details about the testing I did at the time to see the crashing behavior in ghci. I was using ghc 7.0.2 on 64bit windows, but this also appears to affect 7.0.3 on linux. It's likely that other versions of ghc are affected.
My recommendation would be to make the exception thrown by `alloca` catchable. Possibly offering an alternative to `alloca`, say `alloca'`, that can produce a `nullPtr` instead of using exceptions. I would advice against changing the existing `alloca` function to produce `nullPtr` as that could make a lot of existing code unsafe.
For example, it would be nice if the following printed "exception", instead of exiting:
```
$ ulimit -d 100000 -m 1000000 -v 100000
$ ghc --version
The Glorious Glasgow Haskell Compilation System, version 7.0.3
$ ./Alloca
Alloca: out of memory (requested 2148532224 bytes)
$ cat Alloca.hs
import Foreign
import Foreign.Marshal
import Foreign.Marshal.Alloc
import GHC.Exception
import System.IO.Error
main :: IO ()
main = do
(allocaBytes maxBound compare)
`catch` (\_ -> print "exception")
where
compare p = print ((nullPtr :: Ptr Int) == p)
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ---------------- |
| Version | 7.0.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | dagitj@gmail.com |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"GHCi crashes on large alloca/allocaBytes requests","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.0.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["dagitj@gmail.com"],"type":"Bug","description":"GHCi, and ghc, seems to exit (crash?) on certain types of memory allocation exceptions.\r\n\r\nThe FFI addendum says that the allocation functions should be able to return null:\r\nhttp://www.cse.unsw.edu.au/~chak/haskell/ffi/ffi/ffise5.html#x8-230005\r\n\r\nSection 5.8 says this:\r\n\r\n> If any of the allocation functions fails, a value of Ptr.nullPtr is produced. If free or reallocBytes is applied to a memory area that has been allocated with alloca or allocaBytes, the behaviour is undefined. Any further access to memory areas allocated with alloca or allocaBytes, after the computation that was passed to the allocation function has terminated, leads to undefined behaviour. Any further access to the memory area referenced by a pointer passed to realloc, reallocBytes, or free entails undefined behaviour.\r\n\r\n\r\nIn practice, code examples and documentation appear to rely on `alloca` '''NOT''' returning a `nullPtr`:\r\n * http://en.wikibooks.org/wiki/Haskell/FFI\r\n * http://www.haskell.org/haskellwiki/HSFFIG/Examples\r\n * http://book.realworldhaskell.org/read/interfacing-with-c-the-ffi.html\r\n\r\nI reported this on the libraries list, and offered a documentation tweak, and I was asked to create a ticket:\r\nhttp://www.haskell.org/pipermail/libraries/2011-March/016117.html\r\n\r\nThat email has details about the testing I did at the time to see the crashing behavior in ghci. I was using ghc 7.0.2 on 64bit windows, but this also appears to affect 7.0.3 on linux. It's likely that other versions of ghc are affected.\r\n\r\nMy recommendation would be to make the exception thrown by `alloca` catchable. Possibly offering an alternative to `alloca`, say `alloca'`, that can produce a `nullPtr` instead of using exceptions. I would advice against changing the existing `alloca` function to produce `nullPtr` as that could make a lot of existing code unsafe.\r\n\r\nFor example, it would be nice if the following printed \"exception\", instead of exiting:\r\n{{{\r\n$ ulimit -d 100000 -m 1000000 -v 100000\r\n$ ghc --version\r\nThe Glorious Glasgow Haskell Compilation System, version 7.0.3\r\n$ ./Alloca \r\nAlloca: out of memory (requested 2148532224 bytes)\r\n$ cat Alloca.hs\r\nimport Foreign\r\nimport Foreign.Marshal\r\nimport Foreign.Marshal.Alloc\r\nimport GHC.Exception\r\nimport System.IO.Error\r\n\r\nmain :: IO ()\r\nmain = do\r\n (allocaBytes maxBound compare)\r\n `catch` (\\_ -> print \"exception\")\r\n where\r\n compare p = print ((nullPtr :: Ptr Int) == p)\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->https://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 Kmetthttps://gitlab.haskell.org/ghc/ghc/-/issues/1103Japanese Unicode2019-07-07T19:15:15ZhumasectJapanese UnicodeUsing Japanese characters (either katakana or hiragana) in identifiers rules this:
Source/Hehe.hs:12:0: lexical error at character '\\12390'
There is no issue with Haskell98 for upper/lower case identifiers and type constructor identif...Using Japanese characters (either katakana or hiragana) in identifiers rules this:
Source/Hehe.hs:12:0: lexical error at character '\\12390'
There is no issue with Haskell98 for upper/lower case identifiers and type constructor identification with the two complimenting Japanese character sets. Using -fglasgow-exts along with other Unicode characters for various operators which work great.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------- |
| Version | 6.6 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler (Parser) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | MacOS X |
| Architecture | Unknown |
</details>
<!-- {"blocked_by":[],"summary":"Japanese Unicode","status":"New","operating_system":"MacOS X","component":"Compiler (Parser)","related":[],"milestone":"6.6.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.6","keywords":["-fglasgow-exts","japanese","lexical","unicode"],"differentials":[],"test_case":"","architecture":"Unknown","cc":[""],"type":"Bug","description":"Using Japanese characters (either katakana or hiragana) in identifiers rules this:\r\n\r\nSource/Hehe.hs:12:0: lexical error at character '\\12390'\r\n\r\nThere is no issue with Haskell98 for upper/lower case identifiers and type constructor identification with the two complimenting Japanese character sets. Using -fglasgow-exts along with other Unicode characters for various operators which work great.","type_of_failure":"OtherFailure","blocking":[]} -->