module hierarchy (Re: [Haskell-cafe] parsec3 pre-release [important note])

2008-02-04 Thread Wolfgang Jeltsch
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
 reveals.

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?

Best wishes,
Wolfgang
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


Re: module hierarchy (Re: [Haskell-cafe] parsec3 pre-release [important note])

2008-02-04 Thread Johan Tibell
On Feb 4, 2008 12:11 PM, Wolfgang Jeltsch [EMAIL PROTECTED] wrote:
 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
  reveals.

 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?

I would recommend reading Ontology is Overrated [1] as it might be of
relevant to this discussion. I've been asking myself lately if it
would be beneficial for libraries that are not very core (e.g.
Data.Map) to use a unique top-level name (e.g. Parsec.SubModule) and
leave categorization to Hackage. Or should we just try to cram
everything into the same module hierarchy (e.g. Parsing.Parsec,
Parsing.Foo, etc?).

Another question: If we continue with the current approach where
should we put versions of a library specialized to a certain type?
e.g.

Parsing.ByteString.Parsec or Parsing.Parsec.ByteString?

The current preference seems to be to use the latter but that makes it
hard to find all parsing libraries that parses bytestrings as they
would not be kept under Parsing.ByteString.

1. http://www.shirky.com/writings/ontology_overrated.html

-- Johan
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


[Haskell-cafe] parsec3 pre-release [important note]

2008-02-01 Thread Derek Elkins
I forgot to mention that the Text.Parsec modules should be preferred to
the Text.ParserCombinators.Parsec modules as the Haddock documentation
reveals.

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe