April 2018 - 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

Proposal: Rename HashMap.lookupDefault to HashMap.findWithDefault
by Matt Renaud 05 Jan '19

05 Jan '19

*What* *====* Rename unordered-container's Data.HashMap.lookupDefault <https://hackage.haskell.org/package/unordered-containers-0.2.8.0/docs/Data-…> to findWithDefault. findWithDefault :: (Eq k, Hashable k) => v -> k -> HashMap k v -> v Note: There are no functionality changes, this is purely a rename. *Why* *===* This aligns the Data.HashMap API with containers' Data.Map.findWithDefault <https://hackage.haskell.org/package/containers-0.5.11.0/docs/Data-Map-Stric…> . Data.Map.findWithDefault :: Ord k => a -> k -> Map k a -> a The map APIs provided by the two packages are *almost* drop in replacement compatible if you aren't using any of the implementation specific functions (like ordering based functions from Data.Map), this change brings us one step closer. API consistency reduces the cognitive overhead when learning a new package. Having to learn different function names for the same functionality depending on which "map" implementation you're using is a poor developer experience. We chose the containers' name findWithDefault over unordered-containers' lookupDefault for two reasons: 1. Existing lookupX functions returns a Maybe value, while findX functions return a non-wrapped value. 2. The containers package ships with GHC and is a "core" package. *Pros:* *-----* - Consistent API between different "map" implementations (Data.Map, Data.IntMap, Data.HashMap). This makes switching implementations an import change. - Naming matches other similar functions (lookupX return Maybe-wrapped values) *Cons:* *-----* - API change requires users to update their code + unordered-containers has A LOT of users: 358815 total (13325 in the last 30 days) *How* *===* https://github.com/tibbe/unordered-containers/pull/176/commits/152f8818ee13… *Code Changes:* *-------------* - Rename the function in Data.HashMap.Base (and expose it from Strict and Lazy modules) - Make lookupDefault an INLINE alias of findWithDefault - Add DEPRECATION notice to lookupDefault - Bump unordered-containers version to 0.2.9.0 *Migration - Option 1:* *---------------------* *- *Announce on Haskell communication channels (haskell-cafe@, haskell-community@, #haskell on Twitter, Reddit thread, etc.) - Users of unordered-containers >= 0.2.9.0 receive warning about deprecated function - Code can be updated by find and replace: s/lookupDefault/findWithDefault/ - lookupDefault with deprecation notice remains for 1 year (subject to change) - after 1 year the lookupDefault function is removed, unordered-containers version bumped to 0.3.0.0 (major version bump due to breaking change) *Migration - Option 2:* *---------------------* - Announce on Haskell communication channels (haskell-cafe@, haskell-community@, #haskell on Twitter, Reddit thread, etc.) - Users of unordered-containers >= 0.2.9.0 receive warning about deprecated function - Code can be updated by find and replace: s/lookupDefault/findWithDefault/ - lookupDefault function is never removed *Discussion: * *===========* I would like to get some comments on this proposal. In particular: - Is the small API churn worth the increase in consistency? - Should migration option 1 (completely remove the old function) or 2 (keep old function indefinitely) be taken? We can punt on this and go with option 2 to start and revisit later if desired. I hope a decision about the proposal can be reached by 2018-02-09. Thanks!

6 10

Package take over: OneTuple
by Oleg Grenrus 12 May '18

12 May '18

Hi all, I tried to contact John Dorsey who is the sole maintainer of OneTuple [1], but the stated email address (haskell(a)colquitt.org) bounces back. The last version of OneTuple was uploaded "by JohnDorsey at Tue Mar 24 17:35:51 UTC 2009" - 9 years ago. OneTuple was working great so far, but GHC-8.4.1 / base-4.11 introduced breaking change, which affects OneTuple too: Semigroup is now a superclass of Monoid. Therefore none of OneTuple versions is GHC-8.4.1/base-4.11 compatible. I'm a Hackage Trustee [1] and also a user of OneTuple package (though not direct - it's in the transitive closure of Chart + diagrams), so I'd like to see GHC-8.4 compatible OneTuple version soon. The required changes are very small, see https://github.com/phadej/OneTuple/pull/1 or more precisely this exact commit: https://github.com/phadej/OneTuple/pull/1/commits/1dbc4d3186f707034953e1319… I'd like to become (co-)maintainer of OneTuple. I have no other plans than to keep it compiling with recent versions of GHC. Maybe I'll add NFData (from `deepseq`) instance though. Best Regards, Oleg Grenrus [1]: https://hackage.haskell.org/package/OneTuple

4 5

