Text.ParserCombinators.* is a bad name
simonmarhaskell at gmail.com
Fri Mar 10 08:37:43 EST 2006
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:
> but we're stuck with Text.ParserCombinators.Regex. Making me think that:
> namespace should be deprecated in favour of:
> 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
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:
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.
More information about the Libraries