> * 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(a)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
