- Libraries - Haskell.org

RE: Legal package names
by Simon Marlow 11 Mar '05

11 Mar '05

On 11 March 2005 07:44, Adrian Hey wrote: > On Thursday 10 Mar 2005 1:47 pm, Malcolm Wallace wrote: >> I think it is something to do with the regular expression describing >> legal Cabal package names. A package name basically has three >> components: name, version number, and tag. The middle part, the >> version number, may contain dots, but I imagine the outer parts, >> the name and tag, may not? > > Thanks. What's a "tag", BTW? (Cabal docs don't mention it AFAICS, > but maybe I've missed something). The tag is part of the version: a version has the form version ::= digit+ ('.' digit+)* ('-' alphanum+)* Tags are largely ignored by Cabal, they're just for adding useful information to a version (eg. you might add a tag for platform type, release date, or compiled-by). In particular, the tags are ignored in the ordering relation between versions. A package name currently has the form pkgname ::= alphanum+ ('-' alphanum+)* and a package identifier has the form pkgid ::= pkgname ['-' version] Allowing dashes in package names is quite common (look at the names of RPMs on a Linux system, or the packages on a FreeBSD system, for example). We already have problems with pkgids like "foo-1", which is ambiguous. The tools reject ambiguous package identifiers. Allowing '.' in a package name would introduce more possibilities for ambiguity: even 'foo-1.0' becomes ambiguous. So it's not simply a case of generalising the syntax slightly: we need to specify how to resolve the ambiguity. Restricting the components of the package name to start with an alphabetic character only seems a possibility. Cheers, Simon

1 0

Re: Legal package names
by Adrian Hey 11 Mar '05

11 Mar '05

