January 2010 - Libraries

Proposal #3339: Add (+>) as a synonym for mappend
by Bryan O'Sullivan 08 Nov '11

08 Nov '11

Ticket: http://hackage.haskell.org/trac/ghc/ticket/3339 >From the ticket: This proposal was, I think, originally suggested by Jules Bean. The idea is to add two functions to the Data.Monoid module, (+>) and (<+), corresponding to different uses of mappend. These should not be methods of the Monoidtypeclass, but top-level functions. I hope (but slightly doubt) that the visual nature of the two operators might help to counter the thought that monoids are just for gluing things together. (+>) :: (Monoid a) => a -> a -> a a +> b = a `mappend` b (<+) :: (Monoid a) => a -> a -> a a <+ b = b `mappend` a infixl 4 +> infixl 4 <+ Proposed deadline: two weeks. If this looks reasonable, I'll attach darcs patches.

30 75

There are too many error handling conventions used in library code!
by dons＠cse.unsw.edu.au 13 Aug '11

13 Aug '11

This article on the 8 different error handling strategies various common Haskell libs use: http://www.randomhacks.net/articles/2007/03/10/haskell-8-ways-to-report-err… got me thinking: we need to standardise/recommend a small set of methods for library error handling. The lack of consistent error reporting between libs results in verbose code, as we're not able to use a single error handling technique when gluing together code from different libs (i.e. we can't just use Maybe or Either/ErrorT). (It's always nice when you *can* use, say, a Maybe monad to glue code from a number of sources, but eventually you reach code with a different error system, and the Maybe monad breaks down). So, some questions I think we can tackle: * can we identify error handling strategies from the list that should not be used anymore? (throwDyn?) * can we move some of the outlying libraries to a more consistent error framework? * do we need more support for gluing together our different error systems? (it should be easier to glue code using , say, Maybe/Either). * what role does MonadError play here, as a generic error handler? * can we make precise recommendations about which error strategies to use? -- Don

11 16

Bug in Parsec.Token
by Greg Fitzgerald 04 Mar '10

04 Mar '10

In Text.Parsec.Token, the list of reserved names is not necessarily sorted for case-insensitive languages. When the list of reserved names contains a string with capital letters, the 'identifier' combinator can accept identifiers that conflict with reserved names. Attached are patches for Parsec 2.1 and 3.0. Please let me know if there's anything else I can do to ensure this patch makes it to the next release of the Haskell Platform. Thanks, Greg

6 11

Proposal #2629: Data.List: Replace nub; add nubOrd, nubInt, nubWith
by Bart Massey 24 Feb '10

24 Feb '10

http://hackage.haskell.org/trac/ghc/ticket/2629 Everyone always complains about nub, but nobody ever does anything about it except (map head . group . sort), which isn't lazy and isn't always faster. :-) I've implemented a new function nubWith that takes a "stop list" as an argument and filters its target list against the stop list. I've then re-implemented nub and implemented nubOrd and nubInt in terms of nubWith: the stop list is a typeclass, so these implementations are trivial and new implementations are easily added. nubBy is left alone, since there's nothing obvious to be done about it. All of the nubs are still fully lazy. Basic QuickCheck tests are provided, and pass. Performance benchmarking code is provided. The performance of my nub implementation is quite comparable to that of the standard one. My nubOrd and nubInt implementations are dramatically faster, since they use a Set and IntSet respectively for the stop list. In particular, they are performant on long lists with long nubs, unlike the basic nub. My implementation is available via git at git://svcs.cs.pdx.edu/git/nub.git or can be browsed at http://svcs.cs.pdx.edu/gitweb?p=nub.git;a=tree and has a maybe-outdated tarball at http://svcs.cs.pdx.edu/haskell/nub.tar.gz The Nub.hs file itself is attached to the proposal. If the proposal is accepted, I will prepare a patch against current GHC library top-of-tree, but for now it seems easier for everyone to just look at the bits in their current natural habitat.

15 31

packedstring
by Jens Petersen 15 Feb '10

15 Feb '10

