June 2009 - Libraries

Re: [Haskell-cafe] nubBy seems broken in recent GHCs
by Cale Gibbard 10 Jun '09

10 Jun '09

2009/6/6 Bertram Felgenhauer <bertram.felgenhauer(a)googlemail.com>: > Interesting. This was changed in response to > > http://hackage.haskell.org/trac/ghc/ticket/2528 > > | Tue Sep 2 11:29:50 CEST 2008 Simon Marlow <marlowsd(a)gmail.com> > | * #2528: reverse the order of args to (==) in nubBy to match nub > | This only makes a difference when the (==) definition is not > | reflexive, but strictly speaking it does violate the report definition > | of nubBy, so we should fix it. > > It turns out that 'elem' differs from the report version and should > have its comparison reversed. Of course that would only ever matter > for broken Eq instances. > > However, the report also states that the nubBy function may assume that > the given predicate defines an equivalence relation. > > http://haskell.org/onlinereport/list.html#sect17.6 > > So I'm not sure there's anything to be fixed here - although backing > out the above patch probably won't hurt anybody. > > Bertram Yeah, while most Eq instances really do define an equivalence relation (at least extensionally), and the Report authors probably thought in terms of an equivalence relation (even going so far as to say that nubBy can assume its parameter is one, which I think was a mistake), I think nubBy has a much more general use. It does a generalised kind of sieving, specifically, nubBy f xs is the unique subsequence of xs that: 1) Has the property that if x and y are elements such that x occurs before y in it, then f x y is False. 2) The sequence of indices of selected elements is lexicographically minimum for all subsequences satisfying condition 1. (That is, it always picks the earliest elements possible.) I think this is how it ought to be specified. Similarly, groupBy f xs is (and should be) the unique list of contiguous sublists of xs such that: 1) concat (groupBy f xs) = xs 2) If x is the head of any of the sublists and y is any other element of that sublist, then f x y 3) The sequence of lengths of the sublists is lexicographically maximum for all lists satisfying the first two properties (That is, it always prefers adding elements to an earlier group to starting a new group.) - Cale

2 1

Re: [Haskell-cafe] nubBy seems broken in recent GHCs
by Duncan Coutts 10 Jun '09

10 Jun '09

On Sat, 2009-06-06 at 18:39 +0200, Bertram Felgenhauer wrote: > Interesting. This was changed in response to > > http://hackage.haskell.org/trac/ghc/ticket/2528 > > | Tue Sep 2 11:29:50 CEST 2008 Simon Marlow <marlowsd(a)gmail.com> > | * #2528: reverse the order of args to (==) in nubBy to match nub > | This only makes a difference when the (==) definition is not > | reflexive, but strictly speaking it does violate the report definition > | of nubBy, so we should fix it. > > It turns out that 'elem' differs from the report version and should > have its comparison reversed. Of course that would only ever matter > for broken Eq instances. > > However, the report also states that the nubBy function may assume that > the given predicate defines an equivalence relation. > > http://haskell.org/onlinereport/list.html#sect17.6 > > So I'm not sure there's anything to be fixed here - although backing > out the above patch probably won't hurt anybody. Seems to me the obvious solution is to revert the nubBy change and then fix nub so that so that we still get nub = nubBy (==) (which is what ticket #2528 was complaining about in the first place). We need more SmallCheck properties for the List module! When Don and I were testing our stream versions of the List module we uncovered several of these little weirdnesses which were underspecified in the report, or different between the report and common implementations. For example I seem to recall that genericTake and take do not coincide when their types coincide. Duncan

1 0

purely functional lazy non-deterministic programming
by Sebastian Fischer 08 Jun '09

08 Jun '09

Dear Haskell and Curry programmers, there is now a Haskell library that supports lazy functional-logic programming in Haskell. It is available from http://sebfisch.github.com/explicit-sharing and can be obtained from Hackage using cabal-install. The project page links to tutorials that explain how to use the library and to an ICFP'09 paper (joint work with Oleg Kiselyov and Chung-chieh Shan) that explains the implemented ideas in depth. Have fun! Sebastian -- Underestimating the novelty of the future is a time-honored tradition. (D.G.)

1 0

nubBy seems broken in recent GHCs
by Cale Gibbard 06 Jun '09

06 Jun '09

According to the Report: nubBy :: (a -> a -> Bool) -> [a] -> [a] nubBy eq [] = [] nubBy eq (x:xs) = x : nubBy eq (filter (\y -> not (eq x y)) xs) Hence, we should have that nubBy (<) (1:2:[]) = 1 : nubBy (<) (filter (\y -> not (1 < y)) (2:[])) = 1 : nubBy (<) [] = 1 : [] However in ghc-6.10.3: Prelude Data.List> nubBy (<) [1,2] [1,2] The order of the parameters to the function which is passed to nubBy is *important* since the function might not be an equivalence relation. nubBy is more generally useful for sieving even when the relation is not symmetric. groupBy, for a similar reason, has applications for grouping beyond those provided by equivalence relations, and I think we should be able to rely on its behaviour. Moreover, I contend that the Report's order is more sensible, since the parameters to the relation stay in the left-to-right order in which they occurred in the list. It would be good if this could get fixed for 6.10.4. - Cale PS: There is actually another implementation of groupBy which would *also* be useful to have, but which is exactly the same for equivalence relations as groupBy, and it compares adjacent elements rather than the first element of a group with successive ones. (groupByAdjacent or something would be a reasonable name.) An implementation of it can be found here: http://hpaste.org/fastcgi/hpaste.fcgi/view?id=5595

1 0

Re: time library dependencies
by Ashley Yakeley 04 Jun '09

04 Jun '09

