October 2008 - Libraries

A wiki page for managing the 6.10 handover
by Don Stewart 13 Oct '08

13 Oct '08

http://haskell.org/haskellwiki/Upgrading_packages#Typical_breakages_with_GH… It collects the 7 or so known issues that break code with GHC 6.10. Please feel free to clean up, and especially *add techniques for handling each change*. If we do this right, with cabal-install being smart, clear summaries of what is broken and how to fix it, this might be the smoothest major release yet. -- Don

4 6

Arch Haskell News: Oct 12 2008
by Don Stewart 12 Oct '08

12 Oct '08

News about Haskell on Arch Linux http://archhaskell.wordpress.com/2008/10/12/arch-haskell-news-oct-12-2008/ Arch now has 624 Haskell packages in AUR. That’s an increase of 15 new packages in the last 7 days. Planning is also underway for the GHC 6.10 release, and the 6.10 release candidate is in testing. Noteworthy * cabal-install-0.6.0: “The command-line interface for Cabal and Hackage.” * haskell-cabal-1.6.0.1: “A framework for packaging Haskell software” * haskell-bytestring-0.9.1.3: “Fast, packed, strict and lazy byte arrays with a list interface” * haskell-transactional-events-0.1.0.0: “Transactional events, based on Concurrent ML semantics” Full details on the site.

1 0

Arch Haskell News: Oct 4 2008
by Don Stewart 12 Oct '08

12 Oct '08

A weekly update about Haskell on Arch Linux. Highlights, * Arch now has 609 Haskell packages in AUR. That’s a record increase of 19 new packages in the last 7 days. Noteworthy, * mp3decoder-0.0.1: “MP3 decoder for teaching.” * yi-0.4.6.2: “The Haskell-Scriptable Editor” * haskell-haskore-0.0.5.1: “The Haskore Computer Music System” Full update list, http://archhaskell.wordpress.com/2008/10/04/arch-haskell-news-oct-4-2008/ -- Don

2 2

Bugfix for QuickCheck 1.1.0.0
by Patrick Perry 09 Oct '08

09 Oct '08

Hi everyone, I've put in a proposal that fixes a bug in QuickCheck 1.1.0.0. http://hackage.haskell.org/trac/ghc/ticket/2535 Thanks, Patrick

6 10

Re: Proposal #2659: Add sortOn and friends to Data.List
by Bertram Felgenhauer 09 Oct '08

09 Oct '08

Twan van Laarhoven wrote: > Hello list, > > > Almost all uses of sortBy in user code use 'comparing', 'on' or a similar > construction [1]. I think we should add a function that makes this common > behavior more convenient: > > sortOn :: Ord b => (a -> b) -> [a] -> [a] > > For consistency we should also add *On for the other *By functions in > Data.List: > > nubOn :: Eq b => (a -> b) -> [a] -> [a] > deleteOn :: Eq b => (a -> b) -> a -> [a] -> [a] > deleteFirstsOn :: Eq b => (a -> b) -> [a] -> [a] -> [a] > unionOn :: Eq b => (a -> b) -> [a] -> [a] -> [a] > intersectOn :: Eq b => (a -> b) -> [a] -> [a] -> [a] > groupOn :: Eq b => (a -> b) -> [a] -> [[a]] > sortOn :: Ord b => (a -> b) -> [a] -> [a] > insertOn :: Ord b => (a -> b) -> a -> [a] -> [a] > maximumOn :: Ord b => (a -> b) -> [a] -> a > minimumOn :: Ord b => (a -> b) -> [a] -> a > (nubSortOn :: Ord b => (a -> b) -> [a] -> [a]) -- see #2629 Too many functions, and too little added functionality, IMHO. > newtype Down a = Down { getDown :: a } I like this one. Bertram

2 1

Re: Status of nubOrd (Proposal #2629)
by Bertram Felgenhauer 09 Oct '08

09 Oct '08

Bart Massey wrote: > 1) Stick nubOrd' from my previous message into Data.List and > call it a day. I don't like it, for the simple reason that its exact strictness properties are hard to explain. Low performance hurts, too. > 2) Stick (non-StopList) nubWith in Data.List. Stick nubOrd > in Data.Set, implemented using nubWith. > > Advantages: Provides a highly efficient, fully lazy > nubOrd. Provides nubWith. Reasonable implementation. That's nubWith :: (a -> b -> Maybe b) -> b -> [a] -> [a], right? I have no strong opinion about this proposal either way. > Disadvantages: Sticking nubOrd in Data.Set is weird. That doesn't worry me much. We can always add a link to the documentation of 'nub'. All in all I must say that the design space for nub functions is surprisingly big. One aspect that hasn't been mentioned yet is special handling for finite types. For example, nubBool (True:True:False:undefined) could well return [True,False], because all possible values have been exhausted at that point. I'm not suggesting to add more functions for this - nubBool is easily expressed as nubBool = take 2 . nub regards, Bertram

3 3

