November 2007 - Libraries

Cabal and extra-ghci-libraries
by Olivier Boudry 27 Nov '07

27 Nov '07

Hi all, Is there a way to specifiy extra-ghci-libraries in the Cabal file? I found a bug report ( http://www.haskell.org/pipermail/cvs-libraries/2006-January/004778.html) saying that extra-ghci-libraries is now defined in Distribution.InstalledPackageInfo and that parsing code has been added, but it's not recognized if I add it to the cabal file. I built Exif for Windows and cannot use it in ghci (dll load error). The library is named libexif and the dll libexif-12.dll. I can workaround the problem by unregistering the module, adding extra-ghci-libraries to dist\installed-pkg-config and re-registering it again. But it would be easier if I could define the extra-ghci-libraries directly in the Cabal file. I modified the cabal file by just adding extra-ghci-libraries to it, but Cabal don't recognise that name: ... Ghc-options: -O2 -Wall extra-libraries: exif extra-ghci-libraries: libexif-12 include-dirs: C:/msys/1.0/local/include ... When configuring I get this: ... Warning: Unknown fields: extra-ghci-libraries (line 19) Fields allowed in this section: name, version, cabal-version, build-type, license, license-file, copyright, maintainer, build-depends, stability, homepage, package-url, synopsis, description, category, author, tested-with, data-files, extra-source-files, extra-tmp-files I'm using ghc-6.8.1 (the distributed version) and Cabal-1.2.2.0 Thanks, Olivier.

1 0

Re: [Haskell-cafe] expanded standard lib
by Bjorn Bringert 22 Nov '07

22 Nov '07

On Nov 19, 2007, at 23:13 , Henning Thielemann wrote: > > On Mon, 19 Nov 2007, Brandon S. Allbery KF8NH wrote: > >> On Nov 19, 2007, at 15:47 , Radosław Grzanka wrote: >> >>> If you look at the stability tag of ghc libraries you will see >>> that a >>> lot of them are marked as "provisional" (Network.URI for example) or >>> "experimental" (Control.Monad.Trans). >> >> This may not refer to what most people care about; the "experimental" >> stability of Control.Monad.Trans is related to its use of fundeps and >> undecidable instances, and the possibility (likelihood?) of its being >> switched to type families (which "shouldn't" change its user-visible >> interface, as I understand it). > > I like to see MTL split into a Haskell98 part and an advanced part. I > mostly use functionality which would nicely fit into a Haskell98 > interface > and find it annoying that by importing MTL my code becomes less > portable. Yes! Please! /Björn

7 8

Re: [Haskell-cafe] Stream fusion for Hackage
by Ross Paterson 22 Nov '07

22 Nov '07

[redirected from haskell-cafe] On Sat, Nov 17, 2007 at 06:31:08PM -0800, Don Stewart wrote: > Just a quick announce: the stream fusion library for lists, > that Duncan Coutts, Roman Leshchinskiy and I worked on earlier this year > is now available on Hackage as a standalone package: > > http://hackage.haskell.org/cgi-bin/hackage-scripts/package/stream-fusion-0.… The module Data.Stream clashes with a module in the Stream package (originally from the arrows package), and I think the latter is a more widely used notion of stream. Would you consider renaming Data.Stream and Control.Monad.Stream?

9 17

ANNOUNCE: Important bug fix for regex-pcre ByteStrings.
by ChrisK 20 Nov '07

20 Nov '07

Greetings, There are new version 0.82 and 0.93 of regex-posix. If you use regex-posix with Data.ByteString then you should upgrade to obtain a fix for a crash error. There are new version of regex-pcre available on hackage and the two darcs repositories: http://darcs.haskell.org/packages/regex-pcre/ for "stable" version 0.82 and http://darcs.haskell.org/packages/regex-unstable/regex-pcre/ for "unstable" version 0.93 The new version regex-pcre-0.82 replaces the broken version 0.81 The new version regex-pcre-0.93 replaces the broken version 0.92 I apologize for the error. I took the address of the ByteString to give to the pcre library by using unsafeUseAsCStringLen. I had not appreciated that this can return a null pointer for an empty ByteString. My code caught this null pointer and reported it, however, and so a good error message sent in by a user allowed me to quickly find and hopefully fix it. For version 0.92 the error also applied to Lazy ByteStrings. In case anyone is curious, the fixed code checks the pointer returned by unsafeUseAsCStringLen and replaces a null pointer to a non-null pointer to a private private bytestring "myEmpty" with the length set to 0 by "trim": > {-# INLINE asCStringLen #-} > asCStringLen :: ByteString -> (CStringLen -> IO a) -> IO a > asCStringLen s op = B.unsafeUseAsCStringLen s checked > where checked cs@(ptr,_) | ptr == nullPtr = B.unsafeUseAsCStringLen myEmpty (op . trim) > | otherwise = op cs > myEmpty = B.pack [0] > trim (ptr,_) = (ptr,0) This fix is motivated by desiring to ensure asCStringLen never passes a null pointer to "op" and that no memory copy operations are used. The safe "useAsCString(Len)" do not appear capable of returning a null pointer. Only "unsafeUseAsCString(Len)" on an empty bytestring might return a null pointer. -- Chris

1 0

PROPOSAL: Restrict the type of (^), (^^), and add genericPower, genericPower'
by Ian Lynagh 18 Nov '07

18 Nov '07

Hi all, This got a warm reception when I mentioned it in http://www.haskell.org/pipermail/haskell-cafe/2007-June/027557.html so I'm formally proposing it now. It's trac #1902: http://hackage.haskell.org/trac/ghc/ticket/1902 Note that this is a divergence from Haskell 98 (but the libraries already have a handful of small divergences, and Haskell' is just around the corner...). In my opinion, (^) has the wrong type. Just as we have, for example, (!!) :: [a] -> Int -> a genericIndex :: (Integral b) => [a] -> b -> a we should also have (^) :: (Num a) => a -> Int -> a genericPower :: (Num a, Integral b) => a -> b -> a (or some other function name). The same goes for (^^) (genericPower'). In my experience this would remove 99.9% of all defaulting (mostly where you write things like x^12 and 8^12), which means it's easier to get -Wall clean without having to put :: Int annotations everywhere. The impact to GHC's bootlibs and extralibs is minimal. In most cases we have things like 2^15, where Int is clearly fine, although it happens to be defaulted to Integer currently. In Data.Complex we have 2 cases of e^(2::Int) which can now be beautified. There are several cases where the type is inferred to be Int anyway. There are 3 files where we really do have an Integer, and it does matter. They are all for parsing numbers of the form 18e43, in base/Text/Read/Lex.hs, parsec/Text/ParserCombinators/Parsec/Token.hs and haskell-src/Language/Haskell/Lexer.hs. Initial deadline: 1 Dec 2007. Thanks Ian

8 15

haddock - links with fragments messed up
by apfelmus 18 Nov '07

18 Nov '07

Hello, the #-links to the references at the bottom of System.Random work fine in http://www.haskell.org/ghc/docs/latest/html/libraries/random-1.0.0.0/System… but not in http://hackage.haskell.org/packages/archive/random/1.0.0.0/doc/html/System-… Besides, I doubt that the links like System.Random#globalrng are intended to be rendered as such but rather as the title of the destination The global random number generator or something. Regards, apfelmus

2 1

Control.Category in base
by Bertram Felgenhauer 18 Nov '07

18 Nov '07

Hi, I played with ghc head today. I saw that its base library contains Control.Category, and Control.Arrow uses that. (I also saw the discussion about it on this mailing list. There weren't any serious objections; the discussion was far from focused though [*], and I found that the patch was applied rather abruptly. [1]) Anyway, here's what I found trying to compile HXT: 1) Control.Arrow doesn't export (>>>) and (<<<) anymore. 2) All user defined instances of Control.Arrow.Arrow break. The first one is easily fixed in the base library. The second one is more annoying. The required changes to HXT aren't that big - my patch inserts 30 lines and deletes 10 - but it'll be harder to make it compatible between several ghc versions. So all in all I'm rather unhappy that this patch went in, because it breaks existing code and personally I see little gain from it. Personally I'd like to see that patch reverted. However I realize that my complaint comes rather late, so if we decide to keep the patch we have to fix the first issue above to minimize breakage of other packages. regards, Bertram [*] a lot of mails in the thread went off tangents, extending the proposal to refining the class hierarchy of arrows. For reference, the thread starts at http://www.haskell.org/pipermail/libraries/2007-October/008291.html [1] http://www.haskell.org/pipermail/libraries/2007-October/008496.html

2 2

META-PROPOSAL: Documentation should be required to say when exports were introduced
by Ian Lynagh 17 Nov '07

17 Nov '07

Hi all, This is trac #1903: http://hackage.haskell.org/trac/ghc/ticket/1903 One of the nice things about, for example, PHP is that if you look at the documentation for one of its functions, e.g. http://www.php.net/manual/en/function.file-get-contents.php it tells you that file_get_contents is available in PHP >= 4.3.0. I propose that all exports in Haskell libraries should be required to have such a thing in their haddock documentation. For the current code we could either give the current versions as the date of introduction, or do some digging and put precise data in. Initial deadline: 1 December 2007. Thanks Ian

4 6

Adding a DSEL library to the hierarchy
by Alfonso Acosta 15 Nov '07

15 Nov '07

Hi, I'm expecting to publicly release the library of a Haskell-embedded Domain Specific Language, ForSyDe [1], in a few weeks time. However, I'm not still sure of what would be the most appropriate place in the hierarchy where to "plug" the library. To provide a little background, ForSyDe is aimed at modelling systems, and its implementation shares many concepts with Lava [2], the successful Haskell-embedded HDL. So the my question could be rephrased as "If you had to adapt the Lava library to the namespace extension, where would you put it?" My options are: 1) Use Language.ForSyDe But I don't know if embedded-languages really fit here since they don't explicitly "operate on source code" for the end-user (i.e. they don't transform or make computations over the representation of a language but rather provide the language itself) 2) Use the Org root name. However, we don't still have a domain, don't really think we'll have it any time soon, and besides, although the "Org" root name is proposed in the namespace extension, it doesn't really seem to be used in practice (tell me if I'm wrong). 3) Use our own root name: "ForSyDe". That's how it's currently implemented, but I guess that one of the purposes of having a namespace extension was precisely to avoid people adding their own root names. I would really appreciate any advice regarding this matter. Thanks in advance, Alfonso Acosta [1] http://www.imit.kth.se/info/FOFU/ForSyDe/ [2] http://www.cs.chalmers.se/~koen/Lava/

