November 2019 - Libraries

Deprecating fromIntegral
by Niklas Hambüchen 12 Aug '20

12 Aug '20

This is not a joke. I just found a bug in base (https://ghc.haskell.org/trac/ghc/ticket/14262) import System.IO hWaitForInput stdin 4294968296 This code should wait for 49.something days, but it waits for 1 second. It is caused by a quick use of `fromIntegral` to "convert" `Int -> CInt` (where CInt = Int32), causing an overflow. I argue that `fromIntegral` causes unnoticed data corruption without any warning, and thus are worse than partial functions. In this case, this data corruption occurs in the most fundamental code that we all use and have to rely upon (`base`). So I propose that we add a deprecation pragma to `fromIntegral` (however, keeping it forever, like Java does, as there's no benefit to removing it, we just want that people use safer functions over time), and instead provide a `safeFromIntegral` that can only widen ranges, and one or more `unsafeFromIntegral` or appropriately named functions that can error, wrap, return Maybe, or have whatever desired behaviour when the input value doesn't fit into the output type. For some inspiration, `foundation` provides ideas in that direction: http://hackage.haskell.org/package/basement-0.0.2/docs/Basement-From.html http://hackage.haskell.org/package/basement-0.0.2/docs/Basement-IntegralCon… It is a bit funny how we argue that Haskell is good for high assurance programming, and we build all sorts of fancy constructs to eliminate more run-time errors, when in fact we do worse than C in detecting errors in the most basic types a computer can use, such as converting between 64-bit and 32-bit integers. Let's fix that. It avoids real problems in real production systems that are difficult to debug when they happen (who writes a unit test checking that a timeout of 50 days still works? This is the kind of stuff where you have to rely on -- very basic -- types). I'd like to probe support for such a change before doing any work on it. Niklas

18 58

Deprecate First and Last in Data.Monoid
by Andrew Martin 13 Jun '20

13 Jun '20

I propose that the data types First and Last, provided by Data.Monoid, be marked deprecated in GHC 8.6 and removed in GHC 8.10. The Semigroup-Monoid Proposal (SMP) brought about changes that, I will argue, make these data types (1) unneeded and (2) confusing. Why are they no longer needed? Data.Semigroup provides two identically named data types (First and Last). These have Semigroup instances matches what their names suggest. Additionally, SMP corrects the Monoid instance for Maybe so that it now lifts Semigroup instances instead of Monoid instances. What this means is that, assuming the following imports: import qualified Data.Monoid as M import qualified Data.Semigroup as S We have the following equivalences: M.First a === Maybe (M.First a) M.Last a === Maybe (M.Last a) When I say "equivalence", I mean that their Monoid instances have the same behavior. Their Show/Read instances are certainly different, and I’m not sure about their Ord instances. Getting back to the second reason, removing these data types would eliminate confusion. It’s strange that Semigroup is a superclass of Monoid, yet they have Data types with conflicting names defined in their respective modules. When you see the data type First, you cannot tell what someone is talking additional context. In general, base strives to avoid duplicate identifiers. The only other exception to this rule I can think of is that Bifunctor and Arrow both use the identifiers first and second. But, the situation with Data.Semigroup and Data.Monoid is higher impact since people are more likely to import these modules unqualified together. (As an aside, and the confusion I’m talking about here isn’t entirely hypothetical. I got tripped up by this when I first started using the semigroups library. I had to train myself to stop importing Data.Monoid unqualified, because it kept stealing these identifiers) Again, the two reasons are that these are no longer necessary and that they cause confusion. I would appreciate any feedback, including simple nods of agreement or disagreement. Thanks. -- -Andrew Thaddeus Martin

7 8

Re: [core libraries] Adding Backwards to base, re-export from Control.Applicative
by Baldur Blöndal 06 Jun '20

06 Jun '20

I'll CC Haskell Libraries þri., 12. nóv. 2019 kl. 22:14 skrifaði Ryan Scott <ryan.gl.scott(a)gmail.com>: > This discussion definitely belongs on the mailing list, yes. > > Ryan > > On Tue, Nov 12, 2019 at 11:59 AM chessai . <chessai1996(a)gmail.com> wrote: > >> I support this. +1 >> >> Should we copy in the libraries mailing list? >> >> On Tue, Nov 12, 2019, 5:56 AM Baldur Blöndal <baldurpet(a)gmail.com> wrote: >> >>> Is it time to move Control.Applicative.Backwards module from >>> transformers to base, and maybe re-export it from Control.Applicative. >>> >>> It's an interesting, important, simple property of Applicative that they >>> can be run backwards. >>> >>> -- >>> You received this message because you are subscribed to the Google >>> Groups "haskell-core-libraries" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to haskell-core-libraries+unsubscribe(a)googlegroups.com. >>> To view this discussion on the web visit >>> https://groups.google.com/d/msgid/haskell-core-libraries/CAK9DwL9vPwA%3DJ%3… >>> <https://groups.google.com/d/msgid/haskell-core-libraries/CAK9DwL9vPwA%3DJ%3…> >>> . >>> >> -- >> You received this message because you are subscribed to the Google Groups >> "haskell-core-libraries" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to haskell-core-libraries+unsubscribe(a)googlegroups.com. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/haskell-core-libraries/CAD34_kK6QgQ%2BQmg… >> <https://groups.google.com/d/msgid/haskell-core-libraries/CAD34_kK6QgQ%2BQmg…> >> . >> >

8 7

Remove MonadFail (ST s) instance
by Oleg Grenrus 05 Feb '20

05 Feb '20

I cannot see any justification for that instance -- | @since 4.11.0.0 instance Fail.MonadFail (ST s) where fail s = errorWithoutStackTrace s If someone wants to fail pattern matches in `ST s`, please do that explicitly. I suggest and propose the removal without any deprecation period. If someone depends on this behavior, they ought to fix they code immediately: it's straight forward compiler type-error driven refactoring. Note: compatibility package https://hackage.haskell.org/package/fail-4.9.0.0/docs/Control-Monad-Fail.ht… doesn't have that instance, so I suspect not-that many use(d) that instance. Discussion period: 2 weeks (until Monday 2019-12-09). - Oleg P.S. you might run into problems with https://gitlab.haskell.org/ghc/ghc/issues/15681 bug/miss-feature, but there's always a workaround to write code using explicit matching combinator, so it's not a show stopper.

14 23

popCount is a method of Bits, not a FiniteBits
by Oleg Grenrus 03 Dec '19

03 Dec '19

I propose to change it to be member of FiniteBits I recall, there was a proposal to remove bitSize from Bits, so it's an opportunity to introduce another small, yet breaking change at the same time. Discussion time 2 week. - Oleg

6 11

Newtype wrapper for Float/Double with sensible Eq/Ord instances
by Zemyla 02 Dec '19

02 Dec '19

There should be a newtype wrapper that wraps a RealFloat, keeps the Enum/Num/Fractional/so on instances, but gives it sensible ones for Eq and Ord, with the following order: NaN < -Inf < negative < -0 < +0 < positive < +Inf It may not belong in base, but if nothing else it definitely belongs in containers, because Set and Map depend critically on sensible instances of Ord. (Also, it should newtype derive Read and Show, so that people using them with GHCi see "fromList [(NaN, yadda), (-1.5, yadda), (2.7, blah), (+Inf, blah)]" instead of "fromList [(FloatOrd { unwrapFloat :: NaN }, yadda), ...".)

3 3

Add NonEmptyMap and NonEmptySet to containers
by V.Liepelt 25 Nov '19

25 Nov '19

Hi John, I saw your thread about non-empty containers today. Why not call them `Set1`, `Map1`, etc. in analogy to `many`/`many1` from parser combinators? I think most agree that `NonEmpty` is not a great name—I couldn’t summarise it better than Andreas: "NonEmpty what?”. Hence I always do the following: ``` import Data.List.NonEmpty (NonEmpty) import qualified Data.List.NonEmpty as List1 type List1 = NonEmpty ``` In fact I just hoogled for this and noticed that the rebase package seems to do this too. More anecdotal precedent: recently a colleague wrote a datatype isomorphic to `(a, a, [a])` and called it something not quite as ridiculous as `ListWithAtLeastTwoElements`, so I suggested `List2` and everybody involved was happy with that. Vilem

12 12

Improve Data.Functor documentation
by chessai . 24 Nov '19

24 Nov '19

A beginner learning about parametricity and the relationship between Functorial composition and Functor identity brought up a good point to me: the documentation for Bifunctor[1] and Profunctor[2] both explain the relationship between parametricity and their laws, particularly what constitutes a minimum "burden" of proof. I don't have an exact wording yet, but I think it would be a good idea to update the Functor documentation accordingly. A separate point of issue: The line "The instances of Functor for lists, Maybe and IO satisfy these laws." This statement is redundant at best when you consider that Haskellers aim for instances of Functor to be lawful. At worst it could leave beginners confused and with more questions. I could imagine someone interpreting this statement as saying there might exist some unlawful instances. I think this line should just be removed. Let me know what you think. Thanks

3 3

Applicative ((->) c) methods
by Keith 20 Nov '19

20 Nov '19

Just thinking for Applicative ((->) c) (<*) = const (*>) = flip const -- or \ _ x -> x Is it because we can rely on GHC to produce the same code from the current definitions? Also wondering why Monad uses f >>= k = \ r -> k (f r) r but Applicative uses (<*>) f g x = f x (g x) liftA2 q f g x = q (f x) (g x) Seems like if it's style/legibility, it should be consistent between (>>=) and (<*>). And if it's inlining issue, we'd want lambdas for all three. --Keith -- Sent from my phone with K-9 Mail.

4 6

Add Data.Foldable1 to base
by Oleg Grenrus 19 Nov '19

19 Nov '19

I propose adding `Foldable1` type-class into `base1`. Add Foldable1 ============= Motivation ---------- It's regularly asked whether `Foldable1` could be added to `base` (e.g. on reddit[^ref1], there're also GHC issue[^ref2] and old phabricator diff[^ref3]) Also there's work towards non-empty maps and sets[^ref4], which would benefit from `Foldable1`. As commented on reddit, `Foldable1` could be added without any pain to the `base` as it's pure addition - no modifications needed in existing modules. [^ref1]: https://www.reddit.com/r/haskell/comments/6d0vgt/could_we_have_foldable1_an… [^ref2]: https://gitlab.haskell.org/ghc/ghc/issues/13573 [^ref3]: https://phabricator.haskell.org/D4812 [^ref4]: https://github.com/haskell/containers/pull/616 Change ------ The change exist as merge request[^ref4] on gitlab.haskell.org. Importantly, this change **doesn't change** anything in other modules of `base`, except of adding a `Foldable` instance to `Data.Complex`. In particular, `foldl1` and `foldr1` in `Data.Foldable` remain partial, etc. My version of `Foldable1` class is big, so I'll comment the motivation for each member ```haskell class Foldable t => Foldable1 t where {-# MINIMAL foldMap1 | toNonEmpty | foldr1map #-} -- the defining member, like foldMap but only asking for Semigroup foldMap1 :: Semigroup m => (a -> m) -> t a -> m fold1 :: Semigroup m => t m -> m# -- strict foldMap1, cf foldMap' foldMap1' :: Semigroup m => (a -> m) -> t a -> m -- analogue of toList toNonEmpty :: t a -> NonEmpty a -- left&right, strict&non-strict folds foldr1 :: (a -> a -> a) -> t a -> a foldr1' :: (a -> a -> a) -> t a -> a foldl1 :: (a -> a -> a) -> t a -> a foldl1' :: (a -> a -> a) -> t a -> a -- these can have efficient implementation for NonEmptySet maximum1 :: forall a. Ord a => t a -> a minimum1 :: forall a. Ord a => t a -> a -- head1 have efficient implementation for NonEmpty and Tree -- last1 for symmetry head1 :: t a -> a last1 :: t a -> a -- fold variants with premap. -- Without this map, we cannot implement foldl using foldr etc. foldr1map :: (a -> b) -> (b -> b -> b) -> t a -> b foldl1'map :: (a -> b) -> (b -> b -> b) -> t a -> b foldl1map :: (a -> b) -> (b -> b -> b) -> t a -> b foldr1'map :: (a -> b) -> (b -> b -> b) -> t a -> b ``` The merge request also adds instances for everything non-empty in `base`. I propose the `Data.Foldable1` as the module name. `semigroupoids`[^ref6] uses `Data.Semigroup.Foldable`, but it's confusing; and using different name could help migration. The module contains five top-level functions, which should be self-explanatory: ```haskell intercalate1 :: (Foldable1 t, Semigroup m) => m -> t m -> m foldrM1 :: (Foldable1 t, Monad m) => (a -> a -> m a) -> t a -> m a foldlM1 :: (Foldable1 t, Monad m) => (a -> a -> m a) -> t a -> m a maximum1By :: Foldable1 t => (a -> a -> Ordering) -> t a -> a minimum1By :: Foldable1 t => (a -> a -> Ordering) -> t a -> a ``` This is less than in `Data.Semigroup.Foldable`[^ref9], as without `Apply` they don't make sense. For example: ```haskell -- needs Apply, not in Data.Foldable1 traverse1_ :: (Foldable1 t, Apply f) => (a -> f b) -> t a -> f () ``` And if we relax `Apply` to `Applicative`, we get `traverse_`. [^ref5]: https://gitlab.haskell.org/ghc/ghc/merge_requests/1973 [^ref9]: https://hackage.haskell.org/package/semigroupoids-5.3.3/docs/Data-Semigroup… [^ref5]: https://gitlab.haskell.org/ghc/ghc/merge_requests/1973 Compatibility & migration ------------------------- I drafted a compatibility package `foldable1` (github[^ref6], haddocks[^ref7]), which I hope could be maintained under github.com/haskell organization. I can act as a maintainer, with a hope that there won't be a lot of changes happening in `Data.Foldable1`. To my surprise, there's already a package with this name on Hackage[^ref8] by M Farkas-Dyck (cc'd). I hope they would donate the name to Haskell.org / CLC; the package won't have any other good use when `Data.Foldable1` is in `base`, then act as a compat package. `Data.Foldable1` contains also instances for `Lift`, `Backwards` and `Reverse` data types from `transformers`. Perfectly, the `transformers` bundled with GHC with this change would implement the instances as well. This change should propage to `transformers-compat` too. Similarly, `containers` would have an instance for `Tree` (and non-empty `Set` and `Map` when they are added). `semigroupoids` would need a bit of work, to depend on `foldable1`, yet the public changes can be kept quite minimal. I don't think that anything in reverse dependencies of `lens` will be broken by this change, if "new" `Foldable1` is re-exported from `semigroupoids`' `Data.Semigroup.Foldable`[^ref9] Other "compat" packages -- like `tagged`, `bifunctors` -- have to be dealt with case by case. For example whether they should depend on `foldable1` or other way around. [^ref6]: https://github.com/phadej/foldable1 [^ref7]: https://oleg.fi/haddocks/foldable1/ [^ref8]: https://hackage.haskell.org/package/foldable1 [^ref9]: https://hackage.haskell.org/package/semigroupoids-5.3.3/docs/Data-Semigroup… Unresolved questions -------------------- - Should we add `Bifoldable1` too. That should be trivial. - GHC-8.10 freeze is quite soon, is targeting GHC-8.12/base-4.15 more realistic?

