for :: (Traversable t, Applicative f) => t a -> (a -> f b) -> f (t b)

Unfortunate or not, bifor follows the existing convention from Traversable in base.

Given two candidate conventions, I'd choose to err on the side of what we are already doing elsewhere in the library rather than devise and explain a new convention for little margin gain and much added confusion, while simultaneously hitting existing users with type errors / semantics changes.











On Fri, Apr 25, 2014 at 1:14 PM, Andreas Abel <andreas.abel@ifi.lmu.de> wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

A general +1 from me.

To start the bikeshedding, let's have a look at the names in
Data.Bitraversable:

bitraverse :: Applicative f => (a -> f c) -> (b -> f d) -> t a b -> f
(t c d)
bisequenceA:: Applicative f => t (f a) (f b) -> f (t a b)
bimapM     :: Monad m => (a -> m c) -> (b -> m d) -> t a b -> m (t c d)
bisequence :: Monad m => t (m a) (m b) -> m (t a b)
bifor :: (Bitraversable t, Applicative f) => t a b -> (a -> f c) -> (b
- -> f d) -> f (t c d)
biforM :: (Bitraversable t, Monad m) => t a b -> (a -> m c) -> (b -> m
d) -> m (t c d)

I am unhappy about the name "bifor".

forM = flip mapM, so the right generalizations would be

     for   = flip map
     bifor = flip bimap

     forA   = flip mapA   = flip traverse
     biforA = flip bimapA = flip bitraverse

Unfortunately, "for" was taken for "flip traverse" by
Data.Traversable.  Instead "forA" should have been used.

In my own code, I actually define

  for = flip map

and use it in situations like

  let ys = for xs $ \ x ->
       long
       function
       body

(I never use "for" from Data.Traversable anyway, since I have not
needed yet an Applicative which is not a Monad.)

Proposal:  use "biforA" instead of "bifor".

Cheers,
Andreas

On 25.04.2014 18:36, Edward Kmett wrote:
> Biapplicative is left out because unlike the other two, it is
> underdetermined. There are at least two forms of biapplicative
> point. There are however, no such headaches with
> Bifunctor/Bifoldable/Bitraversable, which get nailed down hard by
> the laws.
>
> A very enthusiastic +1 on the proposal from me.
>
> -Edward
>
>> On Apr 25, 2014, at 12:28 PM, Casey McCann
>> <cam@uptoisomorphism.net> wrote:
>>
>> Was Biapplicative left out of the proposal because of
>> dependencies? It seems at least as useful as the others.
>>
>> - C.
>>
>>> On Fri, Apr 25, 2014 at 12:02 PM, Dan Doel <dan.doel@gmail.com>
>>> wrote: The previous discussion about methods on Either had some
>>> mention of adding bifunctors to base, but no one wrote up the
>>> details. So I've taken it upon myself to do so.
>>>
>>>
>>> The following proposal is to add some modules of the bifunctors
>>> [1] package to base, namely:
>>>
>>> Data.Bifunctor Data.Bifoldable Data.Bitraversable
>>>
>>> These modules contain classes and functions for working with
>>> types similar to those identified by Functor, Foldable and
>>> Traversable, except that there are parameterized by two
>>> 'element types' so to speak.
>>>
>>>
>>> The advantages of this change are among the following:
>>>
>>> These are the right abstractions for many operations. For
>>> instance, Arrow is often recommended if someone wants to map
>>> over both sides (or the left side) of a pair. In fact, I'd
>>> wager that it is the single most common reason for recommending
>>> use of Arrow. But this is not really what Arrow was designed
>>> to accomplish. This is exactly what Bifunctor is for, though,
>>> and it abstracts over this kind of operation with pairs,
>>> Either, and in my experience many custom data types.
>>>
>>> Placement in base gives a better opportunity for people to find
>>> these right abstractions. If someone goes into the
>>> documentation for Data.Either looking for a way to map both
>>> parameters, they will not, of course, be directed to the
>>> bifunctors package, even though it provides a good means of
>>> doing what they want. If Bifunctor were in base, the
>>> documentation for Either would note that it is one.
>>>
>>>
>>> Some things to consider:
>>>
>>> The API of the modules will shrink a bit due to Applicative
>>> becoming a superclass of Monad in 7.10. There is no reason for
>>> a separate bitraverse and bimapM and so on. Some things will
>>> likely be renamed, as well; bisequenceA => bisequence, for
>>> instance.
>>>
>>> The 'first' and 'second' functions in Data.Bifunctor overlap
>>> with Arrow. This actually means that they are a drop-in
>>> replacement for the commonly suggested misuse of Arrow.
>>>
>>> None of the dependencies of the bifunctors package are needed
>>> by the modules in question. They are used for other modules, or
>>> as part of an arbitrary decision of where to put an instance.
>>> For example, the tagged dependency is used to give instances
>>> for Tagged, but these could easily be moved into the tagged
>>> package if base were to adopt these classes.
>>>
>>>
>>> Discussion period: 2 weeks
>>>
>>> [1] http://hackage.haskell.org/package/bifunctors


- --
Andreas Abel  <><      Du bist der geliebte Mensch.

Department of Computer Science and Engineering
Chalmers and Gothenburg University, Sweden

andreas.abel@gu.se
http://www2.tcs.ifi.lmu.de/~abel/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlNamAEACgkQPMHaDxpUpLM43gCcCZJS6y4OIYtSU+RifojGKLha
C6EAoOQUhUKbJs3Dt9OZ6ryK97cGrCji
=X8HU
-----END PGP SIGNATURE-----