Text.ParserCombinators.* is a bad name

[Simon Marlow]

Donald Bruce Stewart wrote:
> * Firstly, a library naming issue. Text.ParserCombinators feels like a
> clunkey name. This week I was working on a set of regex combinators,
> that ideally would go under:
> 
>     Text.Combinators.Regex
> 
> but we're stuck with Text.ParserCombinators.Regex. Making me think that:
> 
>     Text.ParserCombinators.ReadP
>     Text.ParserCombinators.Parsec
>     Text.PrettyPrint.HughesPJ
> 
> namespace should be deprecated in favour of:
> 
>     Text.Combinators.ReadP
>     Text.Combinators.Parsec
>     Text.Combinators.HughesPJ
> 
> Reflecting the wide variety of text-manipulation combinators we use. 
> The latter seem more elegant. Parsec in particular can lead to some 
> noisy import statements in its current namespace.

At the time, I think my preference was for Text.Parsing.* and 
Text.Pretty.* (maybe Text.Parser.*, or Text.Parsers.*, I can't remember 
exactly).  Malcolm W. liked the longer version, I didn't feel strongly 
enough to pursue it.

Still, I prefer Parsing and even ParserCombinators to just Combinators, 
I don't think Combinators is a particularly useful classification; most 
modules define combinators.  I think the intention with 
ParserCombinators was to distinguish the category from parsers for a 
particular grammar; on the other hand, the hierarchy puts parsers for 
particular grammars elsewhere (Text.XML.Parser, 
Language.Haskell.Parser).  That is, everything to do with a particular 
language is collected in a sub-hierarchy, rather than collecting by 
operation first.

Designing a hierarchy is never an exact science; you often come across 
several categories on which you can split, and it's a difficult choice 
as to which category should be nearer the root of the tree 
(System.Posix.IO, or System.IO.Posix?).  You could argue all day about 
this stuff and not make any useful progress.

Can I remind people of this:

   http://haskell.org/~simonmar/lib-hierarchy.html

also available in GHC's darcs repo in libraries/doc.  This is the place 
we keep the "design" of the hierarchy, it's not an official document in 
any sense, but it is the result of our original discussions about the 
hierarchy, updates from time to time as new libraries have come along. 
I hope as part of the Haskell' process we'll fix a design for the hierarchy.

> * Secondly, an FAQ on #haskell is "Where is fst3/snd3/thd3?"
> 
> Lacking some fun generic system for hacking at tuples, perhaps 
> fst3/snd3/thd3 should be put back into the base library under 
> Data.Tuple, next to fst/snd?  I note they were in (at least some 
> versions of) Haskel 1.2, and they're even defined locally in GHC.PArr.
> 
> I'll draft the patches if people think these are reasonable.

Data.Tuple for these is fine by me.

Cheers,
	Simon