- Libraries - Haskell.org

ANN: data-textual: Human-friendly textual representations
by Mikhail Vorozhtsov 24 Apr '13

24 Apr '13

Hello lists, I'm pleased to announce the first release of data-textual[1], a library that provides human-friendly counterparts (called Printable/Textual) of the compiler-friendly Show/Read type classes. The library is intended to be used for printing and parsing of non-compound and non-polymorphic compound data (e.g. numbers, network and hardware addresses, date/time, etc). A quick example (vs network-ip[2] library): λ> import Data.Maybe (fromJust) λ> import Data.Textual λ> import Network.IP.Addr λ> let x = fromString "[dead::b:e:e:f]:123" :: Maybe Inet6Addr λ> x Just (InetAddr {inetHost = ip6FromWords 0xdead 0x0 0x0 0x0 0xb 0xe 0xe 0xf, inetPort = 123}) λ> toString (fromJust x) "[dead::b:e:e:f]:123" λ> let y = fromStringAs aNet4Addr "192.168.100.1/24" λ> y Just (netAddr (ip4FromOctets 192 168 100 1) 24) λ> toText (netPrefix $ fromJust y) "192.168.100.0" [1] http://hackage.haskell.org/package/data-textual [2] http://hackage.haskell.org/package/network-ip

1 0

Fix prelude definitions of abs/signum for Floats/Doubles
by Levent Erkok 23 Apr '13

23 Apr '13

The current definition of "abs" and "signum" for the types Float/Double is not IEEE-754 compliant. To wit: Prelude> abs (-0.0::Float) -0.0 Prelude> signum (-0.0::Float) 0.0 The correct result should be the other way around; abs returning 0.0 and signum returning -0.0 when they receive a negative-zero. The same also holds for the type Double. The issue came up several times in several forums, with general consensus that the behavior should match the IEEE-754 specs. Here're three different discussions on this matter: http://www.haskell.org/pipermail/libraries/2011-January/015761.html http://stackoverflow.com/questions/10395761/absolute-value-of-negative-zero… http://www.haskell.org/pipermail/haskell-cafe/2013-April/107471.html Proposed fix: Section 6.4.4 of the report http://www.haskell.org/onlinereport/basic.html#sect6.4 gives "default" definitions for abs/signum; which fails to take into account of negative-zero values for floating-point types. An easy fix would be to add to the report a note on the status of negative-zero for Real/Float instances; with individual implementations explicitly checking for negative-0 first. For instance GHC's implementation can be changed as follows: instance Num Float where signum x | isNegativeZero x = x | x == 0 = 0 | x > 0.0 = 1 | otherwise = negate 1 abs x | isNegativeZero x = 0 | x >= 0 = x | otherwise = negate x A similar change would need to be done for the "Num Double" instance as well. Of course, implementations can take advantage of the underlying CPU's native floating-point abs/sign functions if available as well, avoiding explicit tests at the Haskell code; based on the underlying platform. Library guidelines suggest a discussion period of 2 weeks on this issue. I'm hoping that we can resolve the issue in a timely manner, and at least GHC's implementation can match the desired semantics in the next release. If there's consensus at the end of 2-weeks; I'll go ahead and create a corresponding ticket for GHC. Thanks, -Levent.

12 19

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

22 Apr '13

My point was really that it wasn't a bug, there's nothing to fix: unix-2.6.x.y isn't expected to work with ghc-7.4.z. In the bug's comments you wrote: *Any chance of a fix for this? Many packages depend on unix and these packages can't be installed on Mac OS with the latest Haskell Platform.* * * Why do you think this is a problem? Haskell Platform (including the latest) ships with a version of the unix package that is compatible with the GHC it ships with. Any package that depends on unix should compile on Platform out of the box, as long as it works with GHC-7.4.1 & unix-2.5.1.1. I'd like to know if there are packages for which this is not true. - Mark

1 0

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

22 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