Proposal: Add &&& and *** to Data.Tuple

[Josef Svenningsson]

On 9/17/07, Henrik Nilsson <nhn at cs.nott.ac.uk> wrote:
> Hi Josef and Ian,
>
> Josef wrote:
>
>  > I propose to add the specialized version of these two functions
>  > [&&& and ***]
>  > to Data.Tuple which is more logical thing to import if you wish to
>  > have functions operating on tuples.
>
> Ian Lynagh wrote:
>
>  > I think that having the same function with different types is likely
>  > to cause user confusion, and also ambiguous function errors.
>
> I agree, that sounds worrying.
>
Henrik and Ian,

You've expressed worries that having functions with the same name but
different types could be problematic since it would cause confusing
error messages. While I can sympathize with that argument I don't
think it is an argument against having such functions. It is an
indication that the tools we're using don't report errors very well. I
don't think we should restrict the way we build libraries artificially
because we might get bad error messages. We should instead improve the
error messages!

Furthermore there are already many functions in the base libraries
which have the same name and they seem to cause little harm. Here's
some random examples:

* Data.Array.IArray contains most (all? I haven't checked) of the
functions in Data.Array but generalized to work with any array in
IArray.
* There are many functions with the same name in Data.Map,
Data.IntMap, Data.Set and Data.Sequence .
* Data.ByteString has four different modules all providing the same set of
function names, most of which have their names borrowed from Data.List and the
Prelude.
* Data.Foldable contains a whole slew of functions which are generalized
versions of list processing functions. Not to mention Data.Traversable .
* We have two monads defined in Control.Monad.ST and Control.Monad.ST.Lazy
which provides exactly the same definitions and all functions except one
mean exactly the same thing.

Have you had any problems with these? Personally I've been bitten once
when accidentally mixing the strict and the lazy ST monad. The error
message was indeed abysmal. But as I argued above, it's not a problem
with the library but rather a problem with the tools.

Cheers,

/Josef