- Libraries - Haskell.org

Re: Haskell Platform 2013.2 Proposal Status
by Mark Lentczner 21 Apr '13

21 Apr '13

I'm not sure I understand that bug at all! The unix package is supplied with GHC. You can't, in general, just use a different version. Haskell Platform 2012.4 ships with GHC 7.4.1, which includes unix-2.5.1.1. I wouldn't expect unix-2.6.x.y to work with GHC 7.4.1 at all. Of course unix-2.6.x.y works with GHC 7.6.z, as that is the version of GHC that distributes with it. For this release, I expect to package GHC 7.6.3 (essentially 7.6.2 plush one bug fix), which includes unix-2.6.0.1. In short - I don't see that that bug is anything but as expected, and there is no need for a fix - as unix-2.6.0.1 will come with the next HP. - Mark

1 0

Proxy and new-typeable
by Shachaf Ben-Kiki 19 Apr '13

19 Apr '13

I see that the new-typeable branch in GHC is using "typeRep :: forall a. Typeable a => Proxy a -> TypeRep" rather than "typeOf :: forall a. Typeable a => a -> TypeRep". This is clearly a big improvement over using undefined everywhere. I'd like to suggest a small change, if it hasn't been brought up before -- "typeRep :: forall proxy a. Typeable a => proxy a -> TypeRep". This makes typeRep compatible with any other Proxy type, since it doesn't use any properties of the concrete type -- it just uses it to pass information about the "a". Things that consume a Proxy don't ever need to refer to Proxy explicitly. This would make Typeable compatible with other Proxy libraries, like the one in "tagged". It would also make it compatible with any other type of kind * -> * -- for example, "typeRep ([] :: [Int])" would be a valid, and arguable more convenient, syntax for using typeRep. "Nothing :: Maybe Int" and so on would work too. So things that produce a "proxy" don't need to refer to Proxy explicitly either. Possibly this would make the Proxy type entirely unnecessary. If it stays, though, I suggest that it belongs in a module other than Data.Typeable.Internal -- it's a useful type for many other things, and as long as it's in base and exposed to users, it might as well be treated as a type in its own right. It's also a monad, can provide a variant of `asTypeOf`, and so on. Shachaf

7 24

Re: HP 2013.2 and GHC 7.6.2
by Ian Lynagh 17 Apr '13

17 Apr '13

On Wed, Apr 17, 2013 at 05:37:37PM +0200, Gabor Greif wrote: > On 4/17/13, Iavor Diatchki <iavor.diatchki(a)gmail.com> wrote: > > Hello, > > > > cabal-install 1.16.0 and 1.16.0.1 have some serious bugs that one > > encounters rather quickly. For example, at work I wasted some time until I > > figured out that cabal was generating a 'Paths_' module that does not > > compile. Because of this, you can't even use it to install a newer > > version of itself, where the problem is fixed: you have to manually > > bootstrap the new version with the script! > > I came up with this. > > http://heisenbug.blogspot.fr/2013/02/old-cabal-subhell.html > > Pretty much what you have experienced. This doesn't appear to affect the Cabal that GHC 7.6.2 ships with. I get ... catchIO :: IO a -> (Exception.IOException -> IO a) -> IO a catchIO = Exception.catch ... getBinDir = catchIO (getEnv "HTTP_bindir") (\_ -> return bindir) in Paths_HTTP. Thanks Ian

3 2

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