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

[Josef Svenningsson]

Sorry for my slow reply,

Well, it doesn't seem like we're anywhere near a consensus so I'll
just drop this proposal.

Let me just finish off by clarifying my views on this ticket as I
answer Henrik's post.

On 10/19/07, Henrik Nilsson <nhn at cs.nott.ac.uk> wrote:
> So, with the risk of stating what has already been covered,
> my concerns are that like Jon I find the reuse of names
> unfortunate, especially if it is done in what appears to
> be a very central module. Moreover, as functions are perfectly
> legitimate arrow instances, I don't really see the point of it all,
> and I remain unconvinced by the argument that importing
> Control.Arrow somehow is complicated and scary.
>
I don't think that importing Control.Arrow is complicated of scary. I
just think it gives the wrong mental model of what it going on. In
Control.Arrow it's all about the process of transforming one thing
into the other. Arrows abstract over transformations and gives support
for different varieties including transformations which are stateful,
can throw exceptions and so on and so forth.

However, when we look at the particular case of the function arrow
instance there is a different mental model at play. At least for me.
When I see the (&&&) operator instantiated for the function arrow I
don't think about the process anymore, I think about the objects being
manipulated. And the objects in this case are pairs. The reason is
that the function arrow is so common in Haskell that at least I don't
think about it as anything special. My focus shift towards the things
that form the input and output. And those things are pairs in this
case.

So this really comes down to thinking about morphisms or thinking
about objects if you phrase it in category theory lingo. In my brain
these two ways of thinking are different and therefore I like to have
separate functions for these two models. Even if it means that two
functions are computationally equal.

But maybe the problem is simply that I'm stupid and should learn to
think about these two mental models as one :-).

The other side of the coin is what to name the functions. For this
proposal I chose the same names as their generalized counterparts. I
can see why that worries people although I don't share that feeling.
We have a module system whose purpose is (among other things) to
handle names. It does so rather well, consider for instance Data.Map
and Data.Set which I use extensively in my everyday programming. They
have a lot of function names in common and which also clashes with
Prelude names and other libraries. It's not a problem to have several
functions having the same name. It's actually a feature which lessens
the burden of remembering a ton of names and which shows that their
intended semantics is, if not equal, then strongly related.

Having these tuple function from my proposal but under different names
would be OK for me though. It would be better that not having them at
all.

> It may well be, of course, that the current class hierarchy
> isn't factored the right way, i.e. that operations like &&& and
> *** should live some place else entirely. (This wouldn't be
> the first instance of such problems.)

That might be true. I don't have any opinion on that.

> That's a somewhat orthogonal
> discussion, though. But defining &&& and *** in more places
> certainly isn't going to help.
>
Well, I disagree with that but I've already said why so no need to
rehash it here. I guess we can agree to disagree.

Cheers,

/Josef