Firstly, I'd like to say this proposal is great. We're in dire need of
extending the module namespace, and it's important that we do it in a
community-directed way.
Proposals 1 & 3: no problem.
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.
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. It doesn't fit well with the idea that the hierarchy should
be as static as possible.
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.
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).
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.
I suggest just calling it "Foreign", and putting it near the top of the
hierarchy somewhere. Similarly for Concurrent, Exceptions, etc.
I have a fairly complete hierarchy sketched out, but I'm going to revise
it based on your ideas and send it out later.
Cheers,
Simon
