David Luposchainsky dluposchainsky at googlemail.com
Fri Aug 9 09:55:03 CEST 2013

On 2013-08-09 08:52, Andreas Abel wrote:
> It happens again and again on this list:  Someone request an innocent
> function on tuples or Either and after some initial discussion someone
> else writes "it is in Control.Arrow".  No offense intended, but to me
> "just use Control.Arrow.xxx" is a smart-ass comment in the line of "this
> is just a lax monoidal functor" I hear from category-theorists all the
> time.

I wouldn't go so far as to calling it a "smart-ass" suggestion. I think
using Arrow is fine for this purpose, the thing is just that
Control.Arrow is not where you might be looking for such a function. In
that sense, the comparison to a "just lax monoidal functor" is not very
good - the suggestion is not "view X as an Y and you'll see how Z is
just function F", it is "that very function is almost directly in there".

> Arrows are on a level of abstraction that many Haskell programmers
> (including me) do not make use of and should *not* be forced to study
> just because they need an innocent function about tuples (or Either).

Again, the "Arrows" we're talking here is just the (->) instance, which
is like not knowing Monads but using >>= on Maybe anyway. In other
words, you don't need to know Arrow to use (+++) as soon as you know
it's mapEither, similarly to how you only need to know that >>= pipes on
Just values until it hits a Nothing.

> Thus, I agree with Henning and David and many more that there is
> something wrong here. mapEither, mapPair, mapFst, mapSnd and the like
> should be added to Data.Tuple and Data.Either, at the risk of
> duplicating stuff from Control.Arrow.

In the light of the recent Foldable/Traversable discussion, we'd be
doing a similar thing again: have monomorphic versions of more general
(standard) functions in different libraries. If we add the monomorphic
functions, we should at least define them in terms of the Arrow
functions, i.e. `mapEither :: (monomorphic); mapEither = Arrow.(+++)` so
that we minimize code duplication.


More information about the Libraries mailing list