<div dir="auto">Set is a Foldable, but not a Functor or Traversable. So the precedent is there.</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Jun 1, 2020, 05:16 Andreas Abel <<a href="mailto:andreas.abel@ifi.lmu.de">andreas.abel@ifi.lmu.de</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> > We have Functor, Foldable, and Traversable instances<br>
<br>
Yes, and good so, since I use these type classes every day.  Haven't <br>
ever used Bifoldable, though.  This is why I question the need.<br>
<br>
In general, I am a proponent of fat libraries, thus, I am not strongly <br>
against such an addition, especially if it is only a light-weight <br>
overlay over foldrWithKey.<br>
<br>
I guess since Bifoldable is in base already (wasn't aware of this), the <br>
ship has already sailed on discussing its wide-spread usability.  I <br>
remain unconvinced though.<br>
<br>
What weights in for me is that Map does not have sensible Bifunctor or <br>
Bitraversable instances (since manipulating the keys does not preserve <br>
the tree structure in general).  Thus, we cannot make the chord <br>
(Bi)functor/(Bi)foldable/(Bi)traversable complete.<br>
<br>
My take would be to add Bifoldable only on public demand.<br>
But let's hear other opinions as well.<br>
<br>
--Andreas<br>
<br>
<br>
On 2020-05-31 18:49, Joseph C. Sible wrote:<br>
> I don't find this argument convincing. We have Functor, Foldable, and<br>
> Traversable instances even though mapWithKey, foldrWithKey, and<br>
> traverseWithKey give more control than they do. We have a Semigroup<br>
> instance even though unionWith and unionWithKey give more control than<br>
> it does.<br>
> <br>
> As for the implementation, I'd be fine with changing it to be in terms<br>
> of foldrWithKey. I just care that we have this instance somehow.<br>
> <br>
> Joseph C. Sible<br>
> <br>
> On Sun, May 31, 2020 at 6:23 AM Andreas Abel <<a href="mailto:andreas.abel@ifi.lmu.de" target="_blank" rel="noreferrer">andreas.abel@ifi.lmu.de</a>> wrote:<br>
>><br>
>> Do we have any need for Bifoldable?  We have<br>
>><br>
>>     foldrWithKey :: (k -> a -> b -> b) -> b -> Map k a -> b<br>
>>     foldlWithKey :: (a -> k -> b -> a) -> a -> Map k b -> a<br>
>><br>
>> These functions seem to give more control of how the fold happens.<br>
>><br>
>> And if we'd want Bifoldable, shouldn't the Bifoldable instance be<br>
>> implemented in terms of just foldrWithKey?  Why have a recursive<br>
>> implementation?<br>
>><br>
>> Personally, I consider Bifoldable a fringe class, as I would hope that<br>
>> in general with fusion, I can just go via bimap and ordinary Foldable<br>
>> without much penalty.<br>
>><br>
>> On 2020-05-31 07:20, George Wilson wrote:<br>
>>> If you have a non-commutative monoid, the result could easily be<br>
>>> different than you expect. eg. if you think it would do all keys and<br>
>>> then all values, rather than interleaving (which is I assume the most<br>
>>> efficient to implement).<br>
>>> Despite that I'm still +1 on this.<br>
>>><br>
>>> On Sun, 31 May 2020 at 14:59, Joseph C. Sible <<a href="mailto:josephcsible@gmail.com" target="_blank" rel="noreferrer">josephcsible@gmail.com</a>> wrote:<br>
>>>><br>
>>>> I'll admit I don't have a strong use case for this. I was just looking<br>
>>>> at instances and noticed that these seemed to be a weird omission,<br>
>>>> since there was an obvious definition. But I also don't think it's<br>
>>>> confusing at all. Since (,), Set, and HashSet are Foldable, and (,)<br>
>>>> and (,,) x are Bifoldable, it seems only logical to have Map and<br>
>>>> HashMap be Bifoldable too. What exactly would be confusing about any<br>
>>>> of these?<br>
>>>><br>
>>>> Joseph C. Sible<br>
>>>><br>
>>>> On Sat, May 30, 2020 at 8:33 PM David Feuer <<a href="mailto:david.feuer@gmail.com" target="_blank" rel="noreferrer">david.feuer@gmail.com</a>> wrote:<br>
>>>>><br>
>>>>> Let me take that back. I forgot how weird Bifoldable and Bitraversable are for product types and product-like types. Is this instance actually useful for anything, or is it mostly confusing?<br>
>>>>><br>
>>>>> On Mon, Apr 13, 2020, 9:46 PM David Feuer <<a href="mailto:david.feuer@gmail.com" target="_blank" rel="noreferrer">david.feuer@gmail.com</a>> wrote:<br>
>>>>>><br>
>>>>>> I would go as far as to say we don't need to continue the proposal process here. We're doing it.<br>
>>>>>><br>
>>>>>> On Mon, Apr 13, 2020, 9:44 PM David Feuer <<a href="mailto:david.feuer@gmail.com" target="_blank" rel="noreferrer">david.feuer@gmail.com</a>> wrote:<br>
>>>>>>><br>
>>>>>>> This seems eminently reasonable to me. We must also be sure to add one to Data.HashMap if that's missing too.<br>
>>>>>>><br>
>>>>>>> On Mon, Apr 13, 2020, 9:36 PM Joseph C. Sible <<a href="mailto:josephcsible@gmail.com" target="_blank" rel="noreferrer">josephcsible@gmail.com</a>> wrote:<br>
>>>>>>>><br>
>>>>>>>> I'd like to propose a change to the containers package: adding a<br>
>>>>>>>> Bifoldable instance to Map. I briefly mentioned this on Reddit [1] and<br>
>>>>>>>> no obvious problems were brought up. I submitted a PR implementing it<br>
>>>>>>>> [2]. This seems like an obvious and straightforward instance to me.<br>
>>>>>>>> Thoughts?<br>
>>>>>>>><br>
>>>>>>>> Joseph C. Sible<br>
>>>>>>>><br>
>>>>>>>> [1]: <a href="https://old.reddit.com/r/haskell/comments/fsgqd6/monthly_hask_anything_april_2020/fn90d6k/" rel="noreferrer noreferrer" target="_blank">https://old.reddit.com/r/haskell/comments/fsgqd6/monthly_hask_anything_april_2020/fn90d6k/</a><br>
>>>>>>>> [2]: <a href="https://github.com/haskell/containers/pull/714" rel="noreferrer noreferrer" target="_blank">https://github.com/haskell/containers/pull/714</a><br>
>>>>>>>> _______________________________________________<br>
>>>>>>>> Libraries mailing list<br>
>>>>>>>> <a href="mailto:Libraries@haskell.org" target="_blank" rel="noreferrer">Libraries@haskell.org</a><br>
>>>>>>>> <a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries" rel="noreferrer noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries</a><br>
>>>> _______________________________________________<br>
>>>> Libraries mailing list<br>
>>>> <a href="mailto:Libraries@haskell.org" target="_blank" rel="noreferrer">Libraries@haskell.org</a><br>
>>>> <a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries" rel="noreferrer noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries</a><br>
>>> _______________________________________________<br>
>>> Libraries mailing list<br>
>>> <a href="mailto:Libraries@haskell.org" target="_blank" rel="noreferrer">Libraries@haskell.org</a><br>
>>> <a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries" rel="noreferrer noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries</a><br>
>>><br>
>> _______________________________________________<br>
>> Libraries mailing list<br>
>> <a href="mailto:Libraries@haskell.org" target="_blank" rel="noreferrer">Libraries@haskell.org</a><br>
>> <a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries" rel="noreferrer noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries</a><br>
_______________________________________________<br>
Libraries mailing list<br>
<a href="mailto:Libraries@haskell.org" target="_blank" rel="noreferrer">Libraries@haskell.org</a><br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries" rel="noreferrer noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries</a><br>
</blockquote></div>