cabal-install, ghc-6.10
by Johannes Waldmann 08 Oct '08

08 Oct '08

Does cabal-install work with ghc-6.10? Not out-of-the box it seems. With a recent 6.10 binary snapshot (containing Cabal-1.5.5), I get Configuring cabal-install-0.5.2... Setup: At least the following dependencies are missing: Cabal ==1.4.*, HTTP >=3000 && <3002, base <3 && >=2.0 && <2.2 Regards, J.W.

3 2

Re: A general question about the use of classes in defining interfaces
by Ross Paterson 08 Oct '08

08 Oct '08

On Wed, Oct 08, 2008 at 12:36:02PM +0200, S. Doaitse Swierstra wrote: > Stimulated by remarks made during the discussion on the future of > Haskell at the last Haskell Symposium, I have started to convert my new > parsing library (constructed for the Lernet summerschool in Uruguay) into > Cabalised form. In this library I have amongst others the class: > > class Applicative p where > (<*>) :: p (b -> a) -> p b -> p a > (<|>) :: p a -> p a -> p a > (<$>) :: (b -> a) -> p b -> p a > pReturn :: a -> p a > pFail :: p a > f <$> p = pReturn f <*> p > > which extends/deviates from the standard class Applicative, since I > think these functions more or less belong together. I am happy to factor > out <|> into a separate class. This corresponds to Alternative, a subclass of Applicative (except for <$> being a function instead of a method). They certainly belong together for parsers, but there are applicative functors that don't have the extra monoidal structure. > The problem which arises now is when I want to use the class Applicative > as it is now defined in Control.Applicative. Functions like <$>, <$, <* > and many have standard implementations in terms of the basic function pure > and <*>. Although this looks fine at first sight, this is not so fine if > we want to give more specialised (optimised, checking) implementations, > as I am doing in my library. An example of this is e.g. in many, where > I want to check that the parameter parser does not recognise the empty > sequence since thi is non-sense, etc. Of course we can describe <* by > > p <* q = pure const <*> p <*> q > > but this is also rather inefficient; why first building a result if you > are going to throw it away anyway? The current definition isn't quite as bad as that: p <* q = const <$> p <*> q f <$> a = fmap f a but the general point stands. > More in general I think it is preferred to place common patterns in > classes with a default implementation, so they can be redefined instead > of defining them at top level. > > 1) Does everyone agree with this observation, and if not what am I > missing? > 2) Can we change the module Applicative to reflect my view? I think it > can be done without implying heavy changes to other modules. This seems reasonable to me, as long as there aren't too many of them; we do this for lots of other classes. Would you like to list all the functions that you would like to have as redefinable methods?

2 1

A general question about the use of classes in defining interfaces
by S. Doaitse Swierstra 08 Oct '08

08 Oct '08

Stimulated by remarks made during the discussion on the future of Haskell at the last Haskell Symposium, I have started to convert my new parsing library (constructed for the Lernet summerschool in Uruguay) into Cabalised form. In this library I have amongst others the class: class Applicative p where (<*>) :: p (b -> a) -> p b -> p a (<|>) :: p a -> p a -> p a (<$>) :: (b -> a) -> p b -> p a pReturn :: a -> p a pFail :: p a f <$> p = pReturn f <*> p which extends/deviates from the standard class Applicative, since I think these functions more or less belong together. I am happy to factor out <|> into a separate class. The problem which arises now is when I want to use the class Applicative as it is now defined in Control.Applicative. Functions like <$>, <$, <* and many have standard implementations in terms of the basic function pure and <*>. Although this looks fine at first sight, this is not so fine if we want to give more specialised (optimised, checking) implementations, as I am doing in my library. An example of this is e.g. in many, where I want to check that the parameter parser does not recognise the empty sequence since thi is non-sense, etc. Of course we can describe <* by p <* q = pure const <*> p <*> q but this is also rather inefficient; why first building a result if you are going to throw it away anyway? My life would be simpler if the extensions would either be incorporated in the class Applicative, with default definitions, and were not defined at top level, or in a class Extend_Applicative. More in general I think it is preferred to place common patterns in classes with a default implementation, so they can be redefined instead of defining them at top level. 1) Does everyone agree with this observation, and if not what am I missing? 2) Can we change the module Applicative to reflect my view? I think it can be done without implying heavy changes to other modules. Doaitse

2 1

darcs patch: avoid import renaming errors in nhc98 (and 2 more)
by Malcolm.Wallace＠cs.york.ac.uk 06 Oct '08

06 Oct '08

Mon Oct 6 11:21:53 BST 2008 Malcolm.Wallace(a)cs.york.ac.uk * avoid import renaming errors in nhc98 Mon Oct 6 11:22:48 BST 2008 Malcolm.Wallace(a)cs.york.ac.uk * fix import of Control.Exception for nhc98 Mon Oct 6 11:23:29 BST 2008 Malcolm.Wallace(a)cs.york.ac.uk * in cabal file, avoid -package syb when building with nhc98

1 0