From fumiexcel at gmail.com Fri May 3 02:56:05 2019
From: fumiexcel at gmail.com (Fumiaki Kinoshita)
Date: Fri, 3 May 2019 11:56:05 +0900
Subject: Proposal: give a field name to Data.Ord.Down
Message-ID:
It's awkward to write a lambda to unwrap this kind of wrappers. I propose
newtype Down a = Down { getDown :: a }
with the Show/Read instances as if they didn't have named fields.
The same goes for Control.Arrow.ArrowMonad, although I'm not sure about its
usefulness...
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From davean at xkcd.com Fri May 3 03:13:03 2019
From: davean at xkcd.com (davean)
Date: Thu, 2 May 2019 23:13:03 -0400
Subject: Proposal: give a field name to Data.Ord.Down
In-Reply-To:
References:
Message-ID:
I have needed this many times.
On Thu, May 2, 2019 at 10:56 PM Fumiaki Kinoshita
wrote:
> It's awkward to write a lambda to unwrap this kind of wrappers. I propose
>
> newtype Down a = Down { getDown :: a }
>
> with the Show/Read instances as if they didn't have named fields.
>
> The same goes for Control.Arrow.ArrowMonad, although I'm not sure about
> its usefulness...
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From tanuki at gmail.com Fri May 3 18:39:10 2019
From: tanuki at gmail.com (Theodore Lief Gannon)
Date: Fri, 3 May 2019 11:39:10 -0700
Subject: Proposal: give a field name to Data.Ord.Down
In-Reply-To:
References:
Message-ID:
I just added `Down` to the RIO prelude, and the absence of a deconstructor
was my #1 concern about doing so. It invites another package to provide an
alternative, and we avoid including things with actively competing
implementations. I'd much rather see this handled in `base`.
(I'd rather have it named `unDown`, so as not to steal the name `getDown`
from the heroes who will pair it with `getFunky`. But that's a lesser
concern.)
On Thu, May 2, 2019 at 8:13 PM davean wrote:
> I have needed this many times.
>
> On Thu, May 2, 2019 at 10:56 PM Fumiaki Kinoshita
> wrote:
>
>> It's awkward to write a lambda to unwrap this kind of wrappers. I propose
>>
>> newtype Down a = Down { getDown :: a }
>>
>> with the Show/Read instances as if they didn't have named fields.
>>
>> The same goes for Control.Arrow.ArrowMonad, although I'm not sure about
>> its usefulness...
>> _______________________________________________
>> Libraries mailing list
>> Libraries at haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>>
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From ekmett at gmail.com Sat May 4 07:28:58 2019
From: ekmett at gmail.com (Edward Kmett)
Date: Sat, 4 May 2019 17:28:58 +1000
Subject: Proposal: give a field name to Data.Ord.Down
In-Reply-To:
References:
Message-ID:
+1 from me, with no preference between getDown and runDown
-Edward
> On May 3, 2019, at 1:13 PM, davean wrote:
>
> I have needed this many times.
>
>> On Thu, May 2, 2019 at 10:56 PM Fumiaki Kinoshita wrote:
>> It's awkward to write a lambda to unwrap this kind of wrappers. I propose
>>
>> newtype Down a = Down { getDown :: a }
>>
>> with the Show/Read instances as if they didn't have named fields.
>>
>> The same goes for Control.Arrow.ArrowMonad, although I'm not sure about its usefulness...
>> _______________________________________________
>> Libraries mailing list
>> Libraries at haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From zemyla at gmail.com Sat May 4 08:16:59 2019
From: zemyla at gmail.com (Zemyla)
Date: Sat, 4 May 2019 03:16:59 -0500
Subject: Proposal: give a field name to Data.Ord.Down
In-Reply-To:
References:
Message-ID:
+1 from me, but the field name should be "up".
On Sat, May 4, 2019, 02:29 Edward Kmett wrote:
> +1 from me, with no preference between getDown and runDown
>
> -Edward
>
> On May 3, 2019, at 1:13 PM, davean wrote:
>
> I have needed this many times.
>
> On Thu, May 2, 2019 at 10:56 PM Fumiaki Kinoshita
> wrote:
>
>> It's awkward to write a lambda to unwrap this kind of wrappers. I propose
>>
>> newtype Down a = Down { getDown :: a }
>>
>> with the Show/Read instances as if they didn't have named fields.
>>
>> The same goes for Control.Arrow.ArrowMonad, although I'm not sure about
>> its usefulness...
>> _______________________________________________
>> Libraries mailing list
>> Libraries at haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>>
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From eacameron at gmail.com Sat May 4 14:08:29 2019
From: eacameron at gmail.com (Elliot Cameron)
Date: Sat, 4 May 2019 10:08:29 -0400
Subject: Proposal: give a field name to Data.Ord.Down
In-Reply-To:
References:
Message-ID:
I can getDown with this. +1
On Sat, May 4, 2019, 4:17 AM Zemyla wrote:
> +1 from me, but the field name should be "up".
>
> On Sat, May 4, 2019, 02:29 Edward Kmett wrote:
>
>> +1 from me, with no preference between getDown and runDown
>>
>> -Edward
>>
>> On May 3, 2019, at 1:13 PM, davean wrote:
>>
>> I have needed this many times.
>>
>> On Thu, May 2, 2019 at 10:56 PM Fumiaki Kinoshita
>> wrote:
>>
>>> It's awkward to write a lambda to unwrap this kind of wrappers. I propose
>>>
>>> newtype Down a = Down { getDown :: a }
>>>
>>> with the Show/Read instances as if they didn't have named fields.
>>>
>>> The same goes for Control.Arrow.ArrowMonad, although I'm not sure about
>>> its usefulness...
>>> _______________________________________________
>>> Libraries mailing list
>>> Libraries at haskell.org
>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>>>
>> _______________________________________________
>> Libraries mailing list
>> Libraries at haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>>
>> _______________________________________________
>> Libraries mailing list
>> Libraries at haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>>
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From carter.schonwald at gmail.com Sat May 4 18:11:24 2019
From: carter.schonwald at gmail.com (Carter Schonwald)
Date: Sat, 4 May 2019 14:11:24 -0400
Subject: Proposal: give a field name to Data.Ord.Down
In-Reply-To:
References:
Message-ID:
+1
On Sat, May 4, 2019 at 10:08 AM Elliot Cameron wrote:
> I can getDown with this. +1
>
> On Sat, May 4, 2019, 4:17 AM Zemyla wrote:
>
>> +1 from me, but the field name should be "up".
>>
>> On Sat, May 4, 2019, 02:29 Edward Kmett wrote:
>>
>>> +1 from me, with no preference between getDown and runDown
>>>
>>> -Edward
>>>
>>> On May 3, 2019, at 1:13 PM, davean wrote:
>>>
>>> I have needed this many times.
>>>
>>> On Thu, May 2, 2019 at 10:56 PM Fumiaki Kinoshita
>>> wrote:
>>>
>>>> It's awkward to write a lambda to unwrap this kind of wrappers. I
>>>> propose
>>>>
>>>> newtype Down a = Down { getDown :: a }
>>>>
>>>> with the Show/Read instances as if they didn't have named fields.
>>>>
>>>> The same goes for Control.Arrow.ArrowMonad, although I'm not sure about
>>>> its usefulness...
>>>> _______________________________________________
>>>> Libraries mailing list
>>>> Libraries at haskell.org
>>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>>>>
>>> _______________________________________________
>>> Libraries mailing list
>>> Libraries at haskell.org
>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>>>
>>> _______________________________________________
>>> Libraries mailing list
>>> Libraries at haskell.org
>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>>>
>> _______________________________________________
>> Libraries mailing list
>> Libraries at haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>>
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From chessai1996 at gmail.com Sat May 4 20:20:30 2019
From: chessai1996 at gmail.com (chessai .)
Date: Sat, 4 May 2019 16:20:30 -0400
Subject: Proposal: give a field name to Data.Ord.Down
In-Reply-To:
References:
Message-ID:
+1
On Thu, May 2, 2019, 10:56 PM Fumiaki Kinoshita wrote:
> It's awkward to write a lambda to unwrap this kind of wrappers. I propose
>
> newtype Down a = Down { getDown :: a }
>
> with the Show/Read instances as if they didn't have named fields.
>
> The same goes for Control.Arrow.ArrowMonad, although I'm not sure about
> its usefulness...
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From george at wils.online Sun May 5 01:49:09 2019
From: george at wils.online (George Wilson)
Date: Sun, 5 May 2019 11:49:09 +1000
Subject: Proposal: give a field name to Data.Ord.Down
In-Reply-To:
References:
Message-ID:
+1
On Sun., 5 May 2019, 06:21 chessai ., wrote:
> +1
>
> On Thu, May 2, 2019, 10:56 PM Fumiaki Kinoshita
> wrote:
>
>> It's awkward to write a lambda to unwrap this kind of wrappers. I propose
>>
>> newtype Down a = Down { getDown :: a }
>>
>> with the Show/Read instances as if they didn't have named fields.
>>
>> The same goes for Control.Arrow.ArrowMonad, although I'm not sure about
>> its usefulness...
>> _______________________________________________
>> Libraries mailing list
>> Libraries at haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>>
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From andrew.thaddeus at gmail.com Sun May 5 18:11:02 2019
From: andrew.thaddeus at gmail.com (Andrew Martin)
Date: Sun, 5 May 2019 14:11:02 -0400
Subject: Proposal: give a field name to Data.Ord.Down
In-Reply-To:
References:
Message-ID:
+1. I do prefer getDown as the field name, but anything is better than nothing.
Sent from my iPhone
> On May 4, 2019, at 9:49 PM, George Wilson wrote:
>
> +1
>
>> On Sun., 5 May 2019, 06:21 chessai ., wrote:
>> +1
>>
>>> On Thu, May 2, 2019, 10:56 PM Fumiaki Kinoshita wrote:
>>> It's awkward to write a lambda to unwrap this kind of wrappers. I propose
>>>
>>> newtype Down a = Down { getDown :: a }
>>>
>>> with the Show/Read instances as if they didn't have named fields.
>>>
>>> The same goes for Control.Arrow.ArrowMonad, although I'm not sure about its usefulness...
>>> _______________________________________________
>>> Libraries mailing list
>>> Libraries at haskell.org
>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>> _______________________________________________
>> Libraries mailing list
>> Libraries at haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From vanessa.mchale at iohk.io Wed May 8 01:56:50 2019
From: vanessa.mchale at iohk.io (Vanessa McHale)
Date: Tue, 7 May 2019 20:56:50 -0500
Subject: Proposal: add foldMapA to Data.Foldable or Control.Applicative
Message-ID:
It's relatively easy to define foldMapA, viz.
foldMapA :: (Monoid b, Traversable t, Applicative f) => (a -> f b) -> t
a -> f b
foldMapA = (fmap fold .) . traverse
I've used found it useful once so far:
http://hackage.haskell.org/package/dir-traverse-0.2.0.0/docs/src/System.Directory.Recursive.html#local-6989586621679024835
Cheers,
Vanessa McHale
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL:
From lanablack at amok.cc Wed May 8 02:04:17 2019
From: lanablack at amok.cc (Lana Black)
Date: Wed, 08 May 2019 02:04:17 +0000
Subject: Proposal: add foldMapA to Data.Foldable or Control.Applicative
In-Reply-To:
References:
Message-ID: <9FEB27EF-F0AE-465C-A263-A5B105DCAA7C@amok.cc>
On May 8, 2019 1:56:50 AM UTC, Vanessa McHale wrote:
>It's relatively easy to define foldMapA, viz.
>
>foldMapA :: (Monoid b, Traversable t, Applicative f) => (a -> f b) ->
>t
>a -> f b
>foldMapA = (fmap fold .) . traverse
>
>I've used found it useful once so far:
>http://hackage.haskell.org/package/dir-traverse-0.2.0.0/docs/src/System.Directory.Recursive.html#local-6989586621679024835
>
>Cheers,
>Vanessa McHale
Yes, please! I have found it useful on numerous occasions.
From david.feuer at gmail.com Wed May 8 02:49:10 2019
From: david.feuer at gmail.com (David Feuer)
Date: Tue, 7 May 2019 22:49:10 -0400
Subject: Proposal: add foldMapA to Data.Foldable or Control.Applicative
In-Reply-To:
References:
Message-ID:
On Tue, May 7, 2019, 9:57 PM Vanessa McHale wrote:
> It's relatively easy to define foldMapA, viz.
>
> foldMapA :: (Monoid b, Traversable t, Applicative f) => (a -> f b) -> t
> a -> f b
> foldMapA = (fmap fold .) . traverse
>
That's a bit hard for me to read. Let's rewrite it a bit:
foldMapA f = fmap fold . traverse f
Looking at it more plainly, I can see that this traverses the container
with f, producing a bunch of values, then maps under the functor to fold
them. That smells funny. Let's fix it.
fold
:: (Foldable f, Monoid a)
=> f a -> a
fold = foldMap id
foldMapDefault
:: (Traversable t, Monoid m)
=> (a -> m) -> t a -> m
foldMapDefault f = getConst . traverse (Const . f)
so
foldMapA f = fmap (getConst . traverse Const) . traverse f
By the functor composition law, we can write
foldMapA f = fmap getConst . fmap (traverse Const) . traverse f
By the traversable composition law,
foldMapA f = fmap getConst . getCompose . traverse (Compose . fmap Const
. f)
This isn't looking so hot yet, but bear with me. fmap getConst doesn't
actually do anything (it's operationally the same as fmap id = id), so we
can ignore it). The functor we're traversing in is
Compose f (Const b) (t x)
where x can be anything. How does this functor behave?
pure a
= Compose (pure (pure a))
= Compose (pure (Const mempty))
liftA2 f (Compose x) (Compose y)
= Compose (liftA2 (liftA2 f) x y)
= Compose (liftA2 (\(Const p) (Const q) -> p <> q) x y)
Whew! There are a lot of newtype wrappers, but let's ignore them. Does this
Applicative instance look familiar? It should. It's operationally the same
as the Monoid instance for Data.Monoid.Ap! So we can weaken Traversable to
Foldable, and write
foldMapA
:: (Monoid b, Foldable t, Applicative f)
=> (a -> f b) -> t a -> f b
foldMapA f = getAp . foldMap (Ap . f)
But now it's so simple I'm not sure we need to define it anymore.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From david.feuer at gmail.com Wed May 8 02:59:00 2019
From: david.feuer at gmail.com (David Feuer)
Date: Tue, 7 May 2019 22:59:00 -0400
Subject: Proposal: add foldMapA to Data.Foldable or Control.Applicative
In-Reply-To:
References:
Message-ID:
TLDR: if you ever see anything that looks like
fmap (foldMap f) . traverse g
then you should generally rewrite it to
getAp . foldMap (Ap . fmap f . g)
In this case, f = id, so you just need
getAp . foldMap (Ap . g)
On Tue, May 7, 2019, 10:49 PM David Feuer wrote:
> On Tue, May 7, 2019, 9:57 PM Vanessa McHale
> wrote:
>
>> It's relatively easy to define foldMapA, viz.
>>
>> foldMapA :: (Monoid b, Traversable t, Applicative f) => (a -> f b) -> t
>> a -> f b
>> foldMapA = (fmap fold .) . traverse
>>
>
> That's a bit hard for me to read. Let's rewrite it a bit:
>
> foldMapA f = fmap fold . traverse f
>
> Looking at it more plainly, I can see that this traverses the container
> with f, producing a bunch of values, then maps under the functor to fold
> them. That smells funny. Let's fix it.
>
> fold
> :: (Foldable f, Monoid a)
> => f a -> a
> fold = foldMap id
>
> foldMapDefault
> :: (Traversable t, Monoid m)
> => (a -> m) -> t a -> m
> foldMapDefault f = getConst . traverse (Const . f)
>
> so
>
> foldMapA f = fmap (getConst . traverse Const) . traverse f
>
> By the functor composition law, we can write
>
> foldMapA f = fmap getConst . fmap (traverse Const) . traverse f
>
> By the traversable composition law,
>
> foldMapA f = fmap getConst . getCompose . traverse (Compose . fmap Const
> . f)
>
> This isn't looking so hot yet, but bear with me. fmap getConst doesn't
> actually do anything (it's operationally the same as fmap id = id), so we
> can ignore it). The functor we're traversing in is
>
> Compose f (Const b) (t x)
>
> where x can be anything. How does this functor behave?
>
> pure a
> = Compose (pure (pure a))
> = Compose (pure (Const mempty))
>
> liftA2 f (Compose x) (Compose y)
> = Compose (liftA2 (liftA2 f) x y)
> = Compose (liftA2 (\(Const p) (Const q) -> p <> q) x y)
>
> Whew! There are a lot of newtype wrappers, but let's ignore them. Does
> this Applicative instance look familiar? It should. It's operationally the
> same as the Monoid instance for Data.Monoid.Ap! So we can weaken
> Traversable to Foldable, and write
>
> foldMapA
> :: (Monoid b, Foldable t, Applicative f)
> => (a -> f b) -> t a -> f b
> foldMapA f = getAp . foldMap (Ap . f)
>
> But now it's so simple I'm not sure we need to define it anymore.
>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From david.feuer at gmail.com Wed May 8 03:37:12 2019
From: david.feuer at gmail.com (David Feuer)
Date: Tue, 7 May 2019 23:37:12 -0400
Subject: Proposal: add foldMapA to Data.Foldable or Control.Applicative
In-Reply-To:
References:
Message-ID:
My second to last comment was potentially non-optimal in unusual cases. If
fmap is sufficiently expensive for the functor in question, and f is not
id, then you might want to use
import Data.Functor.Coyoneda
lowerCoyoneda . getAp . foldMap (Ap . fmap f . liftCoyoneda . g)
This is pretty similar to the composition of foldMap and traverse, but it
doesn't have a Traversable constraint.
On Tue, May 7, 2019, 10:59 PM David Feuer wrote:
> TLDR: if you ever see anything that looks like
>
> fmap (foldMap f) . traverse g
>
> then you should generally rewrite it to
>
> getAp . foldMap (Ap . fmap f . g)
>
> In this case, f = id, so you just need
>
> getAp . foldMap (Ap . g)
>
> On Tue, May 7, 2019, 10:49 PM David Feuer wrote:
>
>> On Tue, May 7, 2019, 9:57 PM Vanessa McHale
>> wrote:
>>
>>> It's relatively easy to define foldMapA, viz.
>>>
>>> foldMapA :: (Monoid b, Traversable t, Applicative f) => (a -> f b) -> t
>>> a -> f b
>>> foldMapA = (fmap fold .) . traverse
>>>
>>
>> That's a bit hard for me to read. Let's rewrite it a bit:
>>
>> foldMapA f = fmap fold . traverse f
>>
>> Looking at it more plainly, I can see that this traverses the container
>> with f, producing a bunch of values, then maps under the functor to fold
>> them. That smells funny. Let's fix it.
>>
>> fold
>> :: (Foldable f, Monoid a)
>> => f a -> a
>> fold = foldMap id
>>
>> foldMapDefault
>> :: (Traversable t, Monoid m)
>> => (a -> m) -> t a -> m
>> foldMapDefault f = getConst . traverse (Const . f)
>>
>> so
>>
>> foldMapA f = fmap (getConst . traverse Const) . traverse f
>>
>> By the functor composition law, we can write
>>
>> foldMapA f = fmap getConst . fmap (traverse Const) . traverse f
>>
>> By the traversable composition law,
>>
>> foldMapA f = fmap getConst . getCompose . traverse (Compose . fmap
>> Const . f)
>>
>> This isn't looking so hot yet, but bear with me. fmap getConst doesn't
>> actually do anything (it's operationally the same as fmap id = id), so we
>> can ignore it). The functor we're traversing in is
>>
>> Compose f (Const b) (t x)
>>
>> where x can be anything. How does this functor behave?
>>
>> pure a
>> = Compose (pure (pure a))
>> = Compose (pure (Const mempty))
>>
>> liftA2 f (Compose x) (Compose y)
>> = Compose (liftA2 (liftA2 f) x y)
>> = Compose (liftA2 (\(Const p) (Const q) -> p <> q) x y)
>>
>> Whew! There are a lot of newtype wrappers, but let's ignore them. Does
>> this Applicative instance look familiar? It should. It's operationally the
>> same as the Monoid instance for Data.Monoid.Ap! So we can weaken
>> Traversable to Foldable, and write
>>
>> foldMapA
>> :: (Monoid b, Foldable t, Applicative f)
>> => (a -> f b) -> t a -> f b
>> foldMapA f = getAp . foldMap (Ap . f)
>>
>> But now it's so simple I'm not sure we need to define it anymore.
>>
>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From isaace71295 at gmail.com Wed May 8 03:49:48 2019
From: isaace71295 at gmail.com (Isaac Elliott)
Date: Wed, 8 May 2019 13:49:48 +1000
Subject: Proposal: add foldMapA to Data.Foldable or Control.Applicative
In-Reply-To:
References:
Message-ID:
I've previously suggested similar things, like:
allA :: (Applicative f, Foldable t) => (a -> f Bool) -> t a -> f Bool
allA f = fmap getAll . getAp . foldMap (Ap . fmap All . f)
I think such functions are very convenient.
On Wed, 8 May 2019, 1:37 pm David Feuer, wrote:
> My second to last comment was potentially non-optimal in unusual cases. If
> fmap is sufficiently expensive for the functor in question, and f is not
> id, then you might want to use
>
> import Data.Functor.Coyoneda
>
> lowerCoyoneda . getAp . foldMap (Ap . fmap f . liftCoyoneda . g)
>
> This is pretty similar to the composition of foldMap and traverse, but it
> doesn't have a Traversable constraint.
>
> On Tue, May 7, 2019, 10:59 PM David Feuer wrote:
>
>> TLDR: if you ever see anything that looks like
>>
>> fmap (foldMap f) . traverse g
>>
>> then you should generally rewrite it to
>>
>> getAp . foldMap (Ap . fmap f . g)
>>
>> In this case, f = id, so you just need
>>
>> getAp . foldMap (Ap . g)
>>
>> On Tue, May 7, 2019, 10:49 PM David Feuer wrote:
>>
>>> On Tue, May 7, 2019, 9:57 PM Vanessa McHale
>>> wrote:
>>>
>>>> It's relatively easy to define foldMapA, viz.
>>>>
>>>> foldMapA :: (Monoid b, Traversable t, Applicative f) => (a -> f b) -> t
>>>> a -> f b
>>>> foldMapA = (fmap fold .) . traverse
>>>>
>>>
>>> That's a bit hard for me to read. Let's rewrite it a bit:
>>>
>>> foldMapA f = fmap fold . traverse f
>>>
>>> Looking at it more plainly, I can see that this traverses the container
>>> with f, producing a bunch of values, then maps under the functor to fold
>>> them. That smells funny. Let's fix it.
>>>
>>> fold
>>> :: (Foldable f, Monoid a)
>>> => f a -> a
>>> fold = foldMap id
>>>
>>> foldMapDefault
>>> :: (Traversable t, Monoid m)
>>> => (a -> m) -> t a -> m
>>> foldMapDefault f = getConst . traverse (Const . f)
>>>
>>> so
>>>
>>> foldMapA f = fmap (getConst . traverse Const) . traverse f
>>>
>>> By the functor composition law, we can write
>>>
>>> foldMapA f = fmap getConst . fmap (traverse Const) . traverse f
>>>
>>> By the traversable composition law,
>>>
>>> foldMapA f = fmap getConst . getCompose . traverse (Compose . fmap
>>> Const . f)
>>>
>>> This isn't looking so hot yet, but bear with me. fmap getConst doesn't
>>> actually do anything (it's operationally the same as fmap id = id), so we
>>> can ignore it). The functor we're traversing in is
>>>
>>> Compose f (Const b) (t x)
>>>
>>> where x can be anything. How does this functor behave?
>>>
>>> pure a
>>> = Compose (pure (pure a))
>>> = Compose (pure (Const mempty))
>>>
>>> liftA2 f (Compose x) (Compose y)
>>> = Compose (liftA2 (liftA2 f) x y)
>>> = Compose (liftA2 (\(Const p) (Const q) -> p <> q) x y)
>>>
>>> Whew! There are a lot of newtype wrappers, but let's ignore them. Does
>>> this Applicative instance look familiar? It should. It's operationally the
>>> same as the Monoid instance for Data.Monoid.Ap! So we can weaken
>>> Traversable to Foldable, and write
>>>
>>> foldMapA
>>> :: (Monoid b, Foldable t, Applicative f)
>>> => (a -> f b) -> t a -> f b
>>> foldMapA f = getAp . foldMap (Ap . f)
>>>
>>> But now it's so simple I'm not sure we need to define it anymore.
>>>
>>>> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From david.feuer at gmail.com Wed May 8 04:02:49 2019
From: david.feuer at gmail.com (David Feuer)
Date: Wed, 8 May 2019 00:02:49 -0400
Subject: Proposal: add foldMapA to Data.Foldable or Control.Applicative
In-Reply-To:
References:
Message-ID:
On Tue, May 7, 2019 at 11:49 PM Isaac Elliott wrote:
> I've previously suggested similar things, like:
>
> allA :: (Applicative f, Foldable t) => (a -> f Bool) -> t a -> f Bool
> allA f = fmap getAll . getAp . foldMap (Ap . fmap All . f)
>
> I think such functions are very convenient.
>
I think your allA is arguably better-justified than foldMapA because the
simple
implementation you demonstrate could run into trouble if fmap is expensive.
Better:
allA :: (Applicative f, Foldable t) => (a -> f Bool) -> t a -> f Bool
allA f = getFall . foldMap (Fall . f)
newtype Fall f = Fall {getFall :: f Bool}
instance Applicative f => Semigroup (Fall f) where
Fall x <> Fall y = Fall $ liftA2 (&&) x y
instance Applicative f => Monoid (Fall f) where
mempty = Fall (pure True)
I keep wondering if there's some nice way (short of Coyoneda or similar) to
generalize this
sort of thing. I haven't thought of one yet.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From b at chreekat.net Wed May 8 04:12:28 2019
From: b at chreekat.net (Bryan Richter)
Date: Wed, 8 May 2019 07:12:28 +0300
Subject: Proposal: add foldMapA to Data.Foldable or Control.Applicative
In-Reply-To:
References:
Message-ID:
Hi David,
At the risk of invoking the gods of Language Blorp, I will note that as a
working programmer I know exactly what Applicative, Traversable, and Monoid
are (from Vanessa's original proposal), but the unfortunately-named getAp
is something I will only learn about begrudgingly.
What you consider "so simple we don't need to define it" took a rather
lengthy email to describe. Are you sure it's not worth actually defining?
If nothing else, the next time someone searches Hoogle for a function
matching its type signature, perhaps it will be an opportunity for someone
like me to peer beneath the hood and learn something new.
On Wed, 8 May 2019, 5.59 David Feuer, wrote:
> TLDR: if you ever see anything that looks like
>
> fmap (foldMap f) . traverse g
>
> then you should generally rewrite it to
>
> getAp . foldMap (Ap . fmap f . g)
>
> In this case, f = id, so you just need
>
> getAp . foldMap (Ap . g)
>
> On Tue, May 7, 2019, 10:49 PM David Feuer wrote:
>
>> On Tue, May 7, 2019, 9:57 PM Vanessa McHale
>> wrote:
>>
>>> It's relatively easy to define foldMapA, viz.
>>>
>>> foldMapA :: (Monoid b, Traversable t, Applicative f) => (a -> f b) -> t
>>> a -> f b
>>> foldMapA = (fmap fold .) . traverse
>>>
>>
>> That's a bit hard for me to read. Let's rewrite it a bit:
>>
>> foldMapA f = fmap fold . traverse f
>>
>> Looking at it more plainly, I can see that this traverses the container
>> with f, producing a bunch of values, then maps under the functor to fold
>> them. That smells funny. Let's fix it.
>>
>> fold
>> :: (Foldable f, Monoid a)
>> => f a -> a
>> fold = foldMap id
>>
>> foldMapDefault
>> :: (Traversable t, Monoid m)
>> => (a -> m) -> t a -> m
>> foldMapDefault f = getConst . traverse (Const . f)
>>
>> so
>>
>> foldMapA f = fmap (getConst . traverse Const) . traverse f
>>
>> By the functor composition law, we can write
>>
>> foldMapA f = fmap getConst . fmap (traverse Const) . traverse f
>>
>> By the traversable composition law,
>>
>> foldMapA f = fmap getConst . getCompose . traverse (Compose . fmap
>> Const . f)
>>
>> This isn't looking so hot yet, but bear with me. fmap getConst doesn't
>> actually do anything (it's operationally the same as fmap id = id), so we
>> can ignore it). The functor we're traversing in is
>>
>> Compose f (Const b) (t x)
>>
>> where x can be anything. How does this functor behave?
>>
>> pure a
>> = Compose (pure (pure a))
>> = Compose (pure (Const mempty))
>>
>> liftA2 f (Compose x) (Compose y)
>> = Compose (liftA2 (liftA2 f) x y)
>> = Compose (liftA2 (\(Const p) (Const q) -> p <> q) x y)
>>
>> Whew! There are a lot of newtype wrappers, but let's ignore them. Does
>> this Applicative instance look familiar? It should. It's operationally the
>> same as the Monoid instance for Data.Monoid.Ap! So we can weaken
>> Traversable to Foldable, and write
>>
>> foldMapA
>> :: (Monoid b, Foldable t, Applicative f)
>> => (a -> f b) -> t a -> f b
>> foldMapA f = getAp . foldMap (Ap . f)
>>
>> But now it's so simple I'm not sure we need to define it anymore.
>>
>>> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From david.feuer at gmail.com Wed May 8 04:36:07 2019
From: david.feuer at gmail.com (David Feuer)
Date: Wed, 8 May 2019 00:36:07 -0400
Subject: Proposal: add foldMapA to Data.Foldable or Control.Applicative
In-Reply-To:
References:
Message-ID:
On Wed, May 8, 2019, 12:12 AM Bryan Richter ** wrote:
> Hi David,
>
> At the risk of invoking the gods of Language Blorp, I will note that as a
> working programmer I know exactly what Applicative, Traversable, and Monoid
> are (from Vanessa's original proposal), but the unfortunately-named getAp
> is something I will only learn about begrudgingly.
>
That seems unfortunate. Learning to use such types is pretty useful. I'd
recommend that every Haskell programmer get to know all the types in
Data.Monoid and come to an understanding of what they're good for.
>
> What you consider "so simple we don't need to define it" took a rather
> lengthy email to describe. Are you sure it's not worth actually defining?
>
So ... that long post was about trying to prove what I intuitively thought
*must* be true. In the end, I wasn't quite able to finish the proof, but I
did at least manage to convince myself that my intuition was correct. It's
true that this sort of intuition takes a certain amount of time to develop.
In the case of a really important operation, yeah, we should package it up.
But is this operation important enough? I'm not really convinced yet.
If nothing else, the next time someone searches Hoogle for a function
> matching its type signature, perhaps it will be an opportunity for someone
> like me to peer beneath the hood and learn something new.
>
That's valid. But ... there are lots of opportunities for that sort of
thing already. Is it worth the API clutter to add another one?
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From kovanikov at gmail.com Thu May 9 03:50:27 2019
From: kovanikov at gmail.com (Dmitriy Kovanikov)
Date: Thu, 9 May 2019 11:50:27 +0800
Subject: Proposal: add foldMapA to Data.Foldable or Control.Applicative
In-Reply-To:
References:
Message-ID:
I would like to add one more point of reference to the discussion. The
`foldMapA` function is also implemented in the `relude` alternative prelude:
http://hackage.haskell.org/package/relude-0.5.0/docs/src/Relude.Foldable.Fold.html#foldMapA
And the implementation already uses `Ap` and `getAp` as was discussed here.
Previous implementation used `fmap` and `traverse` but it was changed to a
more efficient one.
One possible improvement: instead of current implementation
> foldMapA f = getAp . foldMap (Ap . f)
It can be slightly more efficient (I guess) by using #. operator to coerce
newtypes
> foldMapA f = getAp #. foldMap (Ap . f)
The implementation in `relude` also contains recommended order of variables
under `forall`. After using `foldMapA` in production for a while we've
figured out in what order variables should go to resolve most often
ambiguities via TypeApplication.
On Wed, May 8, 2019 at 12:36 PM David Feuer wrote:
> On Wed, May 8, 2019, 12:12 AM Bryan Richter **** wrote:
>
>> Hi David,
>>
>> At the risk of invoking the gods of Language Blorp, I will note that as a
>> working programmer I know exactly what Applicative, Traversable, and Monoid
>> are (from Vanessa's original proposal), but the unfortunately-named getAp
>> is something I will only learn about begrudgingly.
>>
>
> That seems unfortunate. Learning to use such types is pretty useful. I'd
> recommend that every Haskell programmer get to know all the types in
> Data.Monoid and come to an understanding of what they're good for.
>
>>
>
>> What you consider "so simple we don't need to define it" took a rather
>> lengthy email to describe. Are you sure it's not worth actually defining?
>>
>
> So ... that long post was about trying to prove what I intuitively thought
> *must* be true. In the end, I wasn't quite able to finish the proof, but I
> did at least manage to convince myself that my intuition was correct. It's
> true that this sort of intuition takes a certain amount of time to develop.
> In the case of a really important operation, yeah, we should package it up.
> But is this operation important enough? I'm not really convinced yet.
>
>
> If nothing else, the next time someone searches Hoogle for a function
>> matching its type signature, perhaps it will be an opportunity for someone
>> like me to peer beneath the hood and learn something new.
>>
>
> That's valid. But ... there are lots of opportunities for that sort of
> thing already. Is it worth the API clutter to add another one?
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From vanessa.mchale at iohk.io Thu May 9 14:28:14 2019
From: vanessa.mchale at iohk.io (Vanessa McHale)
Date: Thu, 9 May 2019 09:28:14 -0500
Subject: Proposal: add foldMapA to Data.Foldable or Control.Applicative
In-Reply-To:
References:
Message-ID:
I appreciate the more efficient version, but I do not consider a package
like relude to be an alternative to base (due to dependencies, maintenance).
On 5/8/19 10:50 PM, Dmitriy Kovanikov wrote:
> I would like to add one more point of reference to the discussion. The
> `foldMapA` function is also implemented in the `relude` alternative
> prelude:
>
> http://hackage.haskell.org/package/relude-0.5.0/docs/src/Relude.Foldable.Fold.html#foldMapA
>
> And the implementation already uses `Ap` and `getAp` as was discussed
> here. Previous implementation used `fmap` and `traverse` but it was
> changed to a more efficient one.
>
> One possible improvement: instead of current implementation
>
> > foldMapA f = getAp . foldMap (Ap . f)
>
> It can be slightly more efficient (I guess) by using #. operator to
> coerce newtypes
>
> > foldMapA f = getAp #. foldMap (Ap . f)
>
> The implementation in `relude` also contains recommended order of
> variables under `forall`. After using `foldMapA` in production for a
> while we've figured out in what order variables should go to resolve
> most often ambiguities via TypeApplication.
>
> On Wed, May 8, 2019 at 12:36 PM David Feuer > wrote:
>
> On Wed, May 8, 2019, 12:12 AM Bryan Richter **** > wrote:
>
> Hi David,
>
> At the risk of invoking the gods of Language Blorp, I will
> note that as a working programmer I know exactly what
> Applicative, Traversable, and Monoid are (from Vanessa's
> original proposal), but the unfortunately-named getAp is
> something I will only learn about begrudgingly.
>
>
> That seems unfortunate. Learning to use such types is pretty
> useful. I'd recommend that every Haskell programmer get to know
> all the types in Data.Monoid and come to an understanding of what
> they're good for.
>
>
> What you consider "so simple we don't need to define it" took
> a rather lengthy email to describe. Are you sure it's not
> worth actually defining?
>
>
> So ... that long post was about trying to prove what I intuitively
> thought *must* be true. In the end, I wasn't quite able to finish
> the proof, but I did at least manage to convince myself that my
> intuition was correct. It's true that this sort of intuition takes
> a certain amount of time to develop. In the case of a really
> important operation, yeah, we should package it up. But is this
> operation important enough? I'm not really convinced yet.
>
>
> If nothing else, the next time someone searches Hoogle for a
> function matching its type signature, perhaps it will be an
> opportunity for someone like me to peer beneath the hood and
> learn something new.
>
>
> That's valid. But ... there are lots of opportunities for that
> sort of thing already. Is it worth the API clutter to add another one?
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>
>
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL:
From carter.schonwald at gmail.com Thu May 9 14:35:16 2019
From: carter.schonwald at gmail.com (Carter Schonwald)
Date: Thu, 9 May 2019 10:35:16 -0400
Subject: Proposal: add foldMapA to Data.Foldable or Control.Applicative
In-Reply-To:
References:
Message-ID:
Its a complicated landscape, and we're still learning.
if a new combinator is hard to write:
a) how do we help educate folks into seeing it as an easy combinator
b) what are the with/without fusion cost models of different
implementations?
c) is it useful?
I’m slightly inclined to support inclusion.
One question I have is whether it’s definable via foldmap itself ?
On Wed, May 8, 2019 at 12:36 AM David Feuer wrote:
> On Wed, May 8, 2019, 12:12 AM Bryan Richter **** wrote:
>
>> Hi David,
>>
>> At the risk of invoking the gods of Language Blorp, I will note that as a
>> working programmer I know exactly what Applicative, Traversable, and Monoid
>> are (from Vanessa's original proposal), but the unfortunately-named getAp
>> is something I will only learn about begrudgingly.
>>
>
> That seems unfortunate. Learning to use such types is pretty useful. I'd
> recommend that every Haskell programmer get to know all the types in
> Data.Monoid and come to an understanding of what they're good for.
>
>>
>
>> What you consider "so simple we don't need to define it" took a rather
>> lengthy email to describe. Are you sure it's not worth actually defining?
>>
>
> So ... that long post was about trying to prove what I intuitively thought
> *must* be true. In the end, I wasn't quite able to finish the proof, but I
> did at least manage to convince myself that my intuition was correct. It's
> true that this sort of intuition takes a certain amount of time to develop.
> In the case of a really important operation, yeah, we should package it up.
> But is this operation important enough? I'm not really convinced yet.
>
>
> If nothing else, the next time someone searches Hoogle for a function
>> matching its type signature, perhaps it will be an opportunity for someone
>> like me to peer beneath the hood and learn something new.
>>
>
> That's valid. But ... there are lots of opportunities for that sort of
> thing already. Is it worth the API clutter to add another one?
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From david.feuer at gmail.com Thu May 9 14:36:34 2019
From: david.feuer at gmail.com (David Feuer)
Date: Thu, 9 May 2019 10:36:34 -0400
Subject: Proposal: add foldMapA to Data.Foldable or Control.Applicative
In-Reply-To:
References:
Message-ID:
Vanessa, it's very common for discussions about adding things to base (or
containers, etc) to get into how those matters have been handled elsewhere.
Many people think that it's better to pull ideas into base only after
they've demonstrated their value elsewhere. Dmitriy's comment should
definitely not be taken as criticism of your proposal.
Dmitriy, there's no question that (#.) or similar should be used rather
than (.). I didn't mention that because it doesn't seem to bear on the
overall question of whether the function should be added, and I didn't want
to confuse other participants with semi-obscure coercion operators.
On Thu, May 9, 2019, 10:28 AM Vanessa McHale wrote:
> I appreciate the more efficient version, but I do not consider a package
> like relude to be an alternative to base (due to dependencies, maintenance).
> On 5/8/19 10:50 PM, Dmitriy Kovanikov wrote:
>
> I would like to add one more point of reference to the discussion. The
> `foldMapA` function is also implemented in the `relude` alternative
> prelude:
>
>
> http://hackage.haskell.org/package/relude-0.5.0/docs/src/Relude.Foldable.Fold.html#foldMapA
>
> And the implementation already uses `Ap` and `getAp` as was discussed
> here. Previous implementation used `fmap` and `traverse` but it was changed
> to a more efficient one.
>
> One possible improvement: instead of current implementation
>
> > foldMapA f = getAp . foldMap (Ap . f)
>
> It can be slightly more efficient (I guess) by using #. operator to coerce
> newtypes
>
> > foldMapA f = getAp #. foldMap (Ap . f)
>
> The implementation in `relude` also contains recommended order of
> variables under `forall`. After using `foldMapA` in production for a while
> we've figured out in what order variables should go to resolve most often
> ambiguities via TypeApplication.
>
> On Wed, May 8, 2019 at 12:36 PM David Feuer wrote:
>
>> On Wed, May 8, 2019, 12:12 AM Bryan Richter **** wrote:
>>
>>> Hi David,
>>>
>>> At the risk of invoking the gods of Language Blorp, I will note that as
>>> a working programmer I know exactly what Applicative, Traversable, and
>>> Monoid are (from Vanessa's original proposal), but the unfortunately-named
>>> getAp is something I will only learn about begrudgingly.
>>>
>>
>> That seems unfortunate. Learning to use such types is pretty useful. I'd
>> recommend that every Haskell programmer get to know all the types in
>> Data.Monoid and come to an understanding of what they're good for.
>>
>>
>>> What you consider "so simple we don't need to define it" took a rather
>>> lengthy email to describe. Are you sure it's not worth actually defining?
>>>
>>
>> So ... that long post was about trying to prove what I intuitively
>> thought *must* be true. In the end, I wasn't quite able to finish the
>> proof, but I did at least manage to convince myself that my intuition was
>> correct. It's true that this sort of intuition takes a certain amount of
>> time to develop. In the case of a really important operation, yeah, we
>> should package it up. But is this operation important enough? I'm not
>> really convinced yet.
>>
>>
>> If nothing else, the next time someone searches Hoogle for a function
>>> matching its type signature, perhaps it will be an opportunity for someone
>>> like me to peer beneath the hood and learn something new.
>>>
>>
>> That's valid. But ... there are lots of opportunities for that sort of
>> thing already. Is it worth the API clutter to add another one?
>> _______________________________________________
>> Libraries mailing list
>> Libraries at haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>>
>
> _______________________________________________
> Libraries mailing listLibraries at haskell.orghttp://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From david.feuer at gmail.com Thu May 9 14:37:53 2019
From: david.feuer at gmail.com (David Feuer)
Date: Thu, 9 May 2019 10:37:53 -0400
Subject: Proposal: add foldMapA to Data.Foldable or Control.Applicative
In-Reply-To:
References:
Message-ID:
Carter, I already showed that it is, and Dmitriy already refined that
definition.
On Thu, May 9, 2019, 10:35 AM Carter Schonwald
wrote:
> Its a complicated landscape, and we're still learning.
>
> if a new combinator is hard to write:
> a) how do we help educate folks into seeing it as an easy combinator
> b) what are the with/without fusion cost models of different
> implementations?
> c) is it useful?
>
> I’m slightly inclined to support inclusion.
>
> One question I have is whether it’s definable via foldmap itself ?
>
> On Wed, May 8, 2019 at 12:36 AM David Feuer wrote:
>
>> On Wed, May 8, 2019, 12:12 AM Bryan Richter **** wrote:
>>
>>> Hi David,
>>>
>>> At the risk of invoking the gods of Language Blorp, I will note that as
>>> a working programmer I know exactly what Applicative, Traversable, and
>>> Monoid are (from Vanessa's original proposal), but the unfortunately-named
>>> getAp is something I will only learn about begrudgingly.
>>>
>>
>> That seems unfortunate. Learning to use such types is pretty useful. I'd
>> recommend that every Haskell programmer get to know all the types in
>> Data.Monoid and come to an understanding of what they're good for.
>>
>>>
>>
>>> What you consider "so simple we don't need to define it" took a rather
>>> lengthy email to describe. Are you sure it's not worth actually defining?
>>>
>>
>> So ... that long post was about trying to prove what I intuitively
>> thought *must* be true. In the end, I wasn't quite able to finish the
>> proof, but I did at least manage to convince myself that my intuition was
>> correct. It's true that this sort of intuition takes a certain amount of
>> time to develop. In the case of a really important operation, yeah, we
>> should package it up. But is this operation important enough? I'm not
>> really convinced yet.
>>
>>
>> If nothing else, the next time someone searches Hoogle for a function
>>> matching its type signature, perhaps it will be an opportunity for someone
>>> like me to peer beneath the hood and learn something new.
>>>
>>
>> That's valid. But ... there are lots of opportunities for that sort of
>> thing already. Is it worth the API clutter to add another one?
>> _______________________________________________
>> Libraries mailing list
>> Libraries at haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From kovanikov at gmail.com Thu May 9 14:47:21 2019
From: kovanikov at gmail.com (Dmitriy Kovanikov)
Date: Thu, 9 May 2019 22:47:21 +0800
Subject: Proposal: add foldMapA to Data.Foldable or Control.Applicative
In-Reply-To:
References:
Message-ID:
Vanessa, I'm not proposing to replace base with relude in libraries like
dir-traverse. Sorry if I wasn't clear enough, I didn't mean to introduce
more confusion.
I don't use `relude` in my libraries as well because I prefer a low amount
of external dependencies and I usually use alternative prelude only in big
applications.
As David mentioned, I indeed just wanted to show one more place where
`foldMapA` is introduced because it's not in base. Having `foldMapA` in
base will make `relude` even better because it will have even fewer custom
things in favour of mere reexports from base. I also think that if some
data type / function has already been in some alternative prelude for some
time, it could be a good addition to base.
On Thu, May 9, 2019 at 10:28 PM Vanessa McHale
wrote:
> I appreciate the more efficient version, but I do not consider a package
> like relude to be an alternative to base (due to dependencies, maintenance).
> On 5/8/19 10:50 PM, Dmitriy Kovanikov wrote:
>
> I would like to add one more point of reference to the discussion. The
> `foldMapA` function is also implemented in the `relude` alternative
> prelude:
>
>
> http://hackage.haskell.org/package/relude-0.5.0/docs/src/Relude.Foldable.Fold.html#foldMapA
>
> And the implementation already uses `Ap` and `getAp` as was discussed
> here. Previous implementation used `fmap` and `traverse` but it was changed
> to a more efficient one.
>
> One possible improvement: instead of current implementation
>
> > foldMapA f = getAp . foldMap (Ap . f)
>
> It can be slightly more efficient (I guess) by using #. operator to coerce
> newtypes
>
> > foldMapA f = getAp #. foldMap (Ap . f)
>
> The implementation in `relude` also contains recommended order of
> variables under `forall`. After using `foldMapA` in production for a while
> we've figured out in what order variables should go to resolve most often
> ambiguities via TypeApplication.
>
> On Wed, May 8, 2019 at 12:36 PM David Feuer wrote:
>
>> On Wed, May 8, 2019, 12:12 AM Bryan Richter **** wrote:
>>
>>> Hi David,
>>>
>>> At the risk of invoking the gods of Language Blorp, I will note that as
>>> a working programmer I know exactly what Applicative, Traversable, and
>>> Monoid are (from Vanessa's original proposal), but the unfortunately-named
>>> getAp is something I will only learn about begrudgingly.
>>>
>>
>> That seems unfortunate. Learning to use such types is pretty useful. I'd
>> recommend that every Haskell programmer get to know all the types in
>> Data.Monoid and come to an understanding of what they're good for.
>>
>>
>>> What you consider "so simple we don't need to define it" took a rather
>>> lengthy email to describe. Are you sure it's not worth actually defining?
>>>
>>
>> So ... that long post was about trying to prove what I intuitively
>> thought *must* be true. In the end, I wasn't quite able to finish the
>> proof, but I did at least manage to convince myself that my intuition was
>> correct. It's true that this sort of intuition takes a certain amount of
>> time to develop. In the case of a really important operation, yeah, we
>> should package it up. But is this operation important enough? I'm not
>> really convinced yet.
>>
>>
>> If nothing else, the next time someone searches Hoogle for a function
>>> matching its type signature, perhaps it will be an opportunity for someone
>>> like me to peer beneath the hood and learn something new.
>>>
>>
>> That's valid. But ... there are lots of opportunities for that sort of
>> thing already. Is it worth the API clutter to add another one?
>> _______________________________________________
>> Libraries mailing list
>> Libraries at haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>>
>
> _______________________________________________
> Libraries mailing listLibraries at haskell.orghttp://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From parsonsmatt at gmail.com Thu May 9 15:09:13 2019
From: parsonsmatt at gmail.com (Matt)
Date: Thu, 9 May 2019 09:09:13 -0600
Subject: Proposal: add foldMapA to Data.Foldable or Control.Applicative
In-Reply-To:
References:
Message-ID:
I've personally defined `foldMapA` in at least three private projects, and
I've one-off written it probably over a dozen times. Each time I've used
something like `fmap k . traverse f` where `k` is one of `mconcat`, `fold`,
`join`, etc. I appreciate the subtle discussion on the implementation for
performance and I think it'd be awesome to have this defined in `base`.
Matt Parsons
On Tue, May 7, 2019 at 10:36 PM David Feuer wrote:
> On Wed, May 8, 2019, 12:12 AM Bryan Richter **** wrote:
>
>> Hi David,
>>
>> At the risk of invoking the gods of Language Blorp, I will note that as a
>> working programmer I know exactly what Applicative, Traversable, and Monoid
>> are (from Vanessa's original proposal), but the unfortunately-named getAp
>> is something I will only learn about begrudgingly.
>>
>
> That seems unfortunate. Learning to use such types is pretty useful. I'd
> recommend that every Haskell programmer get to know all the types in
> Data.Monoid and come to an understanding of what they're good for.
>
>>
>
>> What you consider "so simple we don't need to define it" took a rather
>> lengthy email to describe. Are you sure it's not worth actually defining?
>>
>
> So ... that long post was about trying to prove what I intuitively thought
> *must* be true. In the end, I wasn't quite able to finish the proof, but I
> did at least manage to convince myself that my intuition was correct. It's
> true that this sort of intuition takes a certain amount of time to develop.
> In the case of a really important operation, yeah, we should package it up.
> But is this operation important enough? I'm not really convinced yet.
>
>
> If nothing else, the next time someone searches Hoogle for a function
>> matching its type signature, perhaps it will be an opportunity for someone
>> like me to peer beneath the hood and learn something new.
>>
>
> That's valid. But ... there are lots of opportunities for that sort of
> thing already. Is it worth the API clutter to add another one?
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From chessai1996 at gmail.com Thu May 9 17:49:50 2019
From: chessai1996 at gmail.com (chessai .)
Date: Thu, 9 May 2019 13:49:50 -0400
Subject: Proposal: add foldMapA to Data.Foldable or Control.Applicative
In-Reply-To:
References:
Message-ID:
I've also defined this in multiple of my own projects/codebases, and I
provided it as a motivation for introducing Data.Monoid.Ap in the first
place.
I'm +1 on the inclusion of foldMapA.
On Thu, May 9, 2019, 11:10 AM Matt wrote:
> I've personally defined `foldMapA` in at least three private projects, and
> I've one-off written it probably over a dozen times. Each time I've used
> something like `fmap k . traverse f` where `k` is one of `mconcat`, `fold`,
> `join`, etc. I appreciate the subtle discussion on the implementation for
> performance and I think it'd be awesome to have this defined in `base`.
>
> Matt Parsons
>
>
> On Tue, May 7, 2019 at 10:36 PM David Feuer wrote:
>
>> On Wed, May 8, 2019, 12:12 AM Bryan Richter **** wrote:
>>
>>> Hi David,
>>>
>>> At the risk of invoking the gods of Language Blorp, I will note that as
>>> a working programmer I know exactly what Applicative, Traversable, and
>>> Monoid are (from Vanessa's original proposal), but the unfortunately-named
>>> getAp is something I will only learn about begrudgingly.
>>>
>>
>> That seems unfortunate. Learning to use such types is pretty useful. I'd
>> recommend that every Haskell programmer get to know all the types in
>> Data.Monoid and come to an understanding of what they're good for.
>>
>>>
>>
>>> What you consider "so simple we don't need to define it" took a rather
>>> lengthy email to describe. Are you sure it's not worth actually defining?
>>>
>>
>> So ... that long post was about trying to prove what I intuitively
>> thought *must* be true. In the end, I wasn't quite able to finish the
>> proof, but I did at least manage to convince myself that my intuition was
>> correct. It's true that this sort of intuition takes a certain amount of
>> time to develop. In the case of a really important operation, yeah, we
>> should package it up. But is this operation important enough? I'm not
>> really convinced yet.
>>
>>
>> If nothing else, the next time someone searches Hoogle for a function
>>> matching its type signature, perhaps it will be an opportunity for someone
>>> like me to peer beneath the hood and learn something new.
>>>
>>
>> That's valid. But ... there are lots of opportunities for that sort of
>> thing already. Is it worth the API clutter to add another one?
>> _______________________________________________
>> Libraries mailing list
>> Libraries at haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>>
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From vanessa.mchale at iohk.io Thu May 9 18:56:38 2019
From: vanessa.mchale at iohk.io (Vanessa McHale)
Date: Thu, 9 May 2019 13:56:38 -0500
Subject: Proposal: add foldMapA to Data.Foldable or Control.Applicative
In-Reply-To:
References:
Message-ID:
Interestingly, in the case of dir-traverse,
foldMapA = (fmap fold .) . traverse
ends up being faster than
foldMapA f = getAp . foldMap (Ap . f)
...which I did not expect. I suppose we should benchmark this before
adding it to base.
Cheers,
Vanessa McHale
On 5/9/19 12:49 PM, chessai . wrote:
> I've also defined this in multiple of my own projects/codebases, and I
> provided it as a motivation for introducing Data.Monoid.Ap in the
> first place.
>
> I'm +1 on the inclusion of foldMapA.
>
> On Thu, May 9, 2019, 11:10 AM Matt > wrote:
>
> I've personally defined `foldMapA` in at least three private
> projects, and I've one-off written it probably over a dozen times.
> Each time I've used something like `fmap k . traverse f` where `k`
> is one of `mconcat`, `fold`, `join`, etc. I appreciate the subtle
> discussion on the implementation for performance and I think it'd
> be awesome to have this defined in `base`.
>
> Matt Parsons
>
>
> On Tue, May 7, 2019 at 10:36 PM David Feuer > wrote:
>
> On Wed, May 8, 2019, 12:12 AM Bryan Richter **** > wrote:
>
> Hi David,
>
> At the risk of invoking the gods of Language Blorp, I will
> note that as a working programmer I know exactly what
> Applicative, Traversable, and Monoid are (from Vanessa's
> original proposal), but the unfortunately-named getAp is
> something I will only learn about begrudgingly.
>
>
> That seems unfortunate. Learning to use such types is pretty
> useful. I'd recommend that every Haskell programmer get to
> know all the types in Data.Monoid and come to an understanding
> of what they're good for.
>
>
> What you consider "so simple we don't need to define it"
> took a rather lengthy email to describe. Are you sure it's
> not worth actually defining?
>
>
> So ... that long post was about trying to prove what I
> intuitively thought *must* be true. In the end, I wasn't quite
> able to finish the proof, but I did at least manage to
> convince myself that my intuition was correct. It's true that
> this sort of intuition takes a certain amount of time to
> develop. In the case of a really important operation, yeah, we
> should package it up. But is this operation important enough?
> I'm not really convinced yet.
>
>
> If nothing else, the next time someone searches Hoogle for
> a function matching its type signature, perhaps it will be
> an opportunity for someone like me to peer beneath the
> hood and learn something new.
>
>
> That's valid. But ... there are lots of opportunities for that
> sort of thing already. Is it worth the API clutter to add
> another one?
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>
>
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL:
From david.feuer at gmail.com Thu May 9 19:22:07 2019
From: david.feuer at gmail.com (David Feuer)
Date: Thu, 9 May 2019 15:22:07 -0400
Subject: Proposal: add foldMapA to Data.Foldable or Control.Applicative
In-Reply-To:
References:
**