Bifoldable instance for Map

[Andreas Abel]

I think bitraverse makes some sense.  If you have a tree with two kinds 
of leaves, you can effectfully map over it.

   bitraverse
     :: Applicative f => (a -> f c) -> (b -> f d) -> t a b -> f (t c d)

Here, the tree structure stays in place.

However, bifolding is less meaningful because the ordering of elements 
in the resulting collection (monoid) is somewhat arbitrary.  This 
argument has already been raised in this thread.

In the example of maps where you have keys and values, the distinction 
between them loses its meaning when you do a bifold, and there is no 
reason why they should be ordered in a certain way in the monoid.  In 
contrast, the fold[L/R]WithKey operations bring the problem to the 
attention of the programmer.

Another angle to judge the usefulness of Bifoldable (for Data.Map) could 
be how many clients of Bifoldable there are.  How many methods that one 
would want to run on a Map have a Bifoldable constraint?

On 2020-06-02 06:39, David Feuer wrote:
> No idea. Traversing in a Biapplicative can definitely be interesting. I 
> don't know what Bifoldable or Bitraversable can do.
> 
> On Tue, Jun 2, 2020, 12:12 AM Joseph C. Sible <josephcsible at gmail.com 
> <mailto:josephcsible at gmail.com>> wrote:
> 
>     Let me turn this around: do you believe the Bifoldable class is a
>     useful abstraction at all? Are there any real types (i.e., that exist
>     in `base` or some other popular library or program, rather than made
>     up for the sake of example) that you think have a useful Bifoldable
>     instance? In other words, is your issue actually with this instance,
>     or is it really with the entire class?
> 
>     Joseph C. Sible
> 
>     On Mon, Jun 1, 2020 at 5:51 PM David Feuer <david.feuer at gmail.com
>     <mailto:david.feuer at gmail.com>> wrote:
>      >
>      > Yes, folding generally loses structure. This just seems especially
>      > egregious. Can you think of even a single function polymorphic over
>      > `Bifoldable` containers that you'd find it useful to pass a `HashMap`
>      > to?
>      >
>      > On Mon, Jun 1, 2020 at 5:34 PM Joseph C. Sible
>     <josephcsible at gmail.com <mailto:josephcsible at gmail.com>> wrote:
>      > >
>      > > Aren't you basically just saying that you lose some of the
>     structure
>      > > (namely, the knowledge that the "key" and its "value" go together)?
>      > > But doesn't every Foldable instance on a type that's more
>     complex than
>      > > a list also do that? For example, if you fold a rose tree, you lose
>      > > the knowledge of which elements came from which branches.
>      > >
>      > > (Completely unrelated: "Loost" and the names of its data
>     constructors
>      > > sound like something straight from Dr. Seuss.)
>      > >
>      > > Joseph C. Sible
>      > >
>      > > On Mon, Jun 1, 2020 at 8:28 AM David Feuer
>     <david.feuer at gmail.com <mailto:david.feuer at gmail.com>> wrote:
>      > > >
>      > > > Let me be more specific. Whereas we can get intuition for
>     Foldable from
>      > > >
>      > > >     toList :: t a -> [a]
>      > > >
>      > > > we get intuition for Bifoldable from the hypothetical
>      > > >
>      > > >     toEitherList :: t a b -> [Either a b]
>      > > >
>      > > > This seems quite reasonable for some types.
>      > > >
>      > > >     data Loost a b
>      > > >       = Nool
>      > > >       | Corns b (Loost a b)
>      > > >       | Colns a (Loost a b)
>      > > >
>      > > > But for something like
>      > > >
>      > > >     newtype Plist a b
>      > > >       = PNil
>      > > >       | PCons a b (PList a b)
>      > > >
>      > > > it feels awfully strange. Independent parts of the structure
>     just get lumped together.
> 
> 
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>