module hierarchy (Re: [Haskell-cafe] parsec3 pre-release [important
g9ks157k at acme.softbase.org
Mon Feb 4 06:11:07 EST 2008
Am Samstag, 2. Februar 2008 05:53 schrieb Derek Elkins:
> I forgot to mention that the Text.Parsec modules should be preferred to
> the Text.ParserCombinators.Parsec modules as the Haddock documentation
I would have prefered to shorten ParserCombinators to Parsing and leave Parsec
under the parsing category. However, I would prefer if Parsing would move
out of Text since parsing is not just about parsing text. Parsec parses also
streams other than character streams now.
Recently, there was a discussion on the Yampa mailing list about where to put
FRP-related modules into the module hierarchy. There was the suggestion of
Control.FRP. It was noted, however, that Control seems to suggest imperative
programming while many things under Control are not restricted to that
paradigm (like monads, for example) and others (like FRP) have nothing to do
with imperative programming. We finally chose to introduce a separate
top-level module name FRP since the FRP stuff didn’t seem to really fit in
any of the existing top-level categories.
I concluded from this discussion that the current module hierarchy is too deep
and that it might be good to remove the current top-level layer. So
Parsing.Parsec, for example, or Monad.Reader.
What do you and others think?
More information about the Haskell-Cafe