I think this would be a useful point to stand back and summarise where we seem to have reached in discussing my original proposals (posted on 26th February). Shout if you think I've got something wrong here, missed something important out, or if I mark something as 'decided' that you really want to discuss some more. Proposal 1: introduce nested namespaces. * Everyone seems to agree that this is a good idea. * No-one has objected to using the normal dot (.) as the namespace separator character, nor has anyone suggested a different character. * The idea of an implicit import-renaming clause import A.B.C.D [ as D ] received no objections, although some people would like there to be additional implicit renamings import A.B.C.D [ as C.D ] import A.B.C.D [ as B.C.D ] * The original proposal allowed only absolute naming of modules. Others have proposed an additional mechanism for relative naming of modules within the current (or parent) namespace. I don't see agreement here yet. Proposal 2a: adopt a standardised namespace layout * Again, people seem to agree broadly that this is an essential thing. Discussions are still in progress about the detail of the layout, and I expect these to continue. Proposal 2b: adopt a "Std." namespace for libraries that are common to all implementations. * There is little agreement here. Simon M, Manuel, and others have expressed their doubts that it is workable. No-one has defended the idea except me. But then Simon posted a hierarchy layout proposal in which "Haskell." seemed to take the role of "Std.". So I'm a bit confused. I'd like to see some more discussion about this. Proposal 3: develop a social process for adding new libraries to the "standard" set. * Well, this list is the starting point, so there's not much more to be said on that. * The set of criteria by which we as a community might judge whether a library is recognised as "standard" have not really received any comment. Other issues: * We have mentioned briefly that "standard" libraries should be available in all Haskell systems. But Manuel pointed out that many libraries will be developed independently of particular compilers - and so they should be distributed separately, to ensure they remain up-to-date with external software (e.g. C libraries). I think we need to think carefully about how to manage this process. A single repository of compiler-independent and build-system-independent library code would be a good start. But it won't be sufficient. Regards, Malcolm