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
on module prefixes (= directory names). perhaps there could be renaming declarations not only for modules, but also for prefixes. say you have modules Foo.Frobs and Bar.Frobs, then you could import Foo as X import X.Frobs there would normally be an implicit "import Standard", but you could override with "import Experimental as Standard" of course this could cause more problems than it solves. -- -- Johannes Waldmann ---- http://www.informatik.uni-leipzig.de/~joe/ -- -- joe@informatik.uni-leipzig.de -- phone/fax (+49) 341 9732 204/252 --
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
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
participants (4)
-
Johannes Waldmann -
Malcolm Wallace -
Manuel M. T. Chakravarty -
Simon Marlow