RE: Summary of progress
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.
That'd be fine with me. Actually, to address Malcolm's (understandable) confusion, the differences between "Haskell" and "Std" are mainly that entry into "Haskell" is much easier. For a new library, it could be brought in immediately but marked "non-standard" until such time as the community has discussed and agreed on an interface. In the meantime, compilers would be free to distribute the non-standard version for testing. I've no objection to dropping the "Haskell" prefix and adding a prefix for the non-"Haskell" parts of the tree. An alternative might be to adopt an extension such that import Haskell. would add D/Haskell/ to the search path for each D in the current search path, and perhaps the "import Haskell." could be implicit, like "import Prelude".
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.
Voting is something we want to avoid, I think. Too often you end up with a result you don't like :-). Open discussion, followed by an informed decision by a few trusted individuals would get my vote. Cheers, Simon
An alternative might be to adopt an extension such that
import Haskell.
would add D/Haskell/ to the search path for each D in the current search
This looks like a hack? Indicating that we believe nested module names are a good thing, but also believe that they are cumbersome to use? Do we need two types of `imports': `import Foo.Bar.M' imports a module, while `import Foo.Bar.*' does not actually import a module, but rather adds an element to the search path. So that `import Foo.Bar.*; import M' would do the same as `import Foo.Bar.M' Or do you actually mean `import *.Haskell.*' ? This would make `Foo.Haskell.M' visible as `Foo.M' ? Or as `M' ? Best regards, -- -- Johannes Waldmann ---- http://www.informatik.uni-leipzig.de/~joe/ -- -- joe@informatik.uni-leipzig.de -- phone/fax (+49) 341 9732 204/252 --
Mon, 12 Mar 2001 14:29:59 +0100 (MET), Johannes Waldmann
Do we need two types of `imports': `import Foo.Bar.M' imports a module, while `import Foo.Bar.*' does not actually import a module, but rather adds an element to the search path.
I would prefer to import module names like other names, i.e. import Foo.Bar -- It can make some module names visible. import M -- Imports Foo.Bar.M, assuming it exists. If more than -- one module called M is visible, it's an ambiguity -- error as usual. import Foo.Bar as F import F.M -- Same as above. The only special thing about module names is that their prefixes are automatically imported qualified, i.e to refer to Foo.Bar.M.f you don't have to import each of Foo, Bar and M separately, but just import fully M using its qualified name. This works for other names in ghci. Such Foo.Bar module is not defined explicitly, but results from having a subdirectory in import directories. Contents of all Foo.Bar directories from all import directory roots are merged to form such pseudo-module which contains nothing but modules. In a future version of Haskell, when module export list will specify the interface and not only names, it will be possible to export modules from other explicit modules. There will be no distinction between modules which contain only modules and modules which contain everything else. -- __("< Marcin Kowalczyk * qrczak@knm.org.pl http://qrczak.ids.net.pl/ \__/ ^^ SYGNATURA ZASTÊPCZA QRCZAK
Such Foo.Bar module is not defined explicitly, but results from having a subdirectory in import directories. Contents of all Foo.Bar directories from all import directory roots are merged to form such pseudo-module which contains nothing but modules.
Yes, very good. That's what I wanted. Do the implementors aggree? It might not be that straightforward, for instance, there is no file Foo/Bar.hi - or else, when is it generated/updated? Best regards, -- -- Johannes Waldmann ---- http://www.informatik.uni-leipzig.de/~joe/ -- -- joe@informatik.uni-leipzig.de -- phone/fax (+49) 341 9732 204/252 --
Johannes Waldmann wrote:
Such Foo.Bar module is not defined explicitly, but results from having a subdirectory in import directories. Contents of all Foo.Bar directories from all import directory roots are merged to form such pseudo-module which contains nothing but modules.
Yes, very good. That's what I wanted. Do the implementors aggree?
Personally, I don't like the idea at all. :-) I don't see the need to bring whole namespaces into scope. And even if I did, I wouldn't overload the standard import syntax to mean namespace scoping as well - an entirely different syntax would be better, e.g. namespace Foo.Bar namespace A.B import Baz -- gets Foo.Bar.Baz or A.B.Baz or both. Regards, Malcolm
Two remarks on what Malcolm wrote:
I don't see the need to bring whole namespaces into scope. And even if I did, I wouldn't overload the standard import syntax to mean namespace scoping as well -
Well, the syntax *is* overloaded already :-) `import' serves two purposes: a) declare what modules you want to access b) declare how you want to name entities from these modules. Java drops a) - technically, you could write Java programs without any `import's, by using fully qualified names everywhere. Ada separates a) and b) - it has `with' for a) and `use' for b). (*) Why do we want a) for Haskell? Sure it's easier to implement (but that alone would be a bad excuse) the main reason is that it serves to document the code (namely, its dependecy on other modules), and allows to enforce some coding standards. (**) (*) The advantage (in my eyes) of having these concerns separated is that you can have local `use' statements, i. e. at the top of your module, you have to `with' all packages that you want to access, but you can write `use' statements (that bring their namespace into scope) not only at the top level, but also at local binding groups. (Is this the same as `open' in ML? - I confess I don't know ML.) (**) I use this feature in the following way: students send me their homework in the form of a Haskell module that contains a definition like solution :: Push_Down_Automaton solution = Push_Down_Automaton { states = .., transitions = .., .. } and I then (automatically) run a test program that imports their module. Of course I want to be sure that they don't do some hidden IO stuff and wipe my hard disk - but this is nicely ensured by Haskell's type and module system: the typechecker verifies that the type of `solution' is pure (and not IO something), and I can easily check textually that they don't `import IOExts', which would allow `unsafePerformIO'. (However, I can't simply remove hugs/lib/exts/IOExts.hs because `runhugs' wants it - I don't really see why?) Yes I see that this doesn't necessarily advance the discussion of the standard library layout. -- -- Johannes Waldmann ---- http://www.informatik.uni-leipzig.de/~joe/ -- -- joe@informatik.uni-leipzig.de -- phone/fax (+49) 341 9732 204/252 --
Simon Marlow wrote:
Actually, to address Malcolm's (understandable) confusion, the differences between "Haskell" and "Std" are mainly that entry into "Haskell" is much easier. For a new library, it could be brought in immediately but marked "non-standard" until such time as the community has discussed and agreed on an interface. In the meantime, compilers would be free to distribute the non-standard version for testing.
I've no objection to dropping the "Haskell" prefix and adding a prefix for the non-"Haskell" parts of the tree.
My inclination is certainly to drop the "Haskell." prefix. As an illustration, I was thinking about the various proposed Codec libraries, and came up with a separate hierarchy for them: Haskell FileFormat Compression Gzip Bzip2 Graphics Jpeg Ppm Audio Mp3 Video Mpeg The thing is that "Haskell.FileFormat.Graphics.Jpeg" just looks plain silly. It isn't a Haskell-specific file format. It is an external standard. Just "FileFormat.Graphics.Jpeg" is much more sensible, IMO. Regards, Malcolm
participants (4)
-
Johannes Waldmann -
Malcolm Wallace -
qrczak＠knm.org.pl -
Simon Marlow