May 2018 - Libraries - Haskell.org

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: eigen
by Daniel Cartwright 31 May '18

31 May '18

Hi all, I tried to contact Oleg Sidorkin who is the sole maintainer of eigen (https://hackage.haskell.org/package/eigen) at the stated email address (oleg dot sidorkin at gmail dot com), but received no repsonse. I also opened a GitHub issue at https://github.com/osidorkin/haskell-eigen/issues/17, asking to be a comaintainer for this package, and received no response. Furthermore, this Oleg seems to be mostly inactive on GitHub, with only two contributions over the last 12 months, the most recent one being in November of 2017. The last version of eigen was uploaded "by OlegSidorkin at Tue Nov 7 05:53:55 UTC 2017". The haskell bindings to eigen are currently using a deprecated version of the eigen library. I have done work at the following fork: https://github.com/haskell-numerical/eigen, where I have gotten the bindings up-to-date with the most recent stable version of eigen, as well as incorporating some changes brought up by users of the library in the issue tracker and PRs of Oleg Sidorkin's GitHub repo. I'd like to become (co-)maintainer of eigen. I have a strong interest in maintaining as well as using this library.

1 0

Re: [Haskell-cafe] ANN: primitive 0.6.4.0
by Dr.Koster 30 May '18

30 May '18

I have make some comments on reddit, but still I want to record them here: After reading the new code, I got a feeling that there're some API lacking considerations. Here is some of my personal concerns: The generalized MVar is basically useless because ST is meant to seal its state token, you won't want to add a forkST. You can argue that the atomic operations on MutVar is already added, but still I want to justify its usefulness. There're too much combinators added to PrimArray, is there a plan to port these to other arrays? If we ever provide toList operations, then I would really want it to be a good producer in base's fold-build fusion' view, it's robust and easy to implement, and folding is basically the same speed with List.fold and toList. Anyway it seems I missed the bike shedding, but still I want to thank for all the efforts, I'll try to follow new GitHub workflow more closely. Cheers Winter 发自我的iPhone ------------------ Original ------------------ From: Carter Schonwald <carter.schonwald(a)gmail.com> Date: Thu,May 31,2018 2:55 AM To: haskell-cafe <haskell-cafe(a)haskell.org>, Haskell Libraries <libraries(a)haskell.org> Subject: Re: [Haskell-cafe] ANN: primitive 0.6.4.0 This is a pretty exciting (albeit minor version) I'd like to especially thank David Feuer (treeowl ) and Andrew Martin (andrewthad) for their contributions the change log has a huge number of bug fixes relative to 0.6.2-3 also we added some new modules of features PrimArray --- unboxed nonsliceable vectors MVar -- Mvars that run in any PrimMonad augmented the Data.Primitive exports for increased consistency (the new .Ptr and .Mvar modules aren't exported in this minor version so users can easily migrate) Changes in version 0.6.4.0 Introduce Data.Primitive.PrimArray, which offers types and function for dealing with a ByteArray tagged with a phantom type variable for tracking the element type. Implement isByteArrayPinned and isMutableByteArrayPinned. Add Eq1, Ord1, Show1, and Read1 instances for Array and SmallArray. Improve the test suite. This includes having property tests for typeclasses from base such as Eq, Ord, Functor, Applicative, Monad, IsList, Monoid, Foldable, and Traversable. Fix the broken IsList instance for ByteArray. The old definition would allocate a byte array of the correct size and then leave the memory unitialized instead of writing the list elements to it. Fix the broken Functor instance for Array. The old definition would allocate an array of the correct size with thunks for erroring installed at every index. It failed to replace these thunks with the result of the function applied to the elements of the argument array. Fix the broken Applicative instances of Array and SmallArray. The old implementation of <*> for Arrayfailed to initialize some elements but correctly initialized others in the resulting Array. It is unclear what the old behavior of <*> was for SmallArray, but it was incorrect. Fix the broken Monad instances for Array and SmallArray. Fix the implementation of foldl1 in the Foldable instances for Array and SmallArray. In both cases, the old implementation simply returned the first element of the array and made no use of the other elements in the array. Fix the implementation of mconcat in the Monoid instance for SmallArray. Implement Data.Primitive.Ptr, implementations of Ptr functions that require a Prim constraint instead of a Storable constraint. Add PrimUnlifted instances for TVar and MVar. Use compareByteArrays# for the Eq and Ord instances of ByteArray when building with GHC 8.4 and newer. Add Prim instances for lots of types in Foreign.C.Types and System.Posix.Types. Reexport Data.Primitive.SmallArray and Data.Primitive.UnliftedArray from Data.Primitive. Add fold functions and map function to Data.Primitive.UnliftedArray. Add typeclass instances for IsList, Ord, and Show. Add defaultSetByteArray# and defaultSetOffAddr# to Data.Primitive.Types.

3 2

ANN: primitive 0.6.4.0
by Carter Schonwald 30 May '18

30 May '18

This is a pretty exciting (albeit minor version) I'd like to especially thank David Feuer (treeowl ) and Andrew Martin (andrewthad) for their contributions the change log has a huge number of bug fixes relative to 0.6.2-3 also we added some new modules of features PrimArray --- unboxed nonsliceable vectors MVar -- Mvars that run in any PrimMonad augmented the Data.Primitive exports for increased consistency (the new .Ptr and .Mvar modules aren't exported in this minor version so users can easily migrate) Changes in version 0.6.4.0 - Introduce Data.Primitive.PrimArray, which offers types and function for dealing with a ByteArray tagged with a phantom type variable for tracking the element type. - Implement isByteArrayPinned and isMutableByteArrayPinned. - Add Eq1, Ord1, Show1, and Read1 instances for Array and SmallArray. - Improve the test suite. This includes having property tests for typeclasses from base such as Eq, Ord, Functor, Applicative, Monad, IsList, Monoid, Foldable, and Traversable. - Fix the broken IsList instance for ByteArray. The old definition would allocate a byte array of the correct size and then leave the memory unitialized instead of writing the list elements to it. - Fix the broken Functor instance for Array. The old definition would allocate an array of the correct size with thunks for erroring installed at every index. It failed to replace these thunks with the result of the function applied to the elements of the argument array. - Fix the broken Applicative instances of Array and SmallArray. The old implementation of <*> for Arrayfailed to initialize some elements but correctly initialized others in the resulting Array. It is unclear what the old behavior of <*> was for SmallArray, but it was incorrect. - Fix the broken Monad instances for Array and SmallArray. - Fix the implementation of foldl1 in the Foldable instances for Array and SmallArray. In both cases, the old implementation simply returned the first element of the array and made no use of the other elements in the array. - Fix the implementation of mconcat in the Monoid instance for SmallArray. - Implement Data.Primitive.Ptr, implementations of Ptr functions that require a Prim constraint instead of a Storable constraint. - Add PrimUnlifted instances for TVar and MVar. - Use compareByteArrays# for the Eq and Ord instances of ByteArray when building with GHC 8.4 and newer. - Add Prim instances for lots of types in Foreign.C.Types and System.Posix.Types. - Reexport Data.Primitive.SmallArray and Data.Primitive.UnliftedArray from Data.Primitive. - Add fold functions and map function to Data.Primitive.UnliftedArray. Add typeclass instances for IsList, Ord, and Show. - Add defaultSetByteArray# and defaultSetOffAddr# to Data.Primitive.Types.

1 0

CComplex type
by Daniel Cartwright 30 May '18

30 May '18

I have recently found it useful while working with the FFI to have a CComplex data type, like so: data CComplex a = Complex {-# UNPACK #-} !a {-# UNPACK #-} !a Would something like this be a good addition to Foreign.C.Types?

2 2

Help evaluating TQueue variants
by David Feuer 25 May '18

25 May '18

I've written three related variations on TQueue (from the stm package). All three are designed to avoid the reader starvation problem described in GHC Trac 9539 [1] while limiting contention. Two are based on Okasaki's scheduled (i.e., real-time) banker's queues, while the third is based on his amortized-time banker's queue. I am hoping one or more people with programs that use TQueue heavily would be willing and able to try out these alternatives and see how they perform in their applications. I'm interested in how they compare to the current TQueue implementation, and also how they compare to each other. The queues are currently in a GitHub repository [2], but if it would be helpful I could put them up on Hackage. Thank you for your time. [1] https://ghc.haskell.org/trac/ghc/ticket/9539 [2] https://github.com/treeowl/stm-queues

1 0

Remove Semigroup and Monoid instances for Either
by Andrew Martin 24 May '18

24 May '18

The Semigroup and Monoid instances for Either have surprising behaviors. Currently, the Semigroup instance is written as: instance Semigroup (Either a b) where Left _ <> b = b a <> _ = a One would expect that the Semigroup instances for `Maybe a` and `Either () a` would have the same behaviors, but they don't. We could do better with: instance Semigroup b => Semigroup (Either a b) where (<>) = liftA2 (<>) And now the behaviors match. This generalizes the old Semigroup instance, which could be recovered with `Either a (Data.Semigroup.First b)`. For now, all I'm proposing is removing the existing Semigroup and Monoid instances for Either. I do not believe that new instances should be given immidiately, since that would be the worst kind of breaking change: one that the compiler does not error on. -Andrew Thaddeus Martin

2 2

Strictness of Semigroup instance for Maybe
by Donnacha Oisín Kidney 24 May '18

24 May '18

The current semigroup instance for Maybe looks like this: instance Semigroup a => Semigroup (Maybe a) where Nothing <> b = b a <> Nothing = a Just a <> Just b = Just (a <> b) However, it could be lazier: instance Semigroup a => Semigroup (Maybe a) where Nothing <> b = b Just a <> b = Just (maybe a (a<>) b) This causes different behaviour for Data.Semigroup.First <http://hackage.haskell.org/package/base-4.11.1.0/docs/Data-Semigroup.html#t…> and Data.Monoid.First <http://hackage.haskell.org/package/base-4.11.1.0/docs/Data-Monoid.html#t:Fi…>: >>> Data.Monoid.getFirst . foldMap pure $ [1..] Just 1 >>> fmap Data.Semigroup.getFirst . Data.Semigroup.getOption . foldMap (pure.pure) $ [1..] _|_ A different definition for `Option` gets back the old behaviour: newtype LeftOption a = LeftOption { getLeftOption :: Maybe a } instance Semigroup a => Semigroup (LeftOption a) where LeftOption Nothing <> ys = ys LeftOption (Just x) <> LeftOption ys = LeftOption (Just (maybe x (x<>) ys)) instance Semigroup a => Monoid (LeftOption a) where mempty = LeftOption Nothing mappend = (<>) >>> fmap Data.Semigroup.getFirst . getLeftOption . foldMap (LeftOption . Just . Data.Semigroup.First) $ [1..] Just 1 Is there any benefit to the extra strictness? Should this be changed? Another consideration is that the definition could equivalently be right-strict, to get the desired behaviour for Last, but I think the left-strict definition probably follows the conventions more. I originally posted this to reddit (https://www.reddit.com/r/haskell/comments/8lbzan/semigroup_maybe_too_strict/ <https://www.reddit.com/r/haskell/comments/8lbzan/semigroup_maybe_too_strict/>) and was encouraged to post it here.

7 8