6 12

Re: Proposal: Laws for mtl classes
by Li-yao Xia 18 Nov '19

18 Nov '19

Hello Libraries, Some time ago I proposed some laws for the most common mtl classes (State, Reader, Error): https://mail.haskell.org/pipermail/libraries/2019-April/029549.html To address some concerns about completeness I reorganized the laws into groups describing more high-level properties, and formalized them in Coq to ensure the laws are strong enough to lift themselves through common transformers (StateT, ExceptT, ContT; ReaderT and WriterT are similar to StateT, but formalizing that relationship also makes the laws interact in interesting ways). I'm open to suggestions for better ways to verify the "completeness" of the laws. However, as long there aren't any objections to the existing laws themselves, it still seems worth having some documentation earlier rather than never. In the end the actual changes to the initial proposal were quite minor. Feel free to weigh in on the following pull requests: https://github.com/haskell/mtl/pull/61 (MonadReader, MonadState) https://github.com/haskell/mtl/pull/62 (MonadError) --- # Changes 1. Three laws were added, In MonadReader, > local id = id to complete the property that local is a monoid homomorphism (rather than only semigroup); thanks to Andreas Abel for pointing out its absence in the initial proposal. > local f u = ask >>= \s -> local (\_ -> f s) u This law was necessary to verify ContT's MonadReader instance. ContT is not actually lawful, but a certain subset of it seems to be (the elements of ContT that satisfy the commutativity of ask). I did not manage to find out whether it's implied by the other laws. In MonadError, a naturality law > fmap f (catchError u h) = catchError (fmap f u) (fmap f . h) whose need arose when describing the relationship between StateT's and ReaderT's instances. 2. Another finding is the fact that, much like the laws of MonadState are equivalent to saying that 'state' is a monad morphism, the 'ask' fragment of MonadReader (which to many *is* MonadReader) can also be characterized by a monad morphism, which cannot be 'reader', as it only yields two of the 'ask' laws. 3. There were two mistakes in the original proposal. One MonadError law was too strong: > catchError (m >>= k) h = tryError m >>= either h k -- broken by StateT And local should flip the order of composition > local g . local f = local (g . f) -- wrong > local g . local f = local (f . g) -- right --- # Updated proposal ## MonadState > get >>= put = pure () > put s >> get = put s >> pure s > put s1 >> put s2 = put s2 Those three laws imply the following equations expressing that get has no side effects: > get >> m = m > get >>= \s1 -> get >>= \s2 -> k s1 s2 = get >>= \s -> k s s state must be equivalent to its default definition in terms of get and put, and conversely. Under that last condition, a property which is equivalent to the laws above is that state must be a monad morphism, from State s to m. --- ## MonadReader ask has no side effects, and produces the same result at any time. > ask >> m = m > ask >>= \s1 -> ask >>= \s2 -> k s1 s2 = ask >>= \s -> k s s > > m <*> ask = ask <**> m local f applies f to the environment produced by ask. > local f ask = f <$> ask > local f u = ask >>= \s -> local (\_ -> f s) u local is a monoid morphism from (r -> r) to (reversed) (m a -> m a) (i.e., (Endo r -> Dual (Endo (m a)))). > local id = id > local g . local f = local (f . g) local is a monad morphism from m to m. > local f (pure x) = pure x > local f (a >>= k) = local f a >>= \x -> local f (k x) reader must be equivalent to its default definition in terms of ask, and conversely. Under that last condition, a property which is equivalent to the first two laws is that reader must be a monad morphism from Reader r to m. Another property equivalent to the first three laws is that there is a monad morphism phi :: forall a. ReaderT r m a -> m a such that phi ask = ask and phi . lift = id. --- ## MonadError See also Exceptionally Monadic Error Handling, by Jan Malakhovski: https://arxiv.org/abs/1810.13430 catchError and throwError form a monad, with (>>=) interpreted as catchError and pure as throwError. > catchError (throwError e) h = h e > catchError m throwError = m > catchError (catchError m k) h = catchError m (\e -> catchError (k e) h) pure and throwError are left zeros for catchError and (>>=) respectively. > catchError (pure a) h = pure a > throwError e >>= k = throwError e catchError commutes with fmap (it is a natual transformation). > fmap f (catchError u h) = catchError (fmap f u) (fmap f . h) --- Li-yao Xia

