Malcolm Wallace
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 also don't have a good feeling about Std.
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.
I can understand the concerns that have surfaced at the meeting, but I am not sure that a prefix is the right way to assert the standardness of a library.
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!"
And it wouldn't solve the problem with having to change the name of the library at a point, where by definition, it is heavily used (because only then we take it as a standard library).
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!
There must be an official list of standard libraries. Just as we know have the Library Report that provides the official list of standard libraries. Cheers, Manuel