November 2012 - Libraries

Proposal: Add isLeft/isRight to Data.Either
by Simon Hengel 14 Dec '12

14 Dec '12

Hi, I propose to add isLeft/isRight to Data.Either, with the obvious definitions: isLeft :: Either a b -> Bool isLeft (Left _) = True isLeft (Right _) = False isRight :: Either a b -> Bool isRight (Left _) = False isRight (Right _) = True There has been a discussion on that before [1]. While I agree that fromLeft/fromRight are moot, I don't see issues with isLeft/isRight. Personally I care mostly about isLeft, but for orthogonality I propose to add both isLeft and isRight. Here is a (possibly incomplete) list of packages that come with their own definition of isLeft: snap-core, multifocal, PriorityChansConverger, tamarin-prover-utils, Agda, PCLT, cmdtheline, scyther-proof, xmlhtml, hspec-expectations, Glob, language-glsl, Craft3e, hledger-lib, narc, nemesis, type-settheory, PCLT-DB, RJson, bio, errors, rss2irc, heist Discussion period: 2 Weeks Cheers, Simon [1] http://www.haskell.org/pipermail/libraries/2006-October/006098.html

18 35

digamma function
by Ben Gamari 14 Dec '12

14 Dec '12

My digamma package[1] implements an approximation to the digamma function (due to Tom Minka). Considering that the math-functions package already has a gamma implementation, it seems it would be natural to merge digamma into this package. Alternatively (or additionally), James Cook's gamma package also has a variety of gamma implementations and is also a candidate for merging digamma into. I don't mind maintaining digamma, but it might be easier for others if there were a single package providing all of these functions. Do others have an opinion on this? Are either (or both) of you interested in picking up a digamma implementation? Cheers, - Ben [1] http://hackage.haskell.org/package/digamma

3 2

Re: portable encoding/decoding without going via a handle
by Ganesh Sittampalam 10 Dec '12

10 Dec '12

Hi Judah, On 25/11/2012 17:19, Judah Jacobson wrote: > I think some way to use BufferCodecs without going through the > filesystem would be very useful. One other approach would be > Bytestring-backed Handles; there was talk of them in the past, but I > don't know of any actual packages for it yet. That might be a simpler > approach than manipulating BufferCodecs directly, since you could just > use the functions from Data.Text.IO <http://Data.Text.IO> and all of the > buffering and error recovery would get taken care of automatically. > > This 2009 email from Simon Marlow references bytestring-backed handles > and has a code sample for memory-mapped files that might be helpful: > http://www.haskell.org/pipermail/glasgow-haskell-users/2009-December/018124… > He also mentions bytestring-backed Handles in this talk: > http://community.haskell.org/~simonmar/GHC-IO.pdf > That code's probably bitrotted a little, but seems like a good place to > start. Thanks for the pointers! Do you have any thoughts on what the API for creating a bytestring-backed handle should be? I'm particularly thinking of the case where we are writing to the bytestring - the type could be something like makeWritableByteStringHandle :: IO (Handle, ByteString) but then would we end up with a ByteString value that could be being mutated in parallel with being used. It might be nicer to have it in two phases, e.g. makeWritableByteStringHandle :: IO Handle finishByteStringHandle :: Handle -> IO ByteString but since Handle is a single type rather than a type class, that's not imlpementable. Perhaps: makeWritableByteStringHandle :: IO (Handle, IO ByteString) where the embedded IO action is only valid after the Handle has been hClose'd? Cheers, Ganesh

2 2

Proposal: Add Functor instances for ArgOrder, OptDescr and ArgDescr
by Bas van Dijk 04 Dec '12

04 Dec '12

Hello, I recently needed Functor instances for the types in System.Console.GetOpt. Note that the test-framework package also defines[1] these instances. Discussion deadline: 1 week (I assume this is a no-brainer). Regards, Bas [1] http://hackage.haskell.org/packages/archive/test-framework/0.6.1/doc/html/s…

4 4

Proposal: Add (&) to Data.Function
by Yitzchak Gale 01 Dec '12

01 Dec '12

