GHC issueshttps://gitlab.haskell.org/ghc/ghc/issues2019-07-07T18:39:54Zhttps://gitlab.haskell.org/ghc/ghc/issues/9588Add `MonadPlus (Either e)` and `Alternative (Either e)` instances2019-07-07T18:39:54ZHerbert 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, require us to move `Error` from `transformers` into base, which may be a controversial move.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/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 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":[]} -->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/17894Parsing of values and functions is not consistent2020-03-15T16:31:26ZDaniel 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
```
I think this is useful in `let` blocks.
## Proposal
Parse such values and functions in the same way.## 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/11012Support for unicode primes on identifiers.2019-07-07T18:32:40ZghartshawSupport 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 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":[]} -->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 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.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/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 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":[]} -->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/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/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":[]} -->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/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, 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":[]} -->`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 Marlow