June 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

Proposal: Strict variant of foldMap
by Andrew Martin 02 Jul '18

02 Jul '18

I propose adding another method to the Foldable typeclass: foldMap' This has the same behavior as foldMap except that it is strict in the accumulator. This can lead to considerable performance gains when the user knows that monoidal append is strict both arguments. Consider the following example (available as a gist at https://gist.github.com/andrewthad/f79b7022725532baf709514cf08c3955) {-# LANGUAGE BangPatterns #-} {-# OPTIONS_GHC -O2 #-} import Gauge import Data.Foldable import qualified Data.Set as S foldMap' :: (Monoid m, Foldable f) => (a -> m) -> f a -> m foldMap' f = foldl' (\ !acc a -> acc <> f a) mempty numbers :: [Int] numbers = [1..4000] intToSet :: Int -> S.Set Int intToSet i = S.singleton (mod i 10) main :: IO () main = defaultMain [ bench "lazy" $ whnf (foldMap intToSet) numbers , bench "strict" $ whnf (foldMap' intToSet) numbers ] Here are the results we get from running this: benchmarked lazy time 178.8 μs (176.1 μs .. 183.1 μs) 0.996 R² (0.993 R² .. 0.998 R²) mean 180.8 μs (179.1 μs .. 183.3 μs) std dev 7.242 μs (5.856 μs .. 9.304 μs) variance introduced by outliers: 20% (moderately inflated) benchmarked strict time 108.4 μs (106.1 μs .. 111.0 μs) 0.997 R² (0.996 R² .. 0.999 R²) mean 107.9 μs (107.0 μs .. 109.3 μs) std dev 3.672 μs (2.451 μs .. 6.220 μs) variance introduced by outliers: 15% (moderately inflated) These performance gains are considerable. It needs to be a method of Foldable and not just a function written using foldl' for the same reason that the lazy foldMap needs to be a method of Foldable. There are types for which the default implementation can be improved upon. This is a non-breaking change since there is a sensible default implementation. -- -Andrew Thaddeus Martin

6 8

Interaction between Dependent Haskell quantifiers and instance contexts
by Andrew Martin 29 Jun '18

29 Jun '18

In Richard Eisenberg’s PhD thesis Dependent Types in Haskell: Theory and Practice, he presents outline of what dependent types in Haskell would look like. Such an extension to GHC Haskell would replace most uses of the singleton design pattern described by the Hasochism paper (McBride). But, there is one use of singletons (the design pattern, not the library) that Eisenberg’s thesis doesn’t touch on: using pi types in typeclass instances contexts. Consider the following types from Hasochism: data Nat data Natty :: Nat -> Type class NATTY (n :: Nat) The first type is peano numbers. The second type is a singleton type. The third is a class used to implicitly provide values of type Natty in instance contexts. The same paper puts this class to good use when defining an Applicative instance for length indexed vectors: data Vec :: Nat -> Type -> Type instance NATTY n => Applicative (Vec n) To handle this with dependent types, we would need to instead write: instance pi n. Applicative (Vec n) I haven’t seen or heard any talk about whether this will be admissible. I’d be interested in hearing thoughts from the cognoscenti about any fundamental barriers (either theoretical or GHC-specific) that would prevent something like this from being admitted. I have typeclass instances like this come up fairly often in code I work on, so it’s not just a theoretical question to me. Being able to do this really would help me cut down on boilerplate. Sent from my iPhone

2 2

Proposal: Add an atomic IORef replacement operation
by David Feuer 24 Jun '18

24 Jun '18

Currently, atomicWriteIORef is implemented using atomicModifyIORef. This is not ideal: the latter allocates memory while the former shouldn't need to. In the process of writing alternative implementations, I realized that we can efficiently support an atomic operation that replaces the value in an IORef, returning the previous value. I propose that we add, to Data.IORef, a function to do so: atomicReplaceIORef :: IORef a -> a -> IO a

2 2

Call for a maintainer of protocol-buffers
by Kostiantyn Rybnikov 22 Jun '18

22 Jun '18

Hey everyone, I'm looking for a person who would become the major maintainer of the protocol-buffers package. Details here: https://github.com/k-bx/protocol-buffers/issues/64 Please comment on the issue or send me an email if you'd like to apply. Thank you

1 0

Alternative instance for Either
by Nathan van Doorn 15 Jun '18

15 Jun '18

Proposal: add: instance Monoid e => Alternative (Either e) where empty = Left mempty Left a <|> Left b = Left (a `mappend` b) Right a <|> _ = Right a _ <|> Right b = Right b instance Monoid e => MonadPlus (Either e) where ... to base. This is a reasonably obvious instance which I am pretty sure is law abiding. It'd be useful for defining a series of computations which may fail, where we only care about one success.

3 2

Package take-over: postgresql-libpq and postgresql-simple
by Oleg Grenrus 12 Jun '18

12 Jun '18

I'd like to take over of the packages postgresql-simple and postgresql-libpq. We (me and other hackage trustees) tried to contact Leon on various occasions during this year (from around GHC-8.4.1 release until recent NMU of postgresql-simple) also offering to be a co-maintainers. These are important packages for the ecosystem, so I'd like to take them over. Short term goals are - to release new major version of postgresql-simple: it accumulated many things in the master, as well as there are open PRs - find co-maintainers Best regards, Oleg Grenrus

3 2

Rename INLINABLE to SPECIALISABLE
by Daniel Cartwright 11 Jun '18

11 Jun '18

The "INLINABLE" pragma's name is misleading, it is more like "SPECIALISABLE". Consider the documentation for INLINABLE: Top-level definitions can be marked INLINABLE. myComplicatedFunction :: (Show a, Num a) => ... myComplicatedFunction = ... {-# INLINABLE myComplicatedFunction #-} This causes exactly two things to happens. 1. The function's (exact) definition is included in the interface file for the module. 2. The function will be specialised at use sites -- even across modules. Note that GHC is no more keen to inline an INLINABLE function than any other. I propose that we deprecate "INLINABLE" over a number of years at the same time as introducing "SPECIALISABLE". This wouldn't cause breakages for a long time.

6 5