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. David