* 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
On Fri, Mar 09, 2001 at 02:05:14AM -0800, Simon Marlow wrote:
* 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.
Right, which is pretty much the unsafe stuff. I wasn't very clear here, but I prefered the name System over Unsafe and used it in the summary below, but it was the location under Lang that I was sayign I preferred. I think it would be nice if all the top level hierarchies except Lang were (or at least could be) implemented in Haskell - if you can't implement it in Haskell then it must be part of the language rather than a library for the language.
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.
Yes, sorry, I didn't mean to indicate otherwise.
* 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.
But why should Haskell be a special case? Can C, Pascal, HTML etc all have their own top level hierarchies?
* 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.
OK, I'm not at all familiar with them, just got confused with their current locations.
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.
OK, I guess I misunderstood CoreSyntax, which is presumably lower level.
Perhaps Lang.Prelude would be a better place for it, though.
I still believe this is true,
* 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.}
Having thought further I agree that GHCisms shouldn't be in the main tree, or in fact part of the standard. I think having to type the Haskell. prefix all the time would be a pain, so perhaps something short like Imp.* could be devoted to implementations and the standard wouldn't say how it would be subdivided but simply say "Imp.GHC -- owned by GHC" 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).
Under Lang, as explained above.
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.
*nod*
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.
Agreed.
Thanks
Ian
--
Ian Lynagh -
On Fri, Mar 09, 2001 at 02:05:14AM -0800, Simon Marlow wrote:
* 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.
If you allow relative module paths, you don't have this problem wherever you decide to put GHC. It might be a bit tricky getting the relative module paths to work right if you have a deeply nested hierarchy under GHC. Best, Dylan Thurston
participants (3)
-
Dylan Thurston -
Ian Lynagh -
Simon Marlow