Moving from ghc-users.. On Monday 07 Mar 2005 3:44 pm, Adrian Hey wrote: > Hello, > > I've been trying 6.4 on one of my libraries and it seems it doesn't > like my package names. I give my packages the same name as their > place in the module hierarchy. > > e.g. > name: Data.COrdering > > Is there any reason why this shouldn't be allowed? It seems > so much more convenient this may, at least for packages > the have just one root module. Well (trying to answer my own question), I guess the reason for this change is probably Cabal related, so perhaps someone here can explain. Thinking about this, there doesn't seem to be any good reason for separate package names at all. It just means we have two name space problems instead of one (having to avoid package name and hierarchical module name clashes). Why not just use the root in the hierarchical module name space as the package name? (or use the package name as the root in the hierarchical module name space). So the OpenGL package should be called "Graphics.Rendering.OpenGL", or drop the "Graphics.Rendering" prefix, keep OpenGL as the package name and name its modules accordingly (OpenGL.GL, OpenGL.GLU etc..). (I think it would be rather nice to be able to tell what package a module came from by looking at it's name.) But I definitely think the most obviously appropriate (I.E. consistent with hierarchical module scheme) package names like "Data.COrdering" should at least be legal. Regards -- Adrian Hey

2 2

RE: Legal package names
by Simon Marlow 11 Mar '05

11 Mar '05

On 10 March 2005 12:51, Adrian Hey wrote: > Well (trying to answer my own question), I guess the reason for > this change is probably Cabal related, so perhaps someone here > can explain. > > Thinking about this, there doesn't seem to be any good reason for > separate package names at all. It just means we have two name > space problems instead of one (having to avoid package name and > hierarchical module name clashes). > > Why not just use the root in the hierarchical module name space > as the package name? (or use the package name as the root > in the hierarchical module name space). > > So the OpenGL package should be called "Graphics.Rendering.OpenGL", > or drop the "Graphics.Rendering" prefix, keep OpenGL as the package > name and name its modules accordingly (OpenGL.GL, OpenGL.GLU etc..). > (I think it would be rather nice to be able to tell what package > a module came from by looking at it's name.) > > But I definitely think the most obviously appropriate (I.E. consistent > with hierarchical module scheme) package names like "Data.COrdering" > should at least be legal. Sorry for not getting back to you sooner on this one. I agree that package names should be allowed to include '.'. Unfortunately for no good reason they don't, and it's too late for 6.4 :-( There are some good reasons why package names are separate from the module hierarchy. The archives have lots of old discussion on this topic, but IIRC it can be boiled down to these points: - there can be multiple packages with the same modules (eg. multiple versions of a package) - we don't want administrativia (eg. versions) to be part of the module hierarchy: the hierarchy is intended to organise by *functionality* only. Cheers, Simon

2 1

RE: [Haskell] Hierarchical module namespace extensionnotsufficiently flexible
by Simon Marlow 10 Mar '05

10 Mar '05

On 10 March 2005 00:14, Iavor Diatchki wrote: > On Wed, 9 Mar 2005 23:09:26 -0000, Simon Marlow > <simonmar(a)microsoft.com> wrote: >> I'm not in favour of this proposal, i.e. point (2) from your original >> message[1]. I don't think I fully understand it: is there a mistake >> in the last example of point (2)? The other examples can be >> achieved in a clearer way with a 'qualified module' export. >> >> [1] >> http://www.haskell.org//pipermail/libraries/2005-March/003404.html > I am not sure if it is a good idea either. There indeed was a bug in > the last example of both (2) and (3), the imports should both have an > "as T" in the end. > > The difference between (2) and (3) is what _unqualified_ names get > introduced in the importing module. In (2) one would get unqualified > names as usual, but the qualified names would have an additional > prefix. In (3) there is no way to get unqiualified names at all. I > am not sure that there are situations where (2) is neccessary, but I > don't think this effect can be achieved using only (3). I agree that > we should perhaps go with the simplest and only have alternative (3). I challenge you to find something you can do with (2) but not with the existing module system + 'qualified module' exports. On the other hand, if you don't care about (2), can we forget about it and simplify the discussion? I don't think anyone else was asking for it. Cheers, Simon

2 1

RE: [Haskell] Hierarchical module namespace extensionnotsufficiently flexible
by Simon Marlow 09 Mar '05

09 Mar '05

On 09 March 2005 18:34, Iavor Diatchki wrote: > On Wed, 9 Mar 2005 09:53:35 -0000, Simon Marlow > <simonmar(a)microsoft.com> wrote: >> On 09 March 2005 08:46, Simon Peyton-Jones wrote: >> >>> That wasn't what I intended (though it would be possible) At >>> present module M( module A ) where ... >>> does not cause qualified names in the importing scope: >>> import M as T -- introduces only f, g, T.f, T.g >>> Simply using "as" on the export clause would not change that, would >>> it? In fact, as John M says, it'd be a non-op. > > Just clarifying what I meant here.... Adding an "as" would not be a > no-op. Notice that in the example I wrote it changed what qualified > names got introduced to the importing module, but did not affect the > unqualified names. This breaks the symmetry with imports a little > as these two are not the same: > module M (module A) where ... (behaves as usual) > module M (module A as A) where ... (this one would add "A" to > qualified names in imports) > which differs from the behavior of "as" on imports. I'm not in favour of this proposal, i.e. point (2) from your original message[1]. I don't think I fully understand it: is there a mistake in the last example of point (2)? The other examples can be achieved in a clearer way with a 'qualified module' export. [1] http://www.haskell.org//pipermail/libraries/2005-March/003404.html [snip] > This is fine by me. If we want to just have the one possible meaning, > do we really need to use the "qualified" keyword at all? It seems to make > things more verbose, and I am not sure if the perceived symmetry with > imports will help or confuse programmers. Yes, the qualified keyword is necessary to distinguish 'qualified module M' from 'module M' in the export list - they would mean different things. >> I'd like to question whether specifying the entities in a qualified >> module export is really necessary. Most examples can be rewritten >> using restricted imports instead, eg.: >> ... >> The exception (as Simon already pointed out to me) is when you're >> exporting entities defined by the current module, with a qualifier. >> You can't rewrite that unless the implementation supports >> self-imports, which I believe is tricky to implement (GHC doesn't >> support it). > > I agree with this at least to some extent. I have often needed the > "hiding" version of these exports, e.g. when I'd like to export > everything from a module except a few private functions. > Currently I need to enumerate everything but the few functions. I > guess I could introduce a separate module for these functions, but > this is not very nice. Also without support for recursive modules > this will not work if the private functions need to use some of the > public functions. It sounds like you're supporting the addition of a 'hiding' clause for module exports? I was actually advocating the opposite! Cheers, Simon

2 1

RE: [Haskell] Hierarchical module namespace extensionnotsufficiently flexible
by Simon Marlow 09 Mar '05

09 Mar '05

On 09 March 2005 08:46, Simon Peyton-Jones wrote: > That wasn't what I intended (though it would be possible) At present > module M( module A ) where ... > does not cause qualified names in the importing scope: > import M as T -- introduces only f, g, T.f, T.g > Simply using "as" on the export clause would not change that, would > it? > In fact, as John M says, it'd be a non-op. > > In short, my suggestion is that using "qualified" in an export list > is the *only* way to introduce extra module qualifiers in an > importing scope. Using "as" in an export item would serve only to > change what the qualifier is, and is therefore irrelevant if you > don't have "qualified". Yes. I'd like to question whether specifying the entities in a qualified module export is really necessary. Most examples can be rewritten using restricted imports instead, eg.: module A ( qualified module B (f,g) ) where import B rewrites as: module A ( qualfied module B' as B ) where import B (f,g) as B' import B and I'm sure you can see how to rewrite the others. Sure, the first version is more readable, but I question whether we need the extra generality. It's extra rules in the syntax and extra work that the implementation has to do. The exception (as Simon already pointed out to me) is when you're exporting entities defined by the current module, with a qualifier. You can't rewrite that unless the implementation supports self-imports, which I believe is tricky to implement (GHC doesn't support it). Cheers, Simon

2 1

RE: [Haskell] Hierarchical module namespace extensionnotsufficiently flexible
by Simon Peyton-Jones 09 Mar '05

09 Mar '05

| 1. The one has nothing to do with qualified names, and allows | explicit enumerations in module-style exports,e.g. | module M (module A(f,g)) where ... | I think the semantics of this should be the same as for "module A", | except with an additional filtering that we only export those entities | whose original unqualified name matched "f" and "g". | | Related to this, it might be nice to also allow "hiding" declarations | as well. Then we can write things like: module M (moudle M hiding (f)) where... I agree. | 2. Another proposal is to allow "as" clauses for "module"-style exports, e.g. | module M (module A as P) where ... | This gives an exporting module some control over how qualified names | in the importing module are constructed, e.g. if "f" and "g" were | exported from "M": | import M as T -- introduces the names "f","g", "T.P.f", "T.P.g" That wasn't what I intended (though it would be possible) At present module M( module A ) where ... does not cause qualified names in the importing scope: import M as T -- introduces only f, g, T.f, T.g Simply using "as" on the export clause would not change that, would it? In fact, as John M says, it'd be a non-op. In short, my suggestion is that using "qualified" in an export list is the *only* way to introduce extra module qualifiers in an importing scope. Using "as" in an export item would serve only to change what the qualifier is, and is therefore irrelevant if you don't have "qualified". Simon

1 0

RE: [Haskell] Hierarchical module namespace extension notsufficiently flexible
by Simon Marlow 08 Mar '05

08 Mar '05

On 08 March 2005 15:39, Malcolm Wallace wrote: > "Simon Marlow" <simonmar(a)microsoft.com> writes: > >>> module R( qualified module Q( f,g ) ) where >>> f = ...; g = ... >> >> If we're going to allow (... items ...) at all, then I suggest >> instead that the last example be written: >> >> module R( qualified module R(f,g) as Q ) where >> f = ...; g = ... > > I initially understood the first form to mean something different, > although admittedly the original example does not actually illustrate > it: > > module R( f,g, qualified module Q( f,g ) ) where > import qualified Q (f,g,h) > f = ...; g = ... > > That is, the subordinate items mentioned in conjunction with the > qualified export are a subset of those imported from Q, not those > defined in R. Within the subordinate clause of the export list, they > do not need further qualification since they belong unambiguously to > Q. Yes, I think we're all on the same page here. That's my understanding of the meaning of 'qualified module Q(f,g)' too, and I think it's what Simon intended. Cheers, Simon

3 2

Chestit 8-mi mart
by Iavor Diatchki 08 Mar '05

08 Mar '05

Zdraveyta Mayko, i Babo, Pisha vi na barzo da vi chestitya 8-mart! Nadyavam se da izlezeta nyakada da go otpraznuvate. Makar che e mejdunaroden den na jenata, amerikancite ne go praznuvat ne znam zashto. Az imam dosta rabota i zatova ne sam pisal otdavna, no mislya da vi zvanna po telefona prez weekenda. Minalata sedmica pravih prezentaciya na edna ideya po koyato rabotya i mislya che mina dobre. Ayde ciao zasega i shte si pogovorime po telefona. Celuvki Iavor

1 1

RE: [Haskell] Hierarchical module namespace extension notsufficiently flexible
by Simon Marlow 08 Mar '05

08 Mar '05

On 08 March 2005 14:36, Simon Peyton-Jones wrote: >> Well, as an author of the Hierarchical Modules addendum, and as a >> compiler maintainer, I am already reasonably convinced of the utility >> of this suggestion. It does significantly alter the semantics >> of import/export, in a way that the original Hierarchical Modules >> addendum does not, but as Iavor pointed out, this is not necessarily >> a bad thing. >> >> What we now need is a precise definition. After that, contributions >> of code to implement it would also be welcome. :-) > > Simon and I agree. If someone is willing to evolve a detailed design, > presumably based on the current Hierarchical Modules addendum, and > that design met with general consent, we'd implement it in GHC. > (Provided it didn't require massive changes, which would probably > form part of the design criteria.) > > My current design is sketched below, but I have not thought about it > as long as others have. > > Simon > > > Syntax: Extend the export syntax to allow, as an export item, > > qualified module M [( ...items... )] [as N] > > > Examples: > > module P( qualified module Button ) where > import GTK.This.That.Button as Button > > module Q( > qualified module GTK.This.That.Button as Button > ) where > import GTK.This.That.Button > > module R( qualified module Q( f,g ) ) where > f = ...; g = ... >From the last example is looks like (... items ...) are understood in the context of the top-level scope of the current module. That looks a bit strange to me, because it's different from an import declaration where the (... items ...) are entities exported by the named module. If we're going to allow (... items ...) at all, then I suggest instead that the last example be written: module R( qualified module R(f,g) as Q ) where f = ...; g = ... Cheers, Simon

2 1