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