If you care at all about Haskell 98 compatibility, now would be a really good time to speak up. Remember, silence implies consent. -- Ashley Ashley Yakeley wrote: > I'm looking to update the time library in response to various requests. > Right now it has some weird split-base 2/3 dependency thing going on, > and uses only FFI and CPP language extensions. > > Will it cause anyone any problems if > > * it depends >=base-4.1? > * it requires GeneralizedNewtypeDeriving and DeriveDataTypeable to build? > > The Haskell language is kind of a moving target right now. >

10 29

My attempt at Haskell USB
by Maurício 04 Jun '09

04 Jun '09

A few months ago, I declared here that I intended to get USB working in Haskell. After a lot of thinking on what could be a realistic goal, this is where I've got: http://hackage.haskell.org/packages/archive/bindings-libusb/0.0.3/doc/html/… I know this is probably a disapointment for most of you, but please try to understand the concept at the base package: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/bindings-common-… What I'm doing is to group under these bindings-* packages a Haskell link to well established libraries. But Bindings.* modules are not supposed to be Haskell code, but C (or other languages, in the future?) code in Haskell. You may ask what good is this. Well, suppose you want to write a nice module, using GADTs, Template Haskell and STM, using functionality from libusb or other libraries bindings-* have links to. Just learn to use Foreign.Ptr, Foreign.Marshable and friends. Forget about the details of FFI, it's already done, and it's really time consuming and boring, believe me, I've been there. Are there other libraries you would like to have low-level bindings for? Just tell. I've organized and standardized things in a way that it is really easy to add other libraries really fast. Here is another example: http://hackage.haskell.org/packages/archive/bindings-sqlite3/0.0.2/doc/html… Hope you can use it somehow. This is my attempt in doing something that may be usefull to others after all the great and friendly support I've had from this community in the last month and years. Thanks for you all, gtk2hs guys specially. Best, Maurício

3 3

Announce: second alpha release of OSX haskell platform installer
by Gregory Collins 04 Jun '09

04 Jun '09

Hi all, The second build of the OSX installer is now available for limited testing: http://gregorycollins.net/static/haskell/haskell-platform-2009.2.0.1-alpha2… Apparently this one actually works. Big thanks to Simon Michael for helping me debug the installer issue -- haddock depends on ghc-paths, which wasn't in the haskell-platform.cabal list. I ended up just removing haddock from the installer since it's included with GHC. A before-and-after from Simon on a fresh GHC install: http://gist.github.com/123233 If nobody finds any issues with this version of the installer, I'll bundle up a .dmg file for release. G. -- Gregory Collins <greg(a)gregorycollins.net>

4 4

Notice for package authors
by Duncan Coutts 04 Jun '09

04 Jun '09

Package authors, We are about to add an additional quality check in the Hackage upload process that will affect many packages. Hackage will require an upper bound on the version of the base package and reject packages that omit it. Lots of packages currently specify: build-depends: base or build-depends: base >= 3 This is bad. There is no way for the tools to discover if you mean base 3 or 4 and yet most packages break when we pick the wrong one. You must specify an upper bound so that your package does not break when the next major version of the base library is released. For example, if you've tested with base 3 and 4 then use: build-depends: base >= 3 && < 5 Or if it needs version 4 then use: build-depends: base == 4.* Background ---------- When base 4 was released with ghc-6.10.x the vast majority of packages would have broken were it not for a compatibility shim that we added to the cabal-install tool. It defaulted to picking base 3 when the version constraints did not otherwise specify the use of base 4. The same trick will not work when base 5 is released because it will likely not be possible to continue to ship base 3. It is also important that we start to move towards making the majority of packages compatible with base 4. cabal-install changes --------------------- We will shortly release a minor update to cabal-install to change the way it picks between base 3 and 4. Currently if it has the choice it picks version 3. However that is not optimal for cases like: build-depends: base >= 3 && < 5 where it is clear that it is supposed to work with both. In this case we should not be pessimistic in going with the old base 3 and should instead pick base 4. More precisely, we will only apply the compatibility shim when the version is unbounded above. When it is bounded above, as Hackage will soon require, the normal preference to use the latest version applies. If you'd like to help us check this feature is working properly then grab the latest darcs version of cabal-install (which needs the latest darcs version the Cabal lib). See also http://hackage.haskell.org/trac/hackage/ticket/485 Duncan

3 5

Where should whenJust go?
by Ahn, Ki Yung 04 Jun '09

04 Jun '09

Dear Haskellers, I happened to defined a function whenJust whose definition is like this: > whenJust :: (Monad m) => (a -> m ()) -> Maybe a -> m () > whenJust = maybe (return ()) while I was writing a fun utility to upload to hackage. I had a strong feeling that someone must have defined this already, so I used Hayoo, and I did find it: XMonad.Core.whenJust :: Monad m => Maybe a -> (a -> m ()) -> m () The argument order is different I believe it is dong the same thing. Shouldn't we add add whenJust to more general library regarding Monad and Maybe, so that we can used it as a standard idiom? I think its much more readable writing "maybe (return ())" or "flip (maybe (return ()))". -- Ahn, Ki Yung

1 0

Release Schedule for 2009.2.0.2
by Don Stewart 03 Jun '09

03 Jun '09

The next Haskell Platform release is our final minor version on the 2009.2.0 branch. The timeline looks like: http://trac.haskell.org/haskell-platform/wiki/ReleaseTimetable # Freeze for package changes to 2009.2.0.2: Wednesday July 1 # Release 2009.2.0.2, Monday 13th July (6 weeks after .1) This is a minor release, so follows the versioning policy: bug fixes to packages only, and new installers please. Probably we'll also upgrade to 6.10.4 by then. It would be great if we could have our first public Mac OSX installer by then too, along with a Debian and Fedora installer. -- Don

4 5