10 12

-- Cabal-1.2 and Haddock behaviour
by Andrea Rossato 11 Nov '07

11 Nov '07

Hi, I don't know whether this is going to be a question of just a way to express my deep frustration: I'm trying to maintain a Haskell tool chain for the Slackware GNU/Linux distribution and I'm now trying to update it to ghc-6.8.1. Packaging a Haskell library/application for a Linux distribution usually means writing a script. For Slackware we use SlackBuilds, shell scripts that perform all the needed steps for compiling and installing a package with all the needed documentation. I'm not going to stress the importance of software documentation. Now, as far as I understand, in the transition from Cabal-1.1 to Cabal-1.2, for which I want to express all my gratitude to the Cabal team since it seems to me a huge step forward in the right direction, a small and undocumented change happened: documentation used to be installed in "$PREFIX/share/packagename-version/doc/html" now, instead, it is installed in "$PREFIX/share/doc/packagename-version/html" Almost the same, you may say. Probably someone thought it was cooler this way. Maybe someone else, in the future, may think differently and change it once again. It doesn't matter if a shell script expects to find the documentation somewhere. It doesn't matter if tens, or thousands, or even millions of shell scripts will be broken. We are work in progress, after all. Nothing is required to be stable, and so on and so forth... I think I'm going to give up, actually. If every .x update requires all that effort on my side for packaging the software I'm compiling for myself in such a way that others may find useful too, well, I'm not that committed to sharing and all that kind of stuff. Or, at least, I prefer to use my limited time for having fun as everyone seems to do in the Haskell community: just write that wonderfully concise and nice code! Haskell is self documenting, if you know what it means, if you are an Haskeller. And I'm coming to think I am an haskeller, after all. Why should I care about the other Slackware users? I know Cabal quite well and it is very powerful to enable me to managing all my libraries and applications, and everything almost effortlessly... You did a great job! Thanks Andrea

2 3