- Libraries - Haskell.org

ANN: BUG FIX release of regex-tdfa-1.1.2
by ChrisK 05 May '09

05 May '09

Hello, While occasionally and slowly updating the future version of regex-tdfa I found a bug that exists in the released 1.1.1 version. It was just a matter of passing the wrong value into a function, so was easy to fix when I figured it out. The test case triggered an impossible "error" call and so I know this can kill a program that uses a buggy version of this library. Please upgrade regex-tdfa to version 1.1.2 which is available on hackage at: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/regex-tdfa Cheers, Chris

1 0

Eliminate/move class Alternative
by Ben Franksen 04 May '09

04 May '09

Hi, I propose to remove class Alternative and functions depending on it (optional, some, and many) from Control.Applicative. They can be moved into a separate module Control.Alternative if people desire such a class, but I doubt that it has many useful applications, at least in its present form. Rationale: Although the idea behind Alternative, i.e. generalize some of the functions commonly found in parser combinator libs, is a nice one, it doesn't work too well in practice, /even/ for the case that has inspired it (namely parsers). This is mostly due to the class method 'empty'. First of all, this is a bad name, /especially/ in the context of parsers, where 'empty' intuitively means 'recognize the empty sequence of tokens' which is definitely /not/ what Alternative's 'empty' means. (Indeed, this is normally be the meaning of 'pure' from class Applicative.) The 'empty' from Alternative rather means 'fail'. Yeah, I know that this name is already taken by class Monad. Many names would be better than 'empty', for instance 'none', or just 'failed'. (I'll stick with 'none' in what follows.) Second, and more important, is that some parser libs would like to, but cannot offer a sensible implementation for it. For instance, any error-correcting library of parser combinators (like those invented by Swierstra & Duponcheel) need to construct a valid result even in case of a failed parse. Thus, the user must be able to pass an argument to 'none' which would be possible only if it had a function type, like in class Alternative f where ... none :: a -> f a However, even this wouldn't be enough in practice because typically you will want to pass additional data, like an error message. How this can be properly generalized is something that needs more thought. Some of you might be tempted to say "if you don't like Alternative, just don't use it". However, not using it means additional effort, as I /would/ like to use class Applicative /and/ the <|> operator with its intended meaning, i.e. choice/alternative, and also the dependent functions (optional, many, etc). So currently I have to explicitly hide all the Alternative stuff, like this import Control.Applicative hiding (Alternative(..),optional,some,many) which is not nice at all. As a final point, class Alternative comes with no stated laws. While there are a number of standard classes where laws don't make much sense (like, e.g. Show, or Typeable), this is clearly not one of those cases: The docs say Alternative is "a monoid on applicative functors". This suggests associativity and left/right unit laws. However, this is most probably not the whole story, i.e. how are <|> and the ill-named 'empty' supposed to interact with the operations and laws for Applicative? Are we going to have the same dilemma here, as with MonadPlus vs. MonadZero/MonadOr, whatever? Conclusion: In its current form, class Alternative looks like it has been hastily cobbled together. Thus it has no place in Control.Applicative. Moving it into its own separate module is the least we can do. Cheers Ben

5 6

stats broken?
by Don Stewart 04 May '09

04 May '09

http://hackage.haskell.org/cgi-bin/hackage-scripts/stats 346 users have uploaded 0 versions of 0 packages. -- Users right, but package list misreported?

3 2

ANN: Takusen 0.8.4
by Alistair Bayley 01 May '09

01 May '09

ANN: Takusen 0.8.4 This is mainly a "get it working with ghc-6.10" release. Changes since 0.8.3: - ODBC support: some bug fixes, and basic support for Out-parameters. There is at least one major outstanding bug with Out-parameters, where marshalling a String output bind-variable doesn't work correctly (if it was modified, you still get the String you passed in back, rather than the new String). - Sqlite: bug fix for resource leak: if a command (like rollback or commit) raised an error, the prepared-statement handle was not closed. - cabal: requires cabal 1.6 (or later). With ghc-6.6 on Windows you will need a later cabal than 1.6.0.1, as there is a bug which prevents building (setup configure fails with "setup: fdGetMode: invalid argument (Invalid argument)"). Eric Mertens patch for ODBC on OS x. Greg Leclerq patch for cabal 1.6. Thanks also to Austin Siepp and Brian Callendar for their patches. - ghc-6.10: will build with ghc's 6.10, 6.8, 6.6. Note that Takusen won't work with ghc-6.10.2 out-of-the-box, because the time package is missing. If you install time manually then it should be OK (but this is untested). We use the new extensible exceptions, but we have done so by including it within our own source tree. This will make it easier to use Takusen with older ghc's, and reduces the number of external package dependencies. We have dropped support for 6.4. That's not to say Takusen isn't usable with 6.4, just that we no longer test that configuration. The release bundle: http://hackage.haskell.org/packages/archive/Takusen/0.8.4/Takusen-0.8.4.tar… The latest code: darcs get http://darcs.haskell.org/takusen Docs: http://darcs.haskell.org/takusen/doc/html/index.html If you have cabal-install, then this command should work: cabal install Takusen --flags="sqlite odbc oracle postgres" ... but it doesn't (at least for the version of cabal-install that I have) because the .tar.gz file I uploaded has a bogus checksum. A comprehensive description of API usage can be found in the documentation for module Database.Enumerator (look for the Usage section): http://darcs.haskell.org/takusen/doc/html/Database-Enumerator.html Note that the haddock docs won't build with cabal-1.6.0.2 or earlier. This is because our literate-haskell source files need to be properly preprocessed before being passed to haddock. At the time of writing, you'll need the cabal HEAD to build the docs. Future plans: - Output bind-parameters and multiple-result sets for ODBC - support for Blobs and Clobs - FreeTDS backend (Sybase and MS Sql Server)... maybe For those of you unfamiliar with Takusen, here is our HCAR blurb: Takusen is a DBMS access library. Like HSQL and HDBC, we support arbitrary SQL statements (currently strings, extensible to anything that can be converted to a string). Takusen's 'unique-selling-point' is safety and efficiency. We statically ensure all acquired database resources - such as cursors, connection and statement handles - are released, exactly once, at predictable times. Takusen can avoid loading the whole result set in memory, and so can handle queries returning millions of rows in constant space. Takusen also supports automatic marshalling and unmarshalling of results and query parameters. These benefits come from the design of query result processing around a left-fold enumerator. Currently we fully support ODBC, Oracle, Sqlite, and PostgreSQL.

2 1

ANN: bindings-0.1
by Maurício 01 May '09

01 May '09

Hi, http://hackage.haskell.org/cgi-bin/hackage-scripts/package/bindings This is a package aimed at library writers, not to the everyday Haskell programmer. This the beggining of my goal to create a set of packages like: bindings-common bindings-sqlite3 bindings-openusb bindings-gsl bindings-yourFavoriteLibrary Those are not going to be Haskell style bindings. Instead, what I want is to create a set of low level bindings to the best libraries available, so that if you want to write your Haskell wrap to a foreign library using the latest Haskell features, you can do that relying on low level bindings that are comprehensive, well tested and well behaved, and with all problems regarding building and portability already solved in the best way the community was able to do. Beneficts you get by using it: - If 10 people are trying to write modules over, say, 'gsl', all of then will help contribute with bug-hunting and thoughts to the common package 'bindings-gsl'. - Use your time to write cool experiences with GADTs and Template Haskell. Leave the boring low level stuff to 'bindings-*'. - HUnit tests can be created to all bindings. If you suggest one in a ticket, and it does hold, it will be added to a test package. If you know library 'foo' very well, you won't need to read the documentation for 'bindings-foo'. A set of guidelines ensure that all these low-level bindings can be used after the original library documentation. If you know the guidelines and you know 'foo', you can use 'bindings-foo' after reading in the worst case just a few comments. These guidelines, actually, are community driven. You can find the current set here: http://hackage.haskell.org/packages/archive/bindings/0.1/doc/html/Bindings.… If you want changes or features, just open a ticket at package home: http://bitbucket.org/mauricio/bindings What I really need now is help from libraries experts. If you know your favorite library very well (specially its build process and compile time options) and are willing to answer a few questions on how it works, I'll add a binding to it. This package is a byproduct of professional, paid work. If it achieves some success, it will be maintained in the long term and, if something important depends on it, I'm willing to give maintenance to someone better than me. Best, Maurício

3 4

Data.Map.assocs vs. Data.Map.toAscList
by Simon Hengel 30 Apr '09

30 Apr '09

In Data.Map we have three functions that do exactly the same thing (assocs, toAscList, toList), two of them (assocs, toAscList) by definition. Is this by design? What about deprecating at least one of them? Cheers, Simon Hengel

1 0

Takusen, postgres and boolean fields
by Sasha Shipka 25 Apr '09

25 Apr '09

Let say one has to do something similar to this: execDML $ cmdbind (sql "update some_table set some_boolean_field = ? where ...") [bindP True, ...] When I do it, I have an error: DBError ("42","804") 7 "ERROR: 42804: column \"some_boolean_field\" is of type boolean but expression is of type text ..."

1 0

Proposal: rename Data.Map.fromAscList to Data.Map.unsafeFromAscList
by Chris Eidhof 24 Apr '09

24 Apr '09

Hey all, I had some code where the function elems said a certain key was present, but looking it up returned a Nothing. After some debugging I found out that it did work if I used Prelude's lookup in combination with toList. After even more debugging it turned out there was a fromAscList somewhere deep down in my code where it should have been a fromList. Now, I know that I shouldn't have used fromAscList and that it was totally my fault. I also realize this is something that can't easily be checked using the type system, so I propose we do the next best thing: prefix the name with 'unsafe'. -chris

7 15

Re: [Haskell-cafe] HPong-0.1.2 fails to compile in Debian ghc 6.10.1
by trentbuck＠gmail.com 24 Apr '09

24 Apr '09

"Ahn, Ki Yung" <kyagrd(a)gmail.com> writes: >>> I think this is because the filename of the OpenGL shared library is >>> /usr/lib/libGL.so.1 rather than libGL.so. >> >> No. Do not manually create the symlink. It sounds like you don't >> have the -dev packages for OpenGL installed. > > I do already have the dev package libgl1-mesa-dev installed. [...] > It's just seems to the bug of libgl1-mesa-dev 7.4-2 packaging. It > doesn't seem to make the symbolic link which it claims to make. Duh The file exists in that package, so it seems to me the problem is on your workstation, rather than in the package. I suggest you just reinstall the package in question. You may also want to use cruft(8) to find out if any other files have gone missing, and run a fsck over your root partition. $ aptitude download -t unstable libgl1-mesa-dev [...] Get:1 http://mirror.internode.on.net unstable/main libgl1-mesa-dev 7.4-2 $ dpkg -x libgl1-mesa-dev_7.4-2_all.deb . $ find -name \*.so -ls 13003 0 lrwxrwxrwx 1 twb twb 10 Apr 24 10:41 ./usr/lib/libGL.so -> libGL.so.1 $

1 0

Re: [Haskell-cafe] HPong-0.1.2 fails to compile in Debian ghc 6.10.1
by John Goerzen 23 Apr '09

23 Apr '09

Ahn, Ki Yung wrote: > I don't know the exact reason but this should not fail since I have > Debian packaged ghc 6.10.1 and OpenGL-2.2.1.1 on my system. > > I think this is because the filename of the OpenGL shared library is > /usr/lib/libGL.so.1 rather than libGL.so. This is why we have two No. Do not manually create the symlink. It sounds like you don't have the -dev packages for OpenGL installed. You should install them and then you should be OK.

1 0