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
On Sun, Mar 11, 2001 at 01:28:38PM +0000, Malcolm Wallace wrote:
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.
I think that a common prefix for the standard libraries will get to be a pain far more than one for non standard ones, and non standard ones are going to have a huge prefix for uniqueness anyway. The chances are most modules will either be in . or be standard anyway. My vote is for a user.* hierarchy with mangled e-mail addresses as I have previously described.
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.
In the absence of some sort of committee or community voting, it essentially comes down to what the hugs, GHC and NHC maintainers agree on in practise. As things stand I suspect it will be decided between then with the more controversial ones argued out on a mailing list.
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.
I am unclear on precisely what the problem is here. Clearly the
language extension libraries (like IO) will be implementation specific
and will be maintained with the implementation. For those implementable
in pure Haskell there should be a page, probably on haskell.org, which
links to all the known implementations of each library and each
implementation would then take the latest stable release when it wanted
to release of the implementation it chose, or had one of it's own that
made use of it's own specific extensions. For the purposes of not losing
things when sites disappear, and if haskell.org can cope with this, it
may be sensible to have copies on haskell.org somewhat akin to cpan.org.
This is as good a time as any to bring up testsuites. I propose that,
as part of the interface that defines a library, there must be a
testsuite that uses only existing standard libraries, Haskell 98 and the
new library and checks anything the designer can think of that the
library might do wrong.
Thanks
Ian
--
Ian Lynagh -
Ian Lynagh writes: | On Sun, Mar 11, 2001 at 01:28:38PM +0000, Malcolm Wallace wrote: | > | > 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. | | I think that a common prefix for the standard libraries will get to | be a pain far more than one for non standard ones, and non standard | ones are going to have a huge prefix for uniqueness anyway. The | chances are most modules will either be in . or be standard | anyway. My vote is for a user.* hierarchy with mangled e-mail | addresses as I have previously described. Do we even need to distinguish standard/other modules by their names? If the distinction is just a gentle piece of advice about portability, perhaps it could be expressed some other way (e.g. in the imports of a dummy top-level module called Standard), and each module could go straight to its own One True Preferred Path regardless of whether it's standard yet. - Tom
participants (3)
-
Ian Lynagh -
Malcolm Wallace -
Tom Pledger