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

[Bertram Felgenhauer]

Conal Elliott wrote:
> Maybe I've missed the essence of this discussion, but I seem to see to
> opposite sentiments running through.  One is to create additional,
> *specialized* (for "->") names for existing general arrow operators, rather
> than using the generalized versions, citing simpler error messages.  The
> other thread is regret over th Haskell 98 committee having done just this
> kind of specialization (dumbing down) for monads vs lists.

> I agree that the names "onFst" and "onSnd" are easier to interpret than
> "first" and "second".  So let's use those names for the general (Arrow)
> versions, rather than the specializations.

Changing the names of 'first' and 'second' in Control.Arrow is a bad
idea, I think. It'll break a lot of packages.

Adding functions that conflict with Control.Arrow in Data.Tuple looks
far less problematic, because Data.Tuple is quite rarely used. The
Prelude reexport of Data.Tuple for nhc should be pruned, however.

Data points:

Number of occurences of "Data.Tuple" in various packages:
(note: not all of these are package imports.)
      9 ghc/libraries/base/
      7 ghc/
      5 ghc/testsuite/
      4 lambdabot/
      1 ghc/libraries/template-haskell/

Same for "Control.Arrow":
(note: includes non-imports and imports like Control.Arrow.ListArrow,
so it's overcounting quite a bit)
    174 hxt/
    128 ghc/libraries/arrows/
     21 ghc/testsuite/
     16 lambdabot/
      6 ghc/
      5 ghc/libraries/base/
      2 ghc/libraries/containers/
      1 xmonad/

The sample consists of ghc + testsuite + libraries + extra libraries,
HAppS, X11-extras, binary, derive, gtk2hs, haddock, hssdl, http, hxt, jhc,
lambdabot, tagsoup, uniplate, xmonad and zlib.

Bertram