April 2013 - Libraries

RE: HP 2013.2 and GHC 7.6.2
by Simon Peyton-Jones 17 Apr '13

17 Apr '13

| I just spoiled my day by http://hackage.haskell.org/trac/ghc/ticket/7748 | with ghc-7.6.2 in our large project: | hets: <<loop>> | hets works fine with ghc-7.6.1 (and older versions). I haven't located | the error yet, though. | | Yet, I therefore conclude, GHC 7.6.2 ist not suited for the official HP. Happily I have found and fixed #7748 in the 7.6 branch. Christian, is it possible for you to build the 7.6 branch and test with Hets? Simon

10 19

The description of how to catch exceptions with tryJust is wrong
by Niklas Hambüchen 15 Apr '13

15 Apr '13

http://www.haskell.org/ghc/docs/7.6.2/html/libraries/base/Control-Exception… says: do r <- tryJust (guard . isDoesNotExistError) $ getEnv "HOME" case r of Left e -> ... Right home -> ... That is misleading, because it doesn't actually allow you to do something with the error: e is always (), because guard returns unit. That should be changed in the docs. "Well", thinks the Haskeller, "I shall use tryJust fromException then", but that doesn't work because you can't do that for thinks like "file does not exist", that's why we have isDoesNotExistError after all. What that example actually means is do r <- tryJust (\e -> if isDoesNotExistError then Just e else Nothing) $ getEnv "HOME" case r of Left e -> ... Right home -> ... How elegant.

1 0

Haskell Platform 2013.2 Proposal Status
by Mark Lentczner 14 Apr '13

14 Apr '13

Well, I admit I am a bit tardy with this, and a few dates in the schedule have come and gone. But have no fear, I think we'll be okay. *All: * Updated the time line the 2013.2 release: - *Today* — Call for proposals ends (no more proposals considered) - *April 15th* — Proposals decided, Initial version list - *April 22th* — First candidates - *April 29th* — Open issues resolved, Second candidates - *May 6th* — Final release candidates *Proposals:* These are the proposals being considered for 2013.2, and my current assessment of the "rough consensus": - *case-insensitive:* general consensus for including - *attoparsec: *general consensus for including - - *unordered-containers:* general consensus for including - *hashable:* while there has been much discussion about what to do going forward, I see general consensus that accepting version 1.1 into the platform (which is required by other proposals here) - *OpenGL *&* GLUT:* these have been repackaged by Jason to meet all the concerns of the community. They include two new lower-level packages * OpenGLRaw* and *GLURaw*. General consensus for continuing to include, with the lower level packages, and upgraded to latest versions (yay!) - *JuicyPixels:* people like the idea of having a library like this one, perhaps even this one, but there is concern that this API hasn't baked enough. There is not enough consensus for including. I give you all until Monday for any further discussion, and then we'll call it. *Versions* I now call it official: HP 2013.2 will use GHC 7.6.2. Library maintainers: Please get ready to answer my e-mail when it come a'knockin' on your inbox with the version of your lib we should ship in this release. — Mark "Chief Haskell Gift-Wrapper" Lentczner

5 4

Reverse DNS lookups on accept in network
by Yitzchak Gale 10 Apr '13

10 Apr '13

I noticed that the accept function in the network library, unlike the underlying C function, does a reverse DNS lookup every time it accepts a connection. This seems to be the cause of an acute problem: Hackage is nearly unusable for people whose ISP has broken reverse DNS, since every request to the server delays for 30 seconds or more while waiting for the broken reverse DNS server to time out. I know, the ISP should fix it, or the user should switch to a different ISP, but that isn't always practical. In particular, Roman, our expert from Odessa, is experiencing this problem. And he is hosting a Haskell Hackathon, OdHack, in just a few weeks time. I am concerned that all participants in the Hackathon might also be susceptible, which would be a Very Bad Thing. I'll note that nowadays it seems to be widely accepted "best practice" to avoid per-connection RDNS lookup, e.g., by configuring web servers to log IP addresses instead of domain names. So there are two questions here: one is whether we need a change to the the network and/or cgi packages (and possibly others), and the other is how to solve the hackage problem promptly. My first thought on the first question is to add a new function acceptRaw or accept' to network that skips the lookup, and then change cgi to use it. But I would also support changing accept itself to skip the lookup always. Thanks, Yitz

8 10

correction of the documentation for Traversable
by Petr Pudlák 09 Apr '13

09 Apr '13

Dear haskellers, I propose a correction to the documentation for Traversable. Currently it says: Minimal complete definition: traverse or sequenceA. This is not (completely) correct, it should be: Minimal complete definition: - traverse or - sequenceA with fmap. What happened to me: I defined a Traversable instance with just sequenceA and used fmapDefault and foldMapDefault to define instances of Functor and Foldable. This resulted in an infinite loop. This is because traverse is defined using sequenceA and fmap, but fmapDefault is defined using traverse. So it's not enough to define sequenceA and use the default implementations for the rest, one also has to define fmap explicitly. With best regards, Petr Pudlak

3 2

Moving basic functions
by David Luposchainsky 06 Apr '13

06 Apr '13

Hello GHC HQ, hello mailing list, there are a couple of basic functions that I think aren't where they should be. 1. void is currently in Control.Monad. However, it is defined only in terms of fmap (and therefore only has a Functor constraint). Although this function is often used in a monadic setting as ">> return ()", I really don't think Control.Monad is the right place for it. 2. a) swap is the only function from Data.Tuple that is not exported to Prelude. On #haskell, people are sometimes even surprised there /is/ a Data.Tuple, and redefine their own version of swap at need. I therefore suggest including Data.Tuple.swap in the Prelude. The obvious downside of this change would of course be that it breaks code if there is a top-level user-defined version of it. Fixing this is of course trivial, but necessary. b) A related suggestion would be the addition of an irrefutable swap, (swap'?), defined as "swap ~(a,b) = (b,a)", and its addition to Prelude for the same reasons. 3. $>, a flipped version of <$, currently resides in Control.Comonad, but should be in Data.Functor. Applicative has <* and *>, Monad has >>= and =<<, and I personally keep redefining (or specifically importing) $> quite often, and I don't think I'm the only one. As these are quite small changes I think 2 weeks should be a sufficiently long discussion period. Greetings, David

8 17

Proposal: simplify encoding of numbers in bytestring
by Bryan O'Sullivan 03 Apr '13

03 Apr '13

The bytestring builder API has a large number of entry points for encoding numbers: int8Dec , int16Dec , int32Dec , int64Dec , intDec , integerDec , word8Dec , word16Dec , word32Dec , word64Dec , wordDec Contrast this with the text library: decimal :: Integral a => a -> Builder I want to deprecate the 11 *Dec functions in favour of the same single-entry-point API used by text: it's way simpler, and no less efficient. (Really, the *Hex functions need the same treatment, but they're less of a priority to me.)

5 4