- Libraries - Haskell.org

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

07 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

Re: Monoid for ZipList
by 박신환 05 May '18

05 May '18

I aim to make the semantic consistent compared to that of other type classes (here Maybe). Also note that your instance is identical to upcoming Ap, as Ap (ZipList a). I also aim to make Monoids as diverse as possible. -----Original Message----- From: "Andrew Martin"<andrew.thaddeus(a)gmail.com> To: "박신환"<ndospark320(a)naver.com>; Cc: "Haskell Libraries"<libraries(a)haskell.org>; Sent: 2018-05-03 (목) 21:05:24 Subject: Re: Monoid for ZipList There is another possible instance. We can instead write: instance Semigroup a => Semigroup (ZipList a) where (<>) = liftA2 (<>) instance Monoid a => Monoid (ZipList a) where mempty = pure mempty This behaves differently, and it is also law-abiding.

2 2

Monoid for ZipList
by 박신환 03 May '18

03 May '18

As instance Alternative ZipList is defined since 4.11.0.0: instanceAlternativeZipListwhereempty=ZipList[]ZipList<|>ZipList=ZipList(xs++drop(lengthxs)ys) It seems perfectly fine to make Monoid for ZipList as followings: instance Semigroup a => Semigroup (ZipList a) where ZipList [] <> ZipList ys = ZipList ys ZipList xs <> ZipList [] = ZipList xs ZipList (x:xs) <> ZipList (y:ys) = ZipList (x <> y : ZipList xs <> ZipList ys) instance Semigroup a => Monoid (ZipList a) where mempty = ZipList [] Note that this semantic is similar to that of Maybe.

2 1

Instance of `Semigroup (Either a b)` needs to be eventually changed.
by 박신환 02 May '18

02 May '18

Now since `base` package version `4.11.0.0`, `Monoid` is a subclass of `Semigroup`. And that made `Monoid (Either a b)` instance impossible to exist. Current (`4.11.0.1`) instance of `Semigroup (Either a b)` (excluding `stimes`: {{{#!hs -- | @since 4.9.0.0 instance Semigroup (Either a b) where Left _ <> b = b a <> _ = a }}} No value of `Either a b` can be `mempty`. This must be eventually changed to: {{{#!hs instance Semigroup a => Semigroup (Either a b) where Left a <> Left b = Left (a <> b) Left _ <> b = b a <> _ = a }}} The former behavior can be made with `Either (Last a) b`. This makes `Monoid (Either a b)` possible: {{{#!hs instance Monoid a => Monoid (Either a b) where mempty = Left mempty }}} Also `Alternative (Either e)`: {{{#!hs instance Monoid e => Alternative (Either e) where empty = mempty (<|>) = (<>) }}}

1 0

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