March 2005 - Libraries

RE: Libraries needing documentation
by Simon Marlow 15 Mar '05

15 Mar '05

On 15 March 2005 10:11, Graham Klyne wrote: > At 09:44 15/03/05 +0000, Simon Marlow wrote: >> Or perhaps HTML (XHTML to be precise) should just be a special case >> of an XML library? > > Hmmm... from my work with HaXml, I'm not wildly enthusiastic about > XHTML being a special case, though it's hard to see how this can be > completely avoided when working with old-style HTML. I'd rather see > XHTML layered on an XML library. Sorry, that's what I meant: provide an XML library with an XHTML instance. Cheers, Simon

1 0

RE: Libraries needing documentation
by Graham Klyne 15 Mar '05

15 Mar '05

At 09:44 15/03/05 +0000, Simon Marlow wrote: >Or perhaps HTML (XHTML to be precise) should just be a special case of >an XML library? Hmmm... from my work with HaXml, I'm not wildly enthusiastic about XHTML being a special case, though it's hard to see how this can be completely avoided when working with old-style HTML. I'd rather see XHTML layered on an XML library. #g ------------ Graham Klyne For email: http://www.ninebynine.org/#Contact

1 0

Cabal questions
by Iavor Diatchki 15 Mar '05

15 Mar '05

Hello, The other day I tried to use the Cabal library for the first time, and mostly it worked, but I have the following questions that perhaps someone can help me with: - In the .cabal file there is a field for Exported modules, is there a way to specify that all modules should be exported, or at least a "hiding" version, where I can specify: "export all modules, but the ones in this directory", etc. If not, it seems that I have to write some sort of a script to generate the .cabal file so that I don't accidentally forget some modules, and so again I need a Makefile even for the simplest libraries. - I like the "generate source tarball feature", but can one customize it a bit? Typically when I generate a source tarball I don't just include the source files, but READMEs, examples, documentation etc. Is there a way to specify this? -Iavor

2 1

RE: bracketOnError, while, forever
by Simon Marlow 14 Mar '05

14 Mar '05

On 09 February 2005 12:00, Ross Paterson wrote: > On Wed, Feb 09, 2005 at 11:50:48AM -0000, Simon Marlow wrote: >> On 08 February 2005 12:33, Thomas Jäger wrote: >> >>> First of all >>>> -- Cale Gibbard >>>> comparing :: (Ord a) => (b -> a) -> b -> b -> Ordering >>>> comparing p x y = compare (p x) (p y) >>> fits nicely with the ...By functions from Data.List. >> >> sortBy (comparing fst) >> >> is just too cute not to have. Any objections? > > only that it's not clear where to put it. Just attempting to empty my inbox... we never resolved this one. Perhaps there should be Data.Ord (and Data.Eq for that matter), and then we'd have an obvious place to put comparing? Cheers, Simon

5 4

Useful Numeric Functions
by Ashley Yakeley 14 Mar '05

14 Mar '05

I'm thinking something like these should be in the standard libraries in some form. The first (fromReal) is pretty straightforward. The others come from the observation that there's no reason why the arguments to div and mod should be integers. The basic formulae are these: a `div` b = floor (a/b) a `mod` b = a - (a div b) * b As you can see, div should return an integer (because that's what floor does), but everything else generalises to real. I suspect my implementations are not optimal. -- | similar idea to "fromIntegral" fromReal :: (Real a,Fractional b) => a -> b fromReal = fromRational . toRational -- | like "div", but with a more useful type div' :: (Real a,Integral b) => a -> a -> b div' n d = floor ((toRational n) / (toRational d)) -- | like "divMod", but with a more useful type divMod' :: (Real a,Integral b) => a -> a -> (b,a) divMod' n d = (f,n - (fromIntegral f) * d) where f = div' n d -- | like "mod", but with a more useful type mod' :: (Real a) => a -> a -> a mod' n d = n - (fromInteger f) * d where f = div' n d -- Ashley Yakeley, Seattle WA

2 1

Non-H98 crusade, contd.
by Sven Panne 13 Mar '05

13 Mar '05

Apart from the recent Monoid problems, I'm a bit concerned about the non-portable ReadP creeping into some modules, making them non-H98. This affects e.g. Cabal and even something as simple as System.Info (which incorrectly claims that is portable). IMHO we should really keep at least those portable, even if this would involve a little bit more work. Is local universal quantification really needed for those simple parsing tasks? It looks a bit like overkill here... Cheers, S.

15 30

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