Re: Bifoldable instance for Map

2 Jun 2020

      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 mailto:josephcsible@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 mailto:david.feuer@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
    mailto:josephcsible@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
    mailto:david.feuer@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@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

Re: Bifoldable instance for Map

Andreas Abel