- Libraries - Haskell.org

GHC 6.6 Data.Tuple incompatibility
by John Goerzen 20 Oct '06

20 Oct '06

Hello, I had this code that worked in GHC 6.4: type CommandHandler = FTPServer -> String -> IO Bool type Command = (String, (CommandHandler, (String, String))) instance Eq Command where x == y = (fst x) == (fst y) instance Ord Command where compare x y = compare (fst x) (fst y) I am compiling with overlapping instances set. In GHC 6.6, this gives an error that Eq Command is a duplicate instance of one defined in Data.Tuple. Commenting out that instance causes the Ord Command instance to fail because there is no Eq instance for CommandHandler. After discussing it with Ian Lynagh, his conclusion was that the problem is that Data.Tuple was not compiled with overlapping instances support, and that it probably ought to be. He asked me to post here to see if everyone else felt the same way. Thanks, -- John

6 6

problems with Control.Applicative
by John Meacham 20 Oct '06

20 Oct '06

I really like the ideas behind Control.Applicative, but find it troublesome to use in practice. mainly, the minimalist choice of what to make class methods makes it very difficult to use for various applications. an example that is bugging me right now is that it is the _perfect_ fit for my frisby parser generator, however, I am unable to use it because the primitives 'pure' and 'fmap' and '<*>' which Control.Applicative is built on are not suitable low level primitives in practice (despite being sufficient in theory). The basic issue is that frisby relys on optimizing the parser before executing it, so any static information that can be gleaned from the built parser is very important to have available. however, the optimizer has no way to "see through" an 'fmap' since the functional argument is opaque as far as frisby is concerned. the rub is plain old fmap is almost never used, but all the useful things Control.Applicative provides are: in particular: (<$) :: Functor f => a -> f b -> f a (*>) :: Applicative f => f a -> f b -> f b (<*) :: Applicative f => f a -> f b -> f a optional :: Alternative f => f a -> f (Maybe a) some :: Alternative f => f a -> f [a] many :: Alternative f => f a -> f [a] (along with pure) are sufficient to encode pretty much every reasonable parser, and all of them have a special internal representation independent of 'fmap' it is rather disapointing that I can't make use of this library as it is in ghc when it is such a good fit for the application. Perhaps in the next revision we can move these (or a suitable subset) functions into the class? note I don't really consider RULES appropriate here, knowing that the optimizer will be able to see through these operations is vital for writing a parser that works at all. I would also like to see mapM_ as part of the class definition for traversable. For many monads it makes the difference between linear and constant space usage and space behavior of haskell programs is hard enough to reason about without having to worry about certain rules firing. Also, relying on rules means not being able to use polymorphic combinators built upon these primitives without taking special steps to ensure the rules can still fire. I really like the ideas behind Applicative,Traversable, and Foldable. but I feel these issues will unecesarrily hurt their utility. John -- John Meacham - ⑆repetae.net⑆john⑈

3 5

requesting specific Cabal version
by Bulat Ziganshin 17 Oct '06

17 Oct '06

Hello Haskell, what about adding to .cabal file ability to ask for specific Cabal version? it will allow to make incompatible changes between Cabal versions. program that uses services specific to Cabal 1.4.x, for example, will just ask for using this Cabal version and operation will go fine of course, it will require to have cabal 1.4.x, 1.6.x and other versions simultaneously installed - just like now it's possible (in ghc) to have different versions of any other lib installed together -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com

2 1

What's the story re. darcs.haskell.org?
by Adrian Hey 15 Oct '06

15 Oct '06

Hello folks, These may be dumb questions, but I'm afraid I haven't been keeping up with what's happening in the Haskell world recently.. So.. Is darcs.haskell.org the recommended place to start a new project? If so, who owns/runs this machine and how do I get access to it? What's the rationale for it's current organisation e.g. why is there a separate "packages" directory? (There seem to be packages elsewhere) and what's the "packages.hide" directory for? Thanks -- Adrian Hey

6 8

darcs patch: UNDO: Inline shift in GHC's Bits instanc... (and 1 more)
by Samuel Bronson 12 Oct '06

12 Oct '06

Sun Oct 8 22:09:06 EDT 2006 Samuel Bronson <naesten(a)gmail.com> UNDO: Inline shift in GHC's Bits instances for {Int,Word}{,8,16,32,64} Goes with my inliner patch. Thu Oct 12 08:55:53 EDT 2006 Samuel Bronson <naesten(a)gmail.com> * Use unchecked shifts to implement Data.Bits.rotate This should get rid of those cases, maybe lower the size enough that the inliner will like it? Should make Data.Bits.rotate much more attractive to the inliner, especially for Word types. (Zaps two redundant cases, *and* gets rid of all lets for Word types. Unfortunately the Int types still have lets for the call to int2Word#... probably this is not good, since that doesn't actually do work!)

1 0

Text.Regex
by John Meacham 12 Oct '06

12 Oct '06

I am converting programs to use ghc 6.6, I can't seem to find the routine to make a regular expression that returns whether the string passed in is a valid regular expression or not. The one provided just seems to bottom out when passed an odd regex. John -- John Meacham - ⑆repetae.net⑆john⑈

2 1

darcs patch: UNDO: Inline shift in GHC's Bits instances for {Int, Wo...
by Samuel Bronson 11 Oct '06

11 Oct '06

Sun Oct 8 22:09:06 EDT 2006 Samuel Bronson <naesten(a)gmail.com> UNDO: Inline shift in GHC's Bits instances for {Int,Word}{,8,16,32,64}

1 0

ANNOUNCE: Cabal version 1.1.6
by Duncan Coutts 11 Oct '06

