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