It is a common idiom to write a sequence of composed combinators in reverse order to the way they would be written with ($) or (.). That naturally expresses the idea of the combinators as operations being applied in the given order. This comes up so often, and is commonly used so many times in a single expression, that Control.Arrow.>>> is far too wordy, and even a two- character operator is awkward. Surprisingly, until recently the operator (&) was still not used in any of the popular libraries, and its name naturally expresses the idea we are looking for. This operator has now been defined in the lens package. We hereby propose to move it to its natural home for more general use, Data.Function. As in the lens package, we define the operator as a flipped version of ($), but with slightly higher precedence for better interaction with ($), and with left associativity. This definition has already proven useful and convenient even in the presence of the large and varied corpus of combinators and operators in the lens package. (There it was formerly known as (%), but that clashed with the usual meaning of (%) from Data.Ratio.) infixl 1 & (&) :: a -> (a -> b) -> b a & f = f a {-# INLINE (&) #-} Discussion period: 2 weeks http://hackage.haskell.org/trac/ghc/ticket/7434 Thanks, Yitz

29 67

bug in printf, and patch
by Evan Laforge 28 Nov '12

28 Nov '12

Text.Printf.printf has a bug where it doesn't like negative numbers for * modifiers. I opened a ticket along with a patch at http://hackage.haskell.org/trac/ghc/ticket/7457 I feel like it shouldn't need a discussion since it's just a bug fix, but if someone wants to speak up go ahead. It will change behaviour for people using negative numbers, but since the previous behaviour was "doesn't work" I hope they won't mind :)

1 0

Proposal: Add Eq instance for Control.Exception.ErrorCall
by Simon Hengel 28 Nov '12

28 Nov '12

Hi, I propose to add an Eq instance for ErrorCall. The main motivation is to make it more convenient to construct predicates that select specific exceptions. My current use case is testing for expected exceptions. In Hspec[1] we use predicates for that, e.g.: evaluate (head []) `shouldThrow` (== ErrorCall "Prelude.head: empty list") But I think it can be useful in other situations and it is consistent with the fact that other common exception types have an Eq instance (e.g. ArithException, IOException, ExitCode). Discussion period: 3 Weeks Cheers, Simon [1] http://hspec.github.com/

6 15

Cabal and GHC
by Simon Peyton-Jones 28 Nov '12

28 Nov '12

Michael Snoyman wrote a blog post about Solving Cabal Hall, which came across via the peerless Haskell Weekly News. http://www.yesodweb.com/blog/2012/11/solving-cabal-hell But I'd be unlikely to return there so I'm posting this to the libraries and cabal-devel lists. I'm not deep in Cabal lore, but it seems to me that there is a fairly easy way to do a Lot Better than we are now. Let's go back to "Identifying the Problem". Michael doesn't say, but I'm guessing that Fay depends on yesod-platform. Very well, so Cabal sees I'm installing Fay, which depends on yesod-platform, which dpends on data-default and depends directly on data-default If the package database was empty, Cabal would try to figure out a version of data-default that is acceptable to both yesod-platform and to Fay. And that's what we want! Suppose that Cabal figures out that yesod-platform-2.7 and data-default-0,4 would work. Then, in an empty package database, it could just go ahead and install those. But in your example, the database isn't empty; we have already isntalled yesod-platform-2.7, dependin gon data-default-0.5. And (here's the rub) you can only have yesod-platform-2.7 installed once. One solution might be 1. *un* install yesod-platform-2.7 (depending on data-default-0.5) and 2. *re* install it (depending on data-default-0.4). But that would break any programs that use both yesod-platform-2.7 and data-default-0.5. The solution is obvious: we should make it possible to instally yesod-platform-2.7 twice, once version depending on data-default-0.4 once version depending on data-default-0.5. Now, if Cabal can figure out a plan based on an empty database, it can deliver on that plan even in a non-empty database, without messing up any existing installations. Of course, if Fay depends exclusively on data-default-0.4, and yesod-platform depends exclusively on data-default-0.5, then they genuinely are incompatible, and Cabal can and should say so. That's not Cabal Hell. That's just saying that the package authors have *specified* that they are incompatible. Summary. I may be way off beam here, but I think we can easily make things way better than they are. By "easily" I mean with just design and implementation work. That's not free, and no one has any time.... but it's well within reach. I'd even been wondering about trying to crowd-fund this development so that Well Typed can do it. But let's first see if it'd solve the problem. There must be a wiki page somewhere that articulates the challenge, points to blog posts about it, and discusses solutions. Simon

14 20

portable encoding/decoding without going via a handle
by Ganesh Sittampalam 28 Nov '12

28 Nov '12

Hi, I need to convert directly between different string encodings, rather than just using a particular encoding when reading from/writing to a Handle. I'm aware of the following options, but they have a few problems: - text-icu: not easily usable on Windows as it requires libicu - text: just handles utf8/16/32 - iconv: POSIX only It seems like GHC's TextEncoding has the necessary low-level functionality (http://hackage.haskell.org/packages/archive/base/latest/doc/html/GHC-IO-Enc…) but I can't find any high-level interface for directly transcoding between String/Bytestring/Text. Am I missing something, or would this be a useful addition as a separate library? Cheers, Ganesh

2 2

Non-monotonic releases and package clobbering
by Edward Z. Yang 27 Nov '12

27 Nov '12

Hello all, I recently noticed that there is a subset of packages on Hackage which have had a non-monotonic release in their history. Non-monotonic releases occur for various reasons; for example, http://hackage.haskell.org/package/QuickCheck-1.2.0.1 was made in 2010 (2.1 was released in 2008), ostensibly as a minor bugfix release. However, I found at least one case where a non-monotonic release was due to package clobbering: http://hackage.haskell.org/package/Adaptive-0.1 http://hackage.haskell.org/package/Adaptive-0.22 It's easy to see that these are two different packages. 0.1 is the "later" release, but it is completely shadowed by the old 0.22 release. I'm not sure if I have any concrete recommendations (since this problem is mostly subsumed by the "people shouldn't be able to upload arbitrary stuff to Hackage problem); but I thought this might be interesting information to someone. Edward

2 1