11 Oct '06

The Haskell Cabal The Common Architecture for Building Applications and Libraries. http://haskell.org/cabal/ Cabal version 1.1.6 is now available. It is included in GHC version 6.6. For other Haskell implementations or older versions of GHC you can install it separately: DOWNLOAD: http://www.haskell.org/cabal/download.html http://www.haskell.org/cabal/release/latest/cabal-1.1.6.tar.gz DOCUMENTATION: http://www.haskell.org/cabal/release/latest/doc/users-guide/ http://www.haskell.org/cabal/release/latest/doc/API/ See both the README file and the changelog for interface changes: http://www.haskell.org/cabal/release/latest/changelog BUGS: Report bugs using our bug tracker: http://hackage.haskell.org/trac/hackage/newticket or to the libraries(a)haskell.org mailing list.

1 0

Haskell Packages 6.6?
by Isaac Jones 11 Oct '06

11 Oct '06

Hello good Haskell Hackers. We're pretty well along the way to getting cabal-install and friends working nicely. We've got almost 30 packages in the database. Let's imagine something that would be awesome. A set of Haskell packages which are all known to work together with a particular version of cabal (the one that GHC comes with), and a particular version of GHC. GHC version 6.6 will be released soon, and I think we should try to make this happen. Currently, we have a set of 27 "unstable" packages. They may or may not work with each-other and such: http://hackage.haskell.org/packages/ I just created an empty directory "testing". I propose that we start testing packages, starting with the cabal release candidate that'll go into GHC 6.6, and make sure they work nicely together. Once they're known to work, we can migrate them from the "unstable" directory to the "testing" directory. Once we have a sufficient collection of packages, and once ghc 6.6 is released, we can make a snapshot of this directory, call it "stable-6.6" or something. Then if you have ghc 6.6 and cabal-install, you should be able to "cabal-install p" for any package, and it'll definitely work. So what will we need for this to happen? 1. An installed version of ghc 6.6 on the hackage/darcs server. Maybe in a chroot or something. Maybe from the nightly build tree or the previous snapshot? 2. Some initial set of packages (maybe just cabal-install) to start off. 3. Some script that goes through and builds all of the "unstable" packages in dependency order. I think cabal-install can do this already. In fact, it would be ideal if we used cabal-install for this. 4. The script should also run ./setup haddock and ./setup test. If the packages seem to work w/ 6.6 and the other packages in "testing", it should get migrated from "unstable" to "testing". 5. A web interface (lemmih is working on it) 6. A script to upload packages to "unstable" (Paolo is working on it). 7. Someone to spearhead all of this! peace, isaac p.s. here are the packages we have currently in the database: parsedate-2006.6.4 Haskell library for parsing dates and times cgi-2006.8.5 A Haskell library for writing CGI programs HDBC-odbc-1.0.1.0 lambdabot-4.0 bzlib-0.2 Compression and decompression in the bzip2 format HDBC-sqlite3-1.0.1.0 hask-home-2006.3.23 Generate homepages for cabal packages XmlRpc-2006.6.26 hnop-0.1 Haskell No Operation fps-0.7 HDBC-postgresql-1.0.1.0 rss-2006.7.12 A library for generating RSS 2.0 feeds. HTTP-2006.7.7 Crypto-3.0.3 DES, Blowfish, AES, SHA1, MD5, RSA, X.509 Identity and Attribute Certificates, General ASN.1 Support, Base64, PKCS8, PKCS1v15, Hexdump, Support for Word128, Word192 and Word256 and Beyond, PKCS5 Padding, Various Encryption Modes e.g. Cipher Block Chaining all in one package.plugins-1.0 fastcgi-2006.8.5 A Haskell library for writing FastCGI programs zlib-0.2 Compression and decompression in the gzip and zlib formats HDBC-1.0.1 xhtml-2006.7.5 A Haskell XHTML combinator library darcs-graph-0.1 gd-2006.7.12 A Haskell binding to a subset of the GD graphics library hmp3-1.1 Djinn-2005.12.14 A haskell proof generator iconv-0.2 Perform character set conversion exif-2006.7.11 A Haskell binding to a subset of libexif HaXml-1.13.1 Utilities for manipulating XML documents

5 6

4th Cabal-1.1.6 release candiate
by Duncan Coutts 10 Oct '06

10 Oct '06

Hi all, I've put up a tarball for the fourth 1.16 Cabal release candidate: http://www.haskell.org/cabal/release/cabal-1.1.5.9.4/cabal-1.1.5.9.4.tar.gz I had been hoping that this would be the final RC. One bug I've uncovered is that building the haddock docs for HUnit when cpphs is installed fails. This is because the Distribution.PreProcess.Unlit.unlit code produces incorrect output for Test/HUnit/Lang.lhs. I could do with some help in fixing this. One can reproduce it with: cd libraries/HUnit cpphs -OLang.lhs Test/HUnit/Lang.lhs --noline --strip -D__GLASGOW_HASKELL__=605 -D__HADDOCK__ ghc -e 'interact (Distribution.PreProcess.Unlit.unlit "Lang.lhs")' < Lang.lhs > Lang.hs compare this with: ghc -E Lang.lhs -o Lang.hspp and try: diff Lang.hspp Lang.hs Cabal's unlit code is incorrectly dropping whitespace and actual tokens. See especially the last part of that file. I think this needs fixing asap since the cpphs code path gets used in preference to the ghc -E path if cpphs is installed. In this example the symptoms are not too bad as it seems only to be affecting haddock, but I fear it may break more seriously in other packages. Duncan

2 5