- Libraries - Haskell.org

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

Bits typeclass law for LSB
by Andrew Martin 24 May '18

24 May '18

The trac issue this is asking about is found here: https://ghc.haskell.org/trac/ghc/ticket/14839. I'm looking for any feedback from the broader community to see if the proposed law is incompatible with any important uses of Bits. The text of the trac issue is provided below: The documentation for the Bits typeclass claims: Bits are numbered from 0 with bit 0 being the least significant bit. However, there's no law specified in the typeclass that enforces this. I realized this recently because I've been adding the laws for Bits to a library of property tests I maintain: http://hackage.haskell.org/package/quickcheck-classes-0.3.3/docs/Test-Quick… In another package of mine, someone requested to add a Bits instance for a type but with the MSB considered bit 0. ( https://github.com/andrewthad/haskell-ip/issues/29) I thought this would fail to satisfy a law of Bits, but it doesn't. So at the least, I was thinking we could add the following laws to FiniteBits: countTrailingZeros (bit 0) = 0 countLeadingZeros (bit 0) = finiteBitSize undefined - 1 -- -Andrew Thaddeus Martin

1 0

Resolve name collsion of `first` and `second` by Control.Arrow and Data.Bifunctor
by 박신환 18 May '18

18 May '18

I had to import both Control.Arrow and Data.Bifunctor, and the name collision is annoying. `first` and `second` from Data.Bifunctor should be given other names. I suggest (<$<) and (>$>), respectively.

6 8

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

Proposal: Continue the displayException program
by David Feuer 09 May '18

09 May '18

Several years ago, Michael Snoyman proposed [*] that we add a displayException method to the Exception class, and that we make GHC use it in the default handler. The first part of that proposal was accepted and implemented, but the second part was not, for reasons that are not very clear to me. I would like to re-propose that we change the default exception handler to use displayException instead of Show. This seems like a much better default, and anyone who wants to do it the old way can still change the top-level handler. [*] https://mail.haskell.org/pipermail/libraries/2014-November/024176.html

3 2

Proposal: add Bounded instances for Maybe and Either
by David Feuer 09 May '18

09 May '18

We can write instance Bounded a => Bounded (Maybe a) where minBound = Nothing maxBound = Just maxBound instance (Bounded a, Bounded b) => Bounded (Either a b) where minBound = Left minBound maxBound = Right maxBound While Bounded intentionally does not have an Ord superclass, I think it's worth mentioning that these are the instances that arise naturally from the Ord instances for the types in question.

5 7