Remove WrappedMonad
by Ryan Scott 26 Apr '18

26 Apr '18

Oops, the was supposed to have the "Remove WrappedMonad" title—for some reason, my mail client dropped it. My apologies. Ryan S.

1 0

(no subject)
by Ryan Scott 26 Apr '18

26 Apr '18

That's not even the worst part. Even since GHC 8.0, WrappedMonad's Applicative instance doesn't define pure in terms of return (see [1]), so at the moment, it's completely unusable for DerivingVia in the way that's been proposed. If we we decide we want to keep WrappedMonad after all, we would need to once again change the semantics of this Applicative instance, since it is indeed not terribly useful the way it's currently defined. Ryan S. ----- [1] https://ghc.haskell.org/trac/ghc/ticket/13876

1 0

Remove WrappedMonad
by Andrew Martin 26 Apr '18

26 Apr '18

Control.Applicative features a type named WrappedMonad that is used to recover an Applicative instance from a Monad instance. However, since GHC 7.10, it hasn't been possible to write an Monad instance without an Applicative instance. Consequently, this type is useless (with one caveat below). I propose removing this type. Trac Ticket: https://ghc.haskell.org/trac/ghc/ticket/15027 GitHub PR: https://github.com/ghc/ghc/pull/129 On the PR, David Feuer suggests that the type may have some utility depending on whether the monad-of-no-return proposal is accepted (and also on whether DerivingVia is accepted, but this one seems more sure). If Monad keeps return as a typeclass method, then DerivingVia could be used to produce an Applicative instance from a Monad instance. If anyone knows the status of this proposal, that could be helpful. This aside, all indication of approval or disapproval of this proposal are welcome. Also, I'd really love to know if anyone is even using this type. -- -Andrew Thaddeus Martin

4 7

Name for unary unboxed one-tuple
by Simon Peyton Jones 25 Apr '18

25 Apr '18

Dear Libraries Committee Some time ago Andrew Martin asked you<https://mail.haskell.org/pipermail/libraries/2018-January/028419.html> what the name of the unary unboxed one-tuple type and data constructor should be. The thread ran for a while, but you never came to a conclusion. Can we nail this one? You’ll see on Trac #14673<https://ghc.haskell.org/trac/ghc/ticket/14673#comment:19> that chessai wants me to decide 😊. But it should really be you. To me, there seems to be something of a consensus around Solo#. Simon PS: actually I think Andrew may have addressed libraries@ rather than core-libraries-committee@ by mistake.

5 9

primitive library
by Simon Peyton Jones 23 Apr '18

23 Apr '18

Andrew, David I've seen a lot of traffic about the primitive library, in which you two are playing a leading role. Clearly something interesting is going on, but I have not been paying enough attention to work out what. Maybe lots of unrelated things? Maybe a handful of closely related things? Would you consider putting out a summary (to libraries and ghc-devs) to give an overview of the main threads, and any driving motivations. Why has all this blown up now? Meanwhile, thank you for being so active. Simon

3 3

Proposal: Export (#.) and (.#) from Data.Coerce
by Daniel Cartwright 22 Apr '18

22 Apr '18

(#.) :: Coercible b c => (b -> c) -> (a -> b) -> (a -> c) (#.) _ = coerce {-# INLINE (#.) #-} (.#) :: Coercible a b => (b -> c) -> (a -> b) -> (a -> c) (.#) f _ = coerce f {-# INLINE (.#) #-} The first of these is exported from Data.Functor.Util, and used in many places inside of base for efficiency over '.' (compose), However no module in base actually exports these. I have recently been using Data.Coerce more frequently and think it would be useful to go ahead and export these from somewhere in base. For convenience, I will paste the note about (#.) from Data.Functor.Util: "Note [Function coercion] ~~~~~~~~~~~~~~~~~~~~~~~ Several functions here use (#.) instead of (.) to avoid potential efficiency problems relating to #7542. The problem, in a nutshell: If N is a newtype constructor, then N x will always have the same representation as x (something similar applies for a newtype deconstructor). However, if f is a function, N . f = \x -> N (f x) This looks almost the same as f, but the eta expansion lifts it--the lhs could be _|_, but the rhs never is. This can lead to very inefficient code. Thus we steal a technique from Shachaf and Edward Kmett and adapt it to the current (rather clean) setting. Instead of using N . f, we use N #. f, which is just coerce f `asTypeOf` (N . f) That is, we just *pretend* that f has the right type, and thanks to the safety of coerce, the type checker guarantees that nothing really goes wrong. We still have to be a bit careful, though: remember that #. completely ignores the *value* of its left operand. "

6 6