Hierarchy suggestions

[Malcolm Wallace]

> Proposal 2: I think we should spend a lot of effort designing the layout
> of the module hierarchy, at least the standard parts, to make it as
> "future proof" as possible.  We really don't want to be reorganising
> things later.

I absolutely agree.  Let's try to get the naming correct (and
extensible) right from the beginning.

> 1) Std.
> I have a feeling that the "Std." prefix is going to be annoying,
> especially when libraries move from the base hierarchy to the Std
> hierarchy.

I actually had the same feeling in some ways.  The notion of a
"privileged" Std. hierarchy was not originally part of my proposal,
but it seemed to be quite important to some of the implementers at
the Cambridge meeting where I first presented the namespaces idea.

I think many people would value a clear signal about whether a library
is truly portable or not.  Making that fact a part of the module name
is about as clear and unmistakable as you can get.

> A portable application will only use libraries from the Std hierarchy,
> so we should make this the default.  Non-standard libraries should get
> the prefix, if any.

A "NonStd." prefix perhaps?  The trouble is that it would be very
hard to police.  Anybody can write a library with any name, and it
will immediately look standard unless they take the trouble to follow
this convention.  In some ways that completely negates the meaning
of standard.  "Assume everything is a standard, unless it explicitly
says it isn't!"

> An alternative is to simply sanction each library individually, as the
> interface is fixed and a portable, well-tested implementation exists.
> Non-sanctioned libraries aren't necessarily provided by all of the main
> implementations, and their interfaces may change (or even differ across
> implementations).

This was my original idea.  But I was swayed towards proposing
a distinguished Std. namespace, mainly because of the
clarity/documentation argument.  How do I know whether a library is
portable or not?  "Well it seems to work in GHC, so it must be okay..."
It's amazing how many people think some language feature is standard
Haskell'98 just because ghc implements it!

People don't seem to complain about having to write "java." at the
beginning of all their Java imports.

> 2) Haskell->Plus
> At some point in the future, Haskell will no doubt include the FFI, at
> which point the Haskell->Plus->FFI hierarchy won't make sense any more,
> and we'll have to break lots of existing code to move the library
> somewhere sensible.

The Haskell.Plus. namespace is a cute (IMO) way to make it clear that
these libraries use extensions to pure Haskell'98.  Perhaps if we
called the namespace Haskell98.Plus. then it would be even clearer
that these things are not Haskell'98, and never will be.  When a
future version of Haskell comes along, perhaps it won't even be called
Haskell, so we will adopt a LanguageFormerlyKnownAsHaskell. hierarchy.
(Or more likely Haskell200x. I suppose)

> I suggest just calling it "Foreign", and putting it near the top of the
> hierarchy somewhere.  Similarly for Concurrent, Exceptions, etc.

Whatever, I think the name should make it clear that these libraries
require compiler/language extensions, that's the main point.

> I have a fairly complete hierarchy sketched out, but I'm going to revise
> it based on your ideas and send it out later.

Looking forward to it.  I'll place it on the web next to my current
layout proposal if you like, for comparison.  Then we should start
discussing individual branches of the hierarchy, and try to come up
with a consensus for each part, recording our progress on the web also.
(I suggest at that stage we build a new layout tree from scratch,
separate from both layout proposals, and based on agreement here on
the list).

Regards,
    Malcolm