I needed to apply the follow patch to packedstring to install it with ghc-6.12.1 and cabal-install-0.8.0 on my machine: diff -u packedstring-0.1.0.1/packedstring.cabal\~ packedstring-0.1.0.1/packedstring.cabal --- packedstring-0.1.0.1/packedstring.cabal~ 2010-01-17 16:23:32.000000000 +1000 +++ packedstring-0.1.0.1/packedstring.cabal 2010-01-17 19:18:15.000000000 +1000 @@ -9,7 +9,7 @@ (Deprecated) Packed Strings. build-type: Simple Library - build-depends: base, array + build-depends: base >=4, array exposed-modules: Data.PackedString extensions: CPP (sorry gmail is probably going to mess I the patch header) Jens

3 2

cabal user guide character set
by Jon Fairbairn 14 Feb '10

14 Feb '10

http://www.haskell.org/cabal/release/cabal-latest/doc/users-guide/ is served as Content-Type: text/html; charset=utf-8 but the content appears to be iso8859-1 Perhaps someone could correct one or the other? -- Jón Fairbairn Jon.Fairbairn(a)cl.cam.ac.uk http://www.chaos.org.uk/~jf/Stuff-I-dont-want.html (updated 2009-01-31)

2 1

ANN: haxr 3000.5 and haxr-th 3000.5
by Gracjan Polak 09 Feb '10

09 Feb '10

Hello fellow haskellers, New release of HaXR 3000.5 availalble! HaXR is a library for writing XML-RPC client and server applications in Haskell. HaXR consists of two packages: haxr and haxr-th. The latter package contains the Template Haskell code used for automatically deriving XML-RPC struct representations for Haskell records. http://hackage.haskell.org/package/haxr Goodies in this release include: * UTF-8 encoding * HTTP 4000 and ByteStrings * HaXml dependency upgrade to 1.20 My request to The Powers: since I have no access rights to the HaXR home page http://www.haskell.org/haxr/ could we please move it to haskellwiki? Also the old repository http://darcs.haskell.org/haxr is now stale. Can we do something about this? Happy hacking! -- Gracjan

3 3

Can the Haddock library expose more (then just reading interface files)?
by jutaro 08 Feb '10

08 Feb '10

I've ported part of the Leksah metadata collection to use Haddock. But, now it comes, I have not created another backend, but would like to use Haddock as a library and call "createInterface" directly. So I need to change the exposed-modules section of haddock.cabal file to include: "Haddock.Types Haddock.Interface Haddock.Options" Would that be an acceptable patch for the general release, or do you feel it to be too unhygienic or something? The decision came because: 1. Leksah needs to write a binary format, so that the backend would have introduced new dependencies. (binary, binary-shared) 2. Leksah collects information from a variety of sources dynamically and needs a more flexible approach: - .hi files(installed packages without sources), - haddock (packages with sources that compiles) - parsing sources (projects you work on, which may for now not typecheck or compile). This can be better and more efficiently be implemented with a library approach. Jürgen -- View this message in context: http://old.nabble.com/Can-the-Haddock-library-expose-more-%28then-just-read… Sent from the Haskell - Libraries mailing list archive at Nabble.com.

3 5

Distro mappings script still running?
by Don Stewart 28 Jan '10

28 Jan '10

Hey all, Did the distro mappings script for Hackage (the one that tracks lists of what is in each distro) survive the move to abbott? I'm not sure its updated recently. -- Don

2 2

Minor inefficiency in Data.Map and Data.Set?
by Tyson Whitehead 22 Jan '10

22 Jan '10

I was looking at the Data.Map and Data.Set implementations and I think there is a slight inefficiency. Consider the Data.Map code {-------------------------------------------------------------------- [glue l r]: glues two trees together. Assumes that [l] and [r] are already balanced with respect to each other. --------------------------------------------------------------------} glue :: Map k a -> Map k a -> Map k a glue Tip r = r glue l Tip = l glue l r | size l > size r = let ((km,m),l') = deleteFindMax l in balance km m l' r | otherwise = let ((km,m),r') = deleteFindMin r in balance km m l r' The call to balance should not be needed as subtracting one item from the non- smaller of them cannot thrown them out of balance given they are already in balance with one another. The only way they could be made out of balance would be to subtract an item for smaller one. The replacement code is glue l r | sizeL > sizeR = let ((km,m),l') = deleteFindMax l in Bin sizeX km m l' r | otherwise = let ((km,m),r') = deleteFindMin r in Bin sizeX km m l r' where sizeL = size l sizeR = size r sizeX = sizeL + sizeR The Data.Set code is identical except for the key. Cheers! -Tyson

4 4