* Win32 Dunno what would go in here. Possibly OS.Win32 or something would be better regardless to kep the top level branches to a minimum?
Win32 is a complete Haskell binding to the Win32 API, including, but not limited to, the graphics and user interface API. It doesn't really belong under Graphics, but perhaps if we had a subtree for OS APIs, it could go next to POSIX.
In SM: * System THis is equivalent to Haskell.Plus.Unsafe I think. Personally I think this is a good idea as it is not implementable in Haskell. I'm not sure the Plus distinction is necessary though.
Actually I intended the System hierarchy to contain libraries that interact with the outside world and the Haskell runtime system. All IO-related stuff (except for graphics) belongs in there. I wouldn't object strongly to moving "unsafe" functions into a hierarchy of their own, but IMO unsafePerformIO belongs with the IO monad.
* Source This appears to be parsers etc for Haskell code, and I don't see why it should be here rather than Text.Haskell next to HTML, XML etc
Text.Haskell sounds good. But this also contains a definition of an abstract syntax datatype for Haskell, and it may in the future contain reference implementations of a static analyser and type checker for Haskell, so perhaps keeping it in a hierarchy of its own would be better.
* Concurrent I don't know anything about this but it looks fair enough * Parallel As the comment is "as hslibs/concurrent/Parallel" should it not go under Concurrent?
Hmm. The parallel API is separate from the Concurrent API, and there exist systems that implement one or the other, as well as both. I think they're separate. Parallel is small, though, and perhaps doesn't warrant its own top-level category. Lang.Parallel and Lang.Concurrent would be fine.
* Prelude MW has Haskell.Language.CoreSyntax which I think makes more sense
I don't understand - Prelude wasn't intended to be the same as Haskell.Language.CoreSyntax, it's just the Haskell98 Prelude that we have now. Perhaps Lang.Prelude would be a better place for it, though.
* GHC Probably better under Lang.CompilerSpecific.GHC?
Maybe. We're going to be writing the Lang.CompilerSpecific.GHC prefix a lot while implementing libraries, though. Remember most of this hierarchy is under Haskell, but I put the compiler specific parts outside of the Haskell hierarchy. It's not very clear from the diagram, sorry. Haskell.{Lang,System,Text etc.} GHC.{UnboxedTypes etc.}
There's also the Std vs Non-std top branch debate. I agree with the non-std myself.
The SM trees in general seem a bit better thought out to me too, e.g. I don't think Bits or MD5 belong under Data.Encoding.
To summarise I think something like:
Algebra: As MW Concurrent: As SM plus Parallel Data: As SM Database: As SM and MW Debug: As SM and MW Graphics: As MW (more detailed than SM) Lang: As SM, plus CompilerSpecific.*, Prelude, { System.* from SM plus POSIX plus BSD }
Do you mean System under Lang, or as a top-level category (I think top-level is better, BTW).
Net: As SM (plus a POSIX module if POSIX talks about this) Numeric: As SM and MW OSSpecific: As explained Text: As SM and MW User: your@email.address gets address.email.your.* off of this
As a general comment on the subject of hierarchy layouts, it's clear to me that we can never have a "perfect" hierarchy, since some modules will always belong in more than one place and others won't belong anywhere in particular. I think the best we can do is try to come up with something that is as consistent as possible, not too deeply nested, will extend gracefully as we add new libraries, and won't require reorganising as the language changes. Cheers, Simon