- Libraries - Haskell.org

Small library for LZF compression
by Einar Karttunen 12 Mar '05

12 Mar '05

Hello Here is a small library to handle compressing data with LZF. Is Codec.Compression.LZF the correct place? http://www.cs.helsinki.fi/u/ekarttun/Codec-Compression-LZF/ * BSD licenced * very fast, altough at the expense of compression ratio * No external dependencies - Einar Karttunen

2 1

RE: [Haskell] Hierarchical module namespaceextensionnotsufficiently flexible
by Simon Marlow 11 Mar '05

11 Mar '05

On 11 March 2005 10:56, Simon Peyton-Jones wrote: >> module A (qualified module A) where { f = 'f' } >> module B (module A) where { import A; ... } >> module C where { import B; ... } >> >> How do we refer to 'f' in B? I think the proposal suggests "A.f" or >> "A.A.f". How do we refer to 'f' in C? I think the proposal suggests >> that "f" >> is not in scope in C. >> The reason is that "B" does not export "f", because there is no "f" >> and "A.f" in scope. > > Correct, according to the rules I suggested. > >> It seems that we cannot re-export qualified exports using >> module-style exports. Is this the intended design choice, or am I >> missing >> something? > > Hmm. If you said > > module B( module A.A ) where { import A; ... } > > then since A.A.f and A.f are in scope, presumably A.f is exported, > just as it was from A. I'm not sure about that... the exact wording of the report is: The form "module M" names the set of all entities that are in scope with both an unqualified name e and a qualified name M.e If M is A.A, then both A.A.f and f need to be in scope, which they aren't in this example. But, going back to the original example: module A (qualified module A) where { f = 'f' } module B (module A) where { import A; ... } if we take e==A.f, then by the report's rule, module B exports A.f. So, the rule in the report works if we allow e to scope over qualified names. This is a bit of a hack, and it changes the meaning slightly even in the absence of 'qualified module' exports, so this might have some undesirable consequences. On the other hand, this interpretation does allow you to re-export *everything* from an imported module, including any names it exported via 'qualified module', which is what we want. To avoid confusion, here's a concrete proposal: ----------- 'qualified module A as B' exports the set of all entities e that are in scope as both e and A.e, as B.e. [John Meacham/SimonPJ suggestion] 'module A' exports the set of all entities e that are in scope as both e and A.e, as e. [Haskell 98] In both cases, e can scope over qualified names. [new addition] ------------ (restricting the exports with (..) or hiding (..) can be added too; I just left it out for simplicity). Here are some useful past threads: http://www.haskell.org/pipermail/haskell/2002-November/010662.html http://www.haskell.org/pipermail/haskell/2001-August/007674.html http://www.haskell.org/pipermail/haskell/2001-July/007515.html unfortunately I can't find exactly what I was looking for, namely the motivation that lead to the current clever rule for 'module M' exports. Cheers, Simon

1 0

RE: [Haskell] Hierarchical module namespaceextensionnotsufficiently flexible
by Simon Peyton-Jones 11 Mar '05

11 Mar '05

| module A (qualified module A) where { f = 'f' } | module B (module A) where { import A; ... } | module C where { import B; ... } | | How do we refer to 'f' in B? I think the proposal suggests "A.f" or "A.A.f". | How do we refer to 'f' in C? I think the proposal suggests that "f" | is not in scope in C. | The reason is that "B" does not export "f", because there is no "f" | and "A.f" in scope. Correct, according to the rules I suggested. | It seems that we cannot re-export qualified exports using module-style | exports. Is this the intended design choice, or am I missing | something? Hmm. If you said module B( module A.A ) where { import A; ... } then since A.A.f and A.f are in scope, presumably A.f is exported, just as it was from A. Simon

1 0

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 10 Mar '05

10 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