- Libraries - Haskell.org

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

Taking over `data-default-*`
by Marco Zocca 08 May '18

08 May '18

Dear all, I've been increasingly relying on data-default-class, but sadly it doesn't look like it's currently maintained; there are some tickets on the github issue tracker that would need some attention. I have tried contacting the authro/current maintainer Lukas Mai (CC'd) by email but have not received an answer so far (I hope he's doing well, btw). This is my first public request for taking over the `data-default` family of packages: data-default-class data-default-instances-base data-default-instances-containers data-default-instances-dlist data-default-instances-old-locale data-default Kind regards, Marco Zocca (http://hackage.haskell.org/user/ocramz)

1 0

Proposal: add a foldable law
by Gershom B 06 May '18

06 May '18

This came up before (see the prior thread): https://mail.haskell.org/pipermail/libraries/2015-February/024943.html The thread at that time grew rather large, and only at the end did I come up with what I continue to think is a satisfactory formulation of the law. However, at that point nobody really acted to do anything about it. I would like to _formally request that the core libraries committee review_ the final version of the law as proposed, for addition to Foldable documentation: == Given a fresh newtype GenericSet = GenericSet Integer deriving (Eq, Ord), where GenericSet is otherwise fully abstract: forall (g :: forall a. f a -> Maybe a), (x :: f GenericSet). maybe True (`Foldable.elem` x) (g x) =/= False == The intuition is: "there is no general way to get an `a` out of `f a` which cannot be seen by the `Foldable` instance". The use of `GenericSet` is to handle the case of GADTs, since even parametric polymorphic functions on them may at given _already known_ types have specific behaviors. This law also works over infinite structures. It rules out "obviously wrong" instances and accepts all the instances we want to that I am aware of. My specific motivation for raising this again is that I am rather tired of people saying "well, Foldable has no laws, and it is in base, so things without laws are just fine." Foldable does a have a law we all know to obey. It just has been rather tricky to state. The above provides a decent way to state it. So we should state it. Cheers, Gershom

3 25

Monoid over reciprocal of reciprocal sum
by 박신환 06 May '18

06 May '18

e.g. Parallel resistors, serial capacitors, parallel inductors. newtype RecipSum a = RecipSum {getRecipSum :: a} instance Fractional a => Semigroup (RecipSum a) where RecipSum x <> RecipSum y = RecipSum (recip (recip x + recip y)) sconcat (x :| xs) = mconcat (x : xs). stimes n (RecipSum x) = RecipSum (x / fromIntegral n) instance Fractional a => Monoid (ResipSum a) where mempty = RecipSum (1 / 0) mconcat xs = RecipSum (recip . getSum $ foldMap (Sum . recip . getRecipSum) xs)

2 2

Monoid over XOR or XNOR, and Monoid lifted by Applicative.
by 박신환 05 May '18

05 May '18

Logical XOR is associative, also is XNOR. And they both have an identity element. Hence: newtype Even = Even {getEven :: Bool} newtype Odd = Odd {getOdd :: Bool} instance Semigroup Even where (<>) = (==) -- (==) over Bool == Logical XNOR instance Semigroup Odd where (<>) = (/=) -- (/=) over Bool == Logical XOR instance Monoid Even where mempty = True instance Monoid Odd where mempty = False So foldMap would determine the parity of the number of Trues. Also, Monoid lifted by Applicative is also Monoid. This might be useful: newtype AMonoid f a = AMonoid {getAMonoid :: f a} instance (Applicative f, Semigroup a) => Semigroup (AMonoid f a) where (<>) = liftA2 (<>) instance (Applicative f, Monoid a) => Monoid (AMonoid f a) where mempty = pure mempty

4 4