I forgot to mention that the Text.Parsec modules should be preferred to the Text.ParserCombinators.Parsec modules as the Haddock documentation reveals.
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
On Feb 4, 2008 12:11 PM, 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?
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
participants (3)
-
Derek Elkins -
Johan Tibell -
Wolfgang Jeltsch