At 2001-02-26 09:59, Malcolm Wallace wrote:
Proposal 2 ---------- Adopt a standardised namespace layout to help those looking for or writing libraries,
I'm a big fan of the Java reversed DNS style. Whatever, I think it's important that anyone with a domain name should be able to obtain a unique namespace without any further bureaucracy. In fact, whatever you decide it's likely to happen anyway, since people will decide that for instance "Com.Microsoft.Research.MyModule" is unlikely to clash with anyone outside the appropriate domains and subdivisions. I'm assuming that module name components have enforced capitalisation, like all other Haskell identifiers.
and a "Std" namespace prefix for genuinely standard libraries. (These are two different things.)
Eeesh, let's hope ICANN doesn't register a 'std' TLD. I would prefer "Standard" for this reason and also because the abbreviation seems pretty pointless.
In addition to a standardised hierarchy layout, I propose a truly Standard-with-a-capital-S namespace. A separate discussion is needed on what exactly would consitute "Standard" quality, but by analogy with Java where everything beginning "java." is sanctioned by Sun, I propose that every module name beginning "Std." is in some sense sanctioned by the whole Haskell community.
Do you have any kind of guarantees of copyright openness in mind? In Java, everything under java.* is supposed to be owned by Sun. Will it be standard practice for versions of Standard be included with Haskell compilers? Could the Prelude make use of Standard? Could Standard become an alternative to the Prelude? If answers to these last three are all "no", an alternative would be to put it under "Org.Haskell.Standard". -- Ashley Yakeley, Seattle WA
Ashley writes:
In fact, whatever you decide it's likely to happen anyway, since people will decide that for instance "Com.Microsoft.Research.MyModule" is unlikely to clash with anyone outside the appropriate domains and subdivisions.
Yes, we expect companies to develop their own hierarchies if they so wish. I don't know whether the domain prefixes Com. Net. Org. and country codes Us. Uk. Fr. etc are strictly necessary - as I understand it, Java is moving to allow "vendor." as a synonym for "com.vendor."
I'm assuming that module name components have enforced capitalisation, like all other Haskell identifiers.
A namespace is a dot-separated sequence of conids, therefore yes, there is enforced capitalisation.
Eeesh, let's hope ICANN doesn't register a 'std' TLD. I would prefer "Standard" for this reason and also because the abbreviation seems pretty pointless.
If Std. is going to be the common case, people will complain about having to type the extra five characters. Normally I would say spell it out in full is the best rule. Here, I'm prepared to compromise a little.
Do you have any kind of guarantees of copyright openness in mind? In Java, everything under java.* is supposed to be owned by Sun.
All standard libraries will be copyright to their authors, but must be released under an open source licence. (For instance Hugs at the very least will require the source.) Ideally, I think they should all have the same licence. We need to decide which. LGPL? BSD? Any opinions?
Will it be standard practice for versions of Standard be included with Haskell compilers?
This is the intention.
Could the Prelude make use of Standard? Could Standard become an alternative to the Prelude?
In principle yes. One notable omission from my hierarchy layout proposal is the current Haskell'98 standard libraries. Should they remain at the toplevel? Or should they become Standard.Prelude Standard.IO Standard.List Standard.Monad etc.? Regards, Malcolm
Malcolm Wallace
Ashley writes:
Do you have any kind of guarantees of copyright openness in mind? In Java, everything under java.* is supposed to be owned by Sun.
All standard libraries will be copyright to their authors, but must be released under an open source licence. (For instance Hugs at the very least will require the source.) Ideally, I think they should all have the same licence. We need to decide which. LGPL? BSD? Any opinions?
This depends a bit on what actually we mean by standard. In fact, I don't think that there can be only one standard. There reason is the varying complexity of libraries and the fact that some rely on other non-haskell libraries. For example, the current modules in the Library Report are really standard libraries in the sense that their interface is set in stone and there is as far as technically possible freely available code with absolutely no strings attached. However, this is not going to work for large libraries like HOpenGL or Gtk+HS. Their interface will never be stable simply because they have to track the changes in the corresponding C library (and because they are so big that we will always find mistakes in their interface). Moreover, it doesn't make much sense to require, e.g., that Gtk+HS comes with a license that is less restrictive than LGPL, because GTK+ is LGPL and we can't change this. BTW, this is another reason that I think, Std. doesn't make sense. It's too inflexible.
Will it be standard practice for versions of Standard be included with Haskell compilers?
This is the intention.
Which immediately leads us to protability issues with libraries that are not fully implemented in Haskell, but rely on some external code. Cheers, Manuel
On Tue, Feb 27, 2001 at 05:33:26AM -0800, Ashley Yakeley wrote:
At 2001-02-26 09:59, Malcolm Wallace wrote:
Proposal 2 ---------- Adopt a standardised namespace layout to help those looking for or writing libraries,
I'm a big fan of the Java reversed DNS style. Whatever, I think it's important that anyone with a domain name should be able to obtain a unique namespace without any further bureaucracy.
I'd go for e-mail address (with @ replaced by a . as in DNS records) as
an option as some people have a shared domain name but work on seperate
projects, or have no domain name at all. I'd also agree with Simon
Marlow (I think) that it should be these that are under user. or
something rather than the standard ones under std.
--
Ian Lynagh -
participants (4)
-
Ashley Yakeley -
Ian Lynagh -
Malcolm Wallace -
Manuel M. T. Chakravarty