Alternative hierarchy proposal.

[Ian Lynagh]

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 - <igloo@earth.li>
http://c93.keble.ox.ac.uk/~ian/haskell/