3 3

A bug with Sum (as in Monoid)
by Dannyu NDos 12 Nov '19

12 Nov '19

Sum has bug with floating points. Current definition states +0 as the identity element, while the actual identity is -0 since +0 + -0 = +0.

5 7

Exposed # kinded variables + polykinded Prelude classes?
by Zemyla 06 Nov '19

06 Nov '19

I'm wondering if there would be a benefit, if not to the average programmer, then to the ones working on deeper/faster code, to allow some of the # kinded types (mostly Int#, Word#, Char#, Float#, Double#) to be used in Safe code, and to have typeclasses able to work with them. For instance, the definition of Show would become: class Show (a :: TYPE r) where show :: a -> String default show :: (r ~ 'LiftedRep) => a -> String show x = showsPrec 0 x "" showsPrec :: Int -> a -> ShowS default showsPrec :: (r ~ 'LiftedRep) => Int -> a -> ShowS showsPrec _ x s = show x ++ s showList :: (r ~ 'LiftedRep) => [a] -> ShowS showList ls s = showList__ shows ls s The fact that the defaults only work when the type is a LiftedRep is a nonissue, because there's only a finite number of non-lifted types we'd be defining it for. You could do the same with Eq, Ord, Num, Real, Integral, Fractional, Floating, RealFrac, RealFloat, Semigroup, Monoid, Bits, FiniteBits, and probably several others I can't think of right now. However, with the functions that return pairs, you'd need a version that returns an unboxed pair instead. Assuming you changed ReadPrec, you could even do the same with Read: newtype ReadP (a :: RuntimeRep r) = ReadP (forall b. (a -> R b) -> R b) newtype ReadPrec (a :: RuntimeRep r) = ReadPrec (Int -> ReadP a) IO, ST, and STM could be made polykinded the same way, and would open up Storable. However, how to do a definition for Monad that works for polykinded monads is an issue. I do know that RebindableSyntax handles it easily when there's just one monad that can operate on multiple kinds, though. As for which # types could be exposed, I'm thinking that Char#, Int#, Word#, Float#, Double#, and Proxy# wouldn't be able to break out of Safe code. Int64# and Word64# would work as well, and for 64-bit machines would just be type aliases for Int# and Word# respectively. For types which have functions with undefined behavior for some arguments, you can just make wrappers that check the arguments and error out for the bad values. MutVar#, MVar#, TVar#, and StableName# don't open up any functions that would be unsuitable for safe code, either. I'm pretty sure that Array# and MutableArray# would also be safe, as long as all functions were length-checked and threw errors instead of having undefined behavior. As for why this would be a desirable thing? Mostly for the sake of convenience and generality, I think. I find myself working with unboxed values from time to time, and it's a pain to always remember to use (+#) for Int# and plusWord# for Word#. In addition, having typeclasses that can return unboxed values (like a hypothetical sized# :: Sized a => a -> Int# vs sized :: Sized a => a -> Int) can improve the generated code when the code using the typeclass doesn't get specialized. The module to import these would have to explain the differences between # kinded types and * kinded ones: # values aren't lazy; they can't be top-level definitions; you can't use unboxed tuples or sums with GHCi; and with a few exceptions, you can't place them in containers (you can't have an [Int#], for instance).

5 5

Add instance Data a => Data (ZipList a) to base
by Mario 04 Nov '19

04 Nov '19

I'm surprised this is missing. All newtypes exported from Control.Applicative share the same issue, with the exception of Const.

5 4

Expired certificate for prime.haskell.org
by Simon Jakobi 02 Nov '19

02 Nov '19

Hi! I just wanted to give someone a link to the Semigroup-Monoid-proposal, but couldn't open the page in Chromium: https://prime.haskell.org/wiki/Libraries/Proposals/SemigroupMonoid There's already a short email thread regarding the issue from April on the haskell-prime mailing list: https://mail.haskell.org/pipermail/haskell-prime/2019-April/004448.html It would be nice if proposals like the SMP remained accessible! Cheers, Simon

2 3

bitSize both required and deprecated
by chessai . 01 Nov '19

01 Nov '19

All, In Data.Bits.Bits, `bitSize` has been marked deprecated for a while. but in 4.12, it was also given a default implementation. The issue is that it is in the minimal pragma as a required method. So, if I define it, I get a deprecation warning, but if I don't define it, I get a warning about missing implementations. Is this the intended behaviour? Thanks

4 3