GHC issueshttps://gitlab.haskell.org/ghc/ghc/-/issues2019-07-07T18:40:08Zhttps://gitlab.haskell.org/ghc/ghc/-/issues/9532Expose new CLZ/CTZ primops via `Data.Bits` interface2019-07-07T18:40:08ZHerbert Valerio Riedelhvr@gnu.orgExpose new CLZ/CTZ primops via `Data.Bits` interfaceGHC now provides optimized CLZ/CTZ primops (see #9340), this ticket is about exposing those in a more convenient way.
This was proposed as
> http://www.haskell.org/pipermail/libraries/2014-August/023567.html
and passed (see also [prop...GHC now provides optimized CLZ/CTZ primops (see #9340), this ticket is about exposing those in a more convenient way.
This was proposed as
> http://www.haskell.org/pipermail/libraries/2014-August/023567.html
and passed (see also [proposal summary](http://www.haskell.org/pipermail/libraries/2014-August/023657.html))7.10.1Herbert Valerio Riedelhvr@gnu.orgHerbert Valerio Riedelhvr@gnu.orghttps://gitlab.haskell.org/ghc/ghc/-/issues/9531Implement Prelude.Word Proposal2019-07-07T18:40:08ZHerbert Valerio Riedelhvr@gnu.orgImplement Prelude.Word ProposalThis was proposed on the libraries list and succeeded by vote majority as well as by explicit
confirmation from the core libraries committee.
See [proposal summary](http://www.haskell.org/pipermail/libraries/2014-August/023658.html) for...This was proposed on the libraries list and succeeded by vote majority as well as by explicit
confirmation from the core libraries committee.
See [proposal summary](http://www.haskell.org/pipermail/libraries/2014-August/023658.html) for details.7.10.1Herbert Valerio Riedelhvr@gnu.orgHerbert Valerio Riedelhvr@gnu.orghttps://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/9099Add strict fmap2019-07-07T18:41:55ZquchenAdd strict fmapAdd a strict version of fmap to the standard libraries.
```
infixl 4 <$!>
(<$!>) :: Monad m => (a -> b) -> m a -> m b
f <$!> m = do x <- m
return $! f x
{-# INLINE (<$!>) #-}
```
Libraries discussions:
Take 1: http://...Add a strict version of fmap to the standard libraries.
```
infixl 4 <$!>
(<$!>) :: Monad m => (a -> b) -> m a -> m b
f <$!> m = do x <- m
return $! f x
{-# INLINE (<$!>) #-}
```
Libraries discussions:
Take 1: http://www.haskell.org/pipermail/libraries/2013-November/021728.html
Take 3: http://www.haskell.org/pipermail/libraries/2014-April/022864.html
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 7.8.2 |
| Type | FeatureRequest |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | None |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Add strict fmap","status":"New","operating_system":"","component":"None","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.8.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"FeatureRequest","description":"Add a strict version of fmap to the standard libraries.\r\n\r\n{{{\r\ninfixl 4 <$!>\r\n \r\n(<$!>) :: Monad m => (a -> b) -> m a -> m b\r\nf <$!> m = do x <- m\r\n return $! f x\r\n{-# INLINE (<$!>) #-}\r\n}}}\r\n\r\nLibraries discussions:\r\n\r\nTake 1: http://www.haskell.org/pipermail/libraries/2013-November/021728.html\r\nTake 3: http://www.haskell.org/pipermail/libraries/2014-April/022864.html","type_of_failure":"OtherFailure","blocking":[]} -->7.10.1https://gitlab.haskell.org/ghc/ghc/-/issues/9016Add System.Exit.die2019-07-07T18:42:18ZSimon Hengelsol@typeful.netAdd System.Exit.die(as per the proposal/discussion on haskell-libraries, I just posted a summary that "awaits moderator approval")
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------...(as per the proposal/discussion on haskell-libraries, I just posted a summary that "awaits moderator approval")
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 7.8.2 |
| Type | FeatureRequest |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | libraries/base |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | hvr |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Add System.Exit.die","status":"New","operating_system":"","component":"libraries/base","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.8.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["hvr"],"type":"FeatureRequest","description":"(as per the proposal/discussion on haskell-libraries, I just posted a summary that \"awaits moderator approval\")","type_of_failure":"OtherFailure","blocking":[]} -->7.10.1https://gitlab.haskell.org/ghc/ghc/-/issues/9008Data.Function: Add reverse application operator2019-07-07T18:42:20ZbernalexData.Function: Add reverse application operator<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 7.8.2 |
| Type | FeatureRequest |
| TypeOfFailure ...<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 7.8.2 |
| Type | FeatureRequest |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | libraries/base |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | hvr |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Data.Function: Add reverse application operator","status":"New","operating_system":"","component":"libraries/base","related":[],"milestone":"7.10.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.8.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["hvr"],"type":"FeatureRequest","description":"","type_of_failure":"OtherFailure","blocking":[]} -->7.10.1https://gitlab.haskell.org/ghc/ghc/-/issues/9004Add sortOn function to Data.List2019-07-07T18:42:21ZJohnWiegleyAdd sortOn function to Data.ListThe following passed for two weeks on the libraries mailing list without any dissenting votes.
The request is to add the following function to Data.List:
```
-- | Sort a list by comparing the results of a key function applied to each
-...The following passed for two weeks on the libraries mailing list without any dissenting votes.
The request is to add the following function to Data.List:
```
-- | Sort a list by comparing the results of a key function applied to each
-- element. @sortOn f@ is equivalent to @sortBy . comparing f@, but has the
-- performance advantage of only evaluating @f@ once for each element in the
-- input list. This is called the decorate-sort-undecorate paradigm, or
-- Schwartzian transform.
sortOn :: Ord b => (a -> b) -> [a] -> [a]
sortOn f = map snd . sortBy (comparing fst)
. map (\x -> let y = f x in y `seq` (y, x))
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 7.8.2 |
| Type | FeatureRequest |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | libraries/base |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | hvr |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Add sortOn function to Data.List","status":"New","operating_system":"","component":"libraries/base","related":[],"milestone":"7.10.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.8.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["hvr"],"type":"FeatureRequest","description":"The following passed for two weeks on the libraries mailing list without any dissenting votes.\r\n\r\nThe request is to add the following function to Data.List:\r\n\r\n{{{\r\n-- | Sort a list by comparing the results of a key function applied to each\r\n-- element. @sortOn f@ is equivalent to @sortBy . comparing f@, but has the\r\n-- performance advantage of only evaluating @f@ once for each element in the\r\n-- input list. This is called the decorate-sort-undecorate paradigm, or\r\n-- Schwartzian transform.\r\nsortOn :: Ord b => (a -> b) -> [a] -> [a]\r\nsortOn f = map snd . sortBy (comparing fst)\r\n . map (\\x -> let y = f x in y `seq` (y, x))\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->7.10.1https://gitlab.haskell.org/ghc/ghc/-/issues/8302Add 'bool' to Data.Bool2019-07-07T18:45:39ZOllie CharlesAdd 'bool' to Data.BoolAs mentioned in http://www.haskell.org/pipermail/libraries/2013-September/020492.html I propose we add the 'bool' function to 'Data.Bool'.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| --------...As mentioned in http://www.haskell.org/pipermail/libraries/2013-September/020492.html I propose we add the 'bool' function to 'Data.Bool'.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 7.6.3 |
| 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 'bool' to Data.Bool","status":"New","operating_system":"","component":"libraries/base","related":[],"milestone":"7.8.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.6.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"FeatureRequest","description":"As mentioned in http://www.haskell.org/pipermail/libraries/2013-September/020492.html I propose we add the 'bool' function to 'Data.Bool'.","type_of_failure":"OtherFailure","blocking":[]} -->7.8.1https://gitlab.haskell.org/ghc/ghc/-/issues/7817Moving basic functions2019-07-07T18:47:58ZquchenMoving basic functions**1.** Add the `infixl 4` operator `($>) = flip (<$)` to Data.Functor.
**2.** Move `Control.Monad.void` to `Data.Functor`, and re-export it from `Control.Monad` for compatibility. In addition, replace the deprecated `Foreign.Marshal.Err...**1.** Add the `infixl 4` operator `($>) = flip (<$)` to Data.Functor.
**2.** Move `Control.Monad.void` to `Data.Functor`, and re-export it from `Control.Monad` for compatibility. In addition, replace the deprecated `Foreign.Marshal.Error.void` with a re-export as well.
The mailing list discussion is here:
http://markmail.org/message/cqdlle4l6npxs3jn
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 7.6.2 |
| 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":"Moving basic functions","status":"New","operating_system":"","component":"libraries/base","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.6.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"FeatureRequest","description":"'''1.''' Add the `infixl 4` operator `($>) = flip (<$)` to Data.Functor.\r\n\r\n'''2.''' Move `Control.Monad.void` to `Data.Functor`, and re-export it from `Control.Monad` for compatibility. In addition, replace the deprecated `Foreign.Marshal.Error.void` with a re-export as well.\r\n\r\nThe mailing list discussion is here:\r\nhttp://markmail.org/message/cqdlle4l6npxs3jn","type_of_failure":"OtherFailure","blocking":[]} -->7.8.1https://gitlab.haskell.org/ghc/ghc/-/issues/7530Proposal: Add isLeft/isRight to Data.Either2019-07-07T18:49:20ZSimon Hengelsol@typeful.netProposal: Add isLeft/isRight to Data.EitherI propose to add `isLeft`/`isRight` to `Data.Either`. The corresponding thread on `haskell-liraries` is here: http://www.haskell.org/pipermail/libraries/2012-November/018976.html
<details><summary>Trac metadata</summary>
| Trac field ...I propose to add `isLeft`/`isRight` to `Data.Either`. The corresponding thread on `haskell-liraries` is here: http://www.haskell.org/pipermail/libraries/2012-November/018976.html
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.6.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Proposal: Add isLeft/isRight to Data.Either","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.6.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"I propose to add {{{isLeft}}}/{{{isRight}}} to {{{Data.Either}}}. The corresponding thread on {{{haskell-liraries}}} is here: http://www.haskell.org/pipermail/libraries/2012-November/018976.html","type_of_failure":"OtherFailure","blocking":[]} -->7.8.1https://gitlab.haskell.org/ghc/ghc/-/issues/7425Add method to Data.Bits for creating zeroed values.2019-07-07T18:49:47ZAninhumerAdd method to Data.Bits for creating zeroed values.The removal of the Num superclass from Data.Bits now means there is no simple way to create a value in which all bits are set to zero. There are obviously a variety of ways such a value can be constructed with the existing methods, but n...The removal of the Num superclass from Data.Bits now means there is no simple way to create a value in which all bits are set to zero. There are obviously a variety of ways such a value can be constructed with the existing methods, but nonetheless it seems like an odd omission.
The new method could be given an implementation in terms of the existing ones for backwards compatibility.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 7.6.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 method to Data.Bits for creating zeroed values.","status":"New","operating_system":"","component":"libraries/base","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.6.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"FeatureRequest","description":"The removal of the Num superclass from Data.Bits now means there is no simple way to create a value in which all bits are set to zero. There are obviously a variety of ways such a value can be constructed with the existing methods, but nonetheless it seems like an odd omission.\r\n\r\nThe new method could be given an implementation in terms of the existing ones for backwards compatibility.","type_of_failure":"OtherFailure","blocking":[]} -->7.8.1https://gitlab.haskell.org/ghc/ghc/-/issues/7424Add Data.Bits instance for Bool2019-07-07T18:49:48ZAninhumerAdd Data.Bits instance for BoolGiven the common use cases for Data.Bits, it seems strange that there is no instance for Bool. Previously, the Num superclass was a reason not to include one, as there are valid objections to a Num Bool instance. However, this superclass...Given the common use cases for Data.Bits, it seems strange that there is no instance for Bool. Previously, the Num superclass was a reason not to include one, as there are valid objections to a Num Bool instance. However, this superclass requirement has now been removed, so I think adding a Bits Bool instance would be a good idea.
I have attached a local implementation which I am using, but it may not entirely match the intended semantics of Bits.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 7.6.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 Data.Bits instance for Bool","status":"New","operating_system":"","component":"libraries/base","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.6.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"FeatureRequest","description":"Given the common use cases for Data.Bits, it seems strange that there is no instance for Bool. Previously, the Num superclass was a reason not to include one, as there are valid objections to a Num Bool instance. However, this superclass requirement has now been removed, so I think adding a Bits Bool instance would be a good idea.\r\n\r\nI have attached a local implementation which I am using, but it may not entirely match the intended semantics of Bits.","type_of_failure":"OtherFailure","blocking":[]} -->7.8.1https://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/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/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/4834Implement Functor => Applicative => Monad Hierarchy (aka AMP phase 3)2021-11-02T09:27:32ZgidynImplement Functor => Applicative => Monad Hierarchy (aka AMP phase 3)The standard class hierarchy is a consequence of Haskell's historical development, rather than logic. I would therefore like to propose a reform of the Functor, Applicative, and Monad type classes. The new hierarchy is logical, eliminate...The standard class hierarchy is a consequence of Haskell's historical development, rather than logic. I would therefore like to propose a reform of the Functor, Applicative, and Monad type classes. The new hierarchy is logical, eliminates many duplicate names from the standard type class definitions, and removes the need for boilerplate Monad -\> Applicative instance declarations.
The proposal is detailed in [the wiki](http://haskell.org/haskellwiki/Functor-Applicative-Monad_Proposal), along with an example of a legacy module to provide some backwards-compatibility.
<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":"New Functor => Applicative => Monad Hierarchy","status":"New","operating_system":"","component":"libraries/base","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.0.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"The standard class hierarchy is a consequence of Haskell's historical development, rather than logic. I would therefore like to propose a reform of the Functor, Applicative, and Monad type classes. The new hierarchy is logical, eliminates many duplicate names from the standard type class definitions, and removes the need for boilerplate Monad -> Applicative instance declarations.\r\n\r\nThe proposal is detailed in [http://haskell.org/haskellwiki/Functor-Applicative-Monad_Proposal the wiki], along with an example of a legacy module to provide some backwards-compatibility. ","type_of_failure":"OtherFailure","blocking":[]} -->7.10.1https://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/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":[]} -->