April 2013 - Libraries

Proposal: merge either into transformers
by Roman Cheplyaka 03 Jan '17

03 Jan '17

I propose to add the sole module of the 'either' package[1], Control.Monad.Trans.Either, to the transformers package. It provides EitherT, a very basic and fundamental data type. The difference between EitherT and ErrorT is that the latter has an Error constraint, which is used to imlement 'fail'. Note that 'either' depends on the 'semigroupoids' and 'semigroup' packages to provide appropriate instances. The proposal is not to add those instances to 'transformers' to avoid additional dependencies. The instances can then be left in the 'either' package or moved to the 'semigroupoids' and 'semigroup' packages respectively. ('semigroupoids' already depends on 'transformers', while 'semigroups' does not). Compared to the 'either' package, Show, Read, Eq and Ord instances will be dropped to keep the code Haskell2010 (those instances require FlexibleInstances, FlexibleContexts, and UndecidableInstances). The patch is attached. [*] [*] against transformers-0.3.0.0, because the darcs version is not buildable (Control/Monad/Signatures.hs is not in the repository). Roman

22 72

Proposal: Use time rather than old-time in directory
by Ian Lynagh 17 Sep '14

17 Sep '14

Hi all, This proposal is to change directory to use the time package rather than the old-time package. This will hopefully be a significant step towards actually making the transition in general. I'm not sure if POSIXTime or UTCTime is the better type to use. Does anyone know? I started off with UTCTime, then switched to POSIXTime as UTCTime didn't have a Show instance. I've since found that actually UTCTime has both Show and Read instances, but they are orphaned. So actually, if UTCTime is the better type then switching back to UTCTime would allow us to fix this comment in hpc: -- We would rather use ClockTime in Mix, but ClockTime has no Read instance and simplify the code slightly. Attached are patches for directory, hpc and ghc. Suggested discussion period: Until 5th Nov 2011. Thanks Ian

14 35

Re: Proposal: Add hasBitSize to Data.Bits.Bits
by John Lato 19 Sep '13

19 Sep '13

> From: Edward Kmett <ekmett(a)gmail.com> > > On Fri, Jul 27, 2012 at 3:42 PM, Ian Lynagh <igloo(a)earth.li> wrote: > >> On Fri, Jul 27, 2012 at 03:06:04PM -0400, Edward Kmett wrote: >> > There is currently no way to know whether or not calling >> > Data.Bits.bitSizewill crash your program. >> > >> > I propose extending the Bits class to include: >> > >> > hasBitSize :: Bits b => b -> Bool >> > >> > such that it returns False for Integer and True for the other instances > > Would it be better to move bitSize into a separate class? > > > I don't think so. Ultimately, you should be able to know for every numeric > type if it has a fixed or variable number of bits. In a perfect world 'd > rather just have bitSize return a Maybe that way we don't have to truck > with partial functions in the API. > > However, the case for just adding hasBitSize is that it avoids breaking > existing code. Given that existing code using bitSize can already cause a crash when used with Integer or other infinite types, wouldn't it be better to break existing code so authors can fix (or at least examine) their use of bitSize? I'm in favor of changing the type of bitSize, although since none of my code uses that function it's an easy position for me to take. John L.

13 40

Data instance for Data.Version
by David Lazar 13 Sep '13

13 Sep '13

Hi, Can we derive Data for Data.Version.Version? It would benefit Cabal. Thanks, David

4 4

Re: [commit: unix] master: change notes (1461d21)
by Ian Lynagh 24 Aug '13

24 Aug '13

On Fri, Feb 08, 2013 at 01:56:28PM +0000, Simon Marlow wrote: > On 03/02/13 20:48, Simon Marlow wrote: > >On 02/02/13 14:11, Ian Lynagh wrote: > >> > >>The unix version number is still 2.6.1.0, but doesn't the new policy > >>http://hackage.haskell.org/trac/ghc/wiki/Repositories#Modifyinglocalpackages > >> > >>mean that it should be bumped to 2.7.0.0 now? Actually, having just tried to do this, I'm not sure how it's meant to work in practice. Bumping unix's version requires relaxing the dependencies in Cabal and haskeline on unix. One way to do this is to get upstream to relax the dependency and updating our lagging repo. That will mean a version of the library will be uploaded to hackage with the relaxed dependency. But we don't know what the release 2.7.0.0 of unix will look like yet; perhaps by the time it is released it will not work with the current Cabal/haskeline code. The other way is to make local ghc-only changes to relax the dependencies, but that would increase the risk that we'd release with a ghc branch of the library by mistake. Wouldn't it be better to go back to the previous scheme, where we didn't update version numbers until release time? Thanks Ian

5 7

Re: new-typeable, new cast?
by José Pedro Magalhães 01 Aug '13

01 Aug '13

Hi, On Mon, Mar 4, 2013 at 4:51 PM, Richard Eisenberg <eir(a)cis.upenn.edu> wrote: > Unless I'm missing something, this all looks very straightforward. The > implementation is there, already, in the guise of (gcast Refl). We would > just shuffle the definitions around a bit. Am I indeed missing something? > I think that is the case indeed. Though I agree that it would be a nice addition to Data.Typeable. Cheers, Pedro > > As for the name, I agree that :~: is awkward to type. But, I think == > should be saved for type-level Boolean equality, as a closer analogue to > its term-level meaning. I don't have a better suggestion than :~:. Or, if > we just allow Constraint/* polymorphism, than we can simply use ~, as that > *already* is a GADT wrapping around an even more primitive denotation of > equality. (Just kidding about the Constraint/* polymorphism…) > > Richard > > On Mar 4, 2013, at 10:30 AM, Simon Peyton-Jones wrote: > > > ok good. Since this is in the intersection of singletons and Typeable, I > wonder if Pedro and Richard might together lead on driving this to a > conclusion and implementing it? > > > > Simon > > > > | -----Original Message----- > > | From: Stephanie Weirich [mailto:sweirich@cis.upenn.edu] > > | Sent: 04 March 2013 14:24 > > | To: Shachaf Ben-Kiki > > | Cc: Simon Peyton-Jones; libraries(a)haskell.org; Richard Eisenberg > > | (eir(a)cis.upenn.edu) Dimitrios Vytiniotis; Iavor Diatchki; Conor > > | McBride; Pedro Magalhães > > | Subject: Re: new-typeable, new cast? > > | > > | Nice! I agree that having a (poly-kinded!) function of type > > | > > | >> eqT :: forall (a :: k) (b :: k). (Typeable a, Typeable b) => Maybe > (a > > | >> :~: b) > > | > > | around is The Right Way to Go. I'd call this function "eqT" or > > | "eqTypeable", after the similar operation in Data.Type.Equality. Thanks > > | for pointing out that we can get such a function so easily from gcast. > > | (Note that gcast itself can be polykinded now, I'm writing down the > > | kinds to make them obvious.) > > | > > | gcast :: forall (a :: k) (b::k) (c::k ->*). (Typeable a, Typeable b) -> > > | c a -> Maybe (c b) > > | > > | WRT to gcast1 and gcast2, these functions can be subsumed by eqT, but > > | not by polykinded gcast due to the restrictions on higher-order > > | polymorphism. > > | > > | gcast1 can convert [b Int] to [Maybe Int], but gcast cannot. eqT can do > > | so with a pattern match. This behavior does seem rather special-purpose > > | though---eqT is much more flexible. > > | > > | With singletons, we could imagine two different polykinded operations, > > | that differ only in whether their arguments are explicit/implicit. > > | > > | eqTypeable :: (Typeable a, Typeable b) => Maybe (a :~: b) > > | > > | eqSing :: Sing a -> Sing b -> Maybe (a :~: b) > > | > > | Again, Sing should be kind-indexed, so that we can have Sing True, Sing > > | 0, and (eventually) Sing Int. > > | > > | --Stephanie > > | > > | > > | On Mar 4, 2013, at 8:46 AM, Shachaf Ben-Kiki wrote: > > | > > | > On Mon, Mar 4, 2013 at 4:24 AM, Simon Peyton-Jones > > | > <simonpj(a)microsoft.com> wrote: > > | >> | λ> data a :~: b where Refl :: a :~: a > > | >> | λ> :t gcast Refl > > | >> | gcast Refl :: forall a b. (Typeable a, Typeable b) => Maybe > > | >> | ((:~:) * a b) > > | >> > > | >> That is a ferociously-unintuitive use of 'gcast'! It too me dome > > | while to convince myself that it was right. Though it does indeed > > | work. I'd see (gcast Refl) as the primitive, with 'gcast' itself as a > > | simple derived function. > > | >> > > | >> I'm not sure what name to give the new cast function > > | >> ?? :: Typeable a, Typeable b) => Maybe (a :~: b) > > | >> > > | >> > > | >> Do we need gcast1 and gcast2 any more, in our new polykinded world? > > | Can they be depreceated? > > | >> > > | >> Simon > > | >> > > | > > > | > A couple of people have suggested "same". (I wonder if this would > also > > | > subsume eqSingNat/eqSingSym?). > > | > > > | > By the way -- since (:~:) seems to be in HEAD now, but not yet > > | > released, is there a chance of renaming it? ":~:" is pretty awkward > to > > | > type, given all the new TypeOperators options these days; how about > > | > "=="? > > | > > > | > Shachaf > > | > > > > > > >

7 17

Proposal: Strict scanl, scanl1 and mapAccumL
by Bas van Dijk 19 Jul '13

19 Jul '13

Hi, Data.List exports strict versions of foldl an foldl1. I think it should also export these strict versions of scanl, scanl1 and mapAccumL: scanl' :: (a -> b -> a) -> a -> [b] -> [a] scanl' f q ls = q : (case ls of [] -> [] x:xs -> let q' = f q x in q' `seq` scanl f q' xs) scanl1' :: (a -> a -> a) -> [a] -> [a] scanl1' f (x:xs) = scanl' f x xs scanl1' _ [] = [] mapAccumL' :: (acc -> x -> (acc, y)) -> acc -> [x] -> (acc, [y]) mapAccumL' _ s [] = (s, []) mapAccumL' f s (x:xs) = (s'',y:ys) where (s', y ) = f s x (s'',ys) = s' `seq` mapAccumL' f s' xs Is there a good reason they're not included? Discussion deadline: 2 weeks (till Monday 26 November). Regards, Bas

9 18

A single general modification function for Map and IntMap proposal
by Nikita Volkov 15 Jul '13

15 Jul '13

There is a list of problems with the current "Map" and "IntMap" modification interfaces: - they are filled with quirky and too specialized functions - they are not consistent in terms of how equally named functions behave: http://hackage.haskell.org/packages/archive/containers/latest/doc/html/Data… - they still don't cover some important scenarios of use Because of the above I have very often found myself in requirement for the following function: withItem :: (Ord k) => k -> (Maybe i -> (r, Maybe i)) -> Map k i -> (r, Map k i) withItem k f m = let item = Map.lookup k m (r, item') = f item m' = Map.update (const item') k m in (r, m') It covers all the imaginable scenarios of modification operations: delete, update, replace, - yet it also provides one with ability to extract the modified data and not only. The problem is that this implementation involves a repeated lookup for the same item: first with "lookup", then with "update" - but the "containers" library exposes no functionality to get around that. So I suggest to implement an efficient version of "withItem" in the library. This function turns out to be far more generalized than any of the currently present in the library, so it can become a basic building block for all sorts of modifying functions, including all the already existing ones, e.g.: alter :: Ord k => (Maybe a -> Maybe a) -> k -> Map k a -> Map k a alter f k = snd . withItem k (\i -> ((), f i)) delete :: Ord k => k -> Map k a -> Map k a delete k = snd . withItem k (const ((), Nothing)) updateLookupWithKey :: (Ord k) => (k -> a -> Maybe a) -> k -> Map k a -> (Maybe a, Map k a) updateLookupWithKey f k = withItem k $ \i -> case i of Just i -> case f k i of Nothing -> (Just i, Nothing) Just i' -> (Just i', Just i') _ -> (Nothing, Nothing) You can see how easy it makes to achieve any sort of specialized functionality. So, besides the evident benefits, this function can also become a replacement for a whole list of confusing specialized ones, thus greatly lightening the library. You might have also noticed how this function is based around the standard "a -> (b, a)" pattern of the "State" monad, thus making it easily composable with it using the "state" and "runState" functions. Summarizing, my suggestions are: 1. Implement an efficient version of "withItem" for lazy and strict versions of "Map" and "IntMap". 2. Change the order of parameters from "lambda -> key" to "key -> lambda". The "updateLookupWithKey" example implementation shows how this change can be benefitial. 3. Begin the deprecation process of the following functions: insertWith, insertWithKey, insertLookupWithKey, adjust, adjustWithKey, update, updateWithKey, updateLookupWithKey, alter. A deadline for discussion is set to 6 weeks. For a formatted version of this message please visit https://github.com/haskell/containers/issues/28.

11 18

Proposal: When possible, give more useful exceptions from rawSystem and friends
by Ian Lynagh 02 Jun '13

02 Jun '13

Hi all, Currently, if you try to use rawSystem to run a program that doesn't exist, you will just get a bad error code as a result, e.g. this program: import System.IO.Error import System.Process main :: IO () main = do (rawSystem "/bin/true" [] >>= print) `catchIOError` \e -> putStrLn ("Exc: " ++ show e) (rawSystem "/bin/false" [] >>= print) `catchIOError` \e -> putStrLn ("Exc: " ++ show e) (rawSystem "/non/existent" [] >>= print) `catchIOError` \e -> putStrLn ("Exc: " ++ show e) putStrLn "Done" prints: ExitSuccess ExitFailure 1 ExitFailure 127 Done However, if we are on a platform that supports vfork, then we can pass information from the child process back to the parent process as they share address space. With the attached patch we instead get: ExitSuccess ExitFailure 1 Exc: resolveProcessHandle: does not exist (No such file or directory) (and it should be easy to also get "/non/existent" in the exception). If there are platforms that don't support vfork, then they will still give the old output. I haven't yet looked at whether we can also get good exceptions on Windows (the patch won't build on Windows yet; I still need to update the Windows-specific code). I think that despite the possibility that some platforms may not be able to support it, we should provide the better behaviour on platforms that do. What do you think? And do you have any other comments on the patch? (this proposal was inspired by http://hackage.haskell.org/trac/ghc/ticket/7859) Suggested discussion deadline: Mon 13 May 2013. Thanks Ian

4 6

instance Arbitrary Data.Map
by Henning Thielemann 01 Jun '13

01 Jun '13

It seems like the 'containers' package uses QuickCheck for testing, but does not export an Arbitrary Data.Map instance. Is this intended?

3 2

PolyKinds, Control.Category and GHC 7.6.1
by Edward Kmett 30 May '13

30 May '13

Would it be possible to add something like {-# LANGUAGE CPP #-} #if defined(__GLASGOW_HASKELL__) && __GLASGOW_HASKELL__ >= 704 {-# LANGUAGE PolyKinds #-} #endif to the top of Control.Category before the 7.6.1 final release? Control.Category.Category is pretty much the only type in base that directly benefits from PolyKinds without any code changes, but without enabling the extension there nobody can define categories for kinds other than *, and most interesting categories actually have more exotic kinds. I only noticed that it wasn't there in the release candidate just now. -Edward Kmett

5 11

Stricter WriterT (Part II)
by Gabriel Gonzalez 20 May '13

20 May '13

I previously asked on this mailing list about getting a stricter WriterT added to transformers here: http://www.haskell.org/pipermail/libraries/2012-October/018599.html To recap, neither of the two WriterT implementations in transformers keep the accumulator strictly evaluated. In the previous request, I presented four implementations, only one of which runs in constant space, all of which are in this hpaste: http://hpaste.org/75837 To summarize the four implementations: Version #1: WriterT from Control.Monad.Trans.Writer.Strict Version #2: Same as Version1, except the monad bind strictly evaluates the mappended result Version #3: WriterT reimplemented as StateT, but no strictness annotations Version #4: Same as Version3, except 'tell' strictly evaluates the mappended result Only version #4 works and runs in constant space. Actually, not only does it run in constant space, but I failed to realize at the time that it also compiles to very efficient core when you add an `Int` type annotation to the summand. For example, if you try to sum 1 billion `Int`s in the naive way using Version #4: main :: IO () main = (print =<<) $ runWriterT4 $ replicateM_ 1000000000 $ tell4 $ Sum (1 :: Int) ... and compile it with -O2, it generates the following very nice core: $wa1 = \ (w_s25b :: Int#) (ww_s25e :: Int#) (w1_s25g :: State# RealWorld) -> case <=# w_s25b 1 of _ { False -> $wa1 (-# w_s25b 1) (+# 1 ww_s25e) w1_s25g; True -> (# w1_s25g, ((), (I# (+# 1 ww_s25e)) ) #) } ... and runs in 4.6 seconds on my netbook: time ./writer ((),Sum {getSum = 1000000000}) real 0m4.580s user 0m4.560s sys 0m0.008s ... which is about 4.6 nanoseconds per element. This is quite impressive when you consider it is factoring everything through the 'IO' monad. If you use `Identity` as the base monad: main4 = print $ runIdentity $ runWriterT4 $ replicateM_ n $ tell4 $ Sum (1 :: Int) ... then it gets slightly faster: real 0m3.678s user 0m3.668s sys 0m0.000s ... with an even nicer inner loop: $wa1 = \ (w_s25v :: Int#) (ww_s25y :: Int#) -> case <=# w_s25v 1 of _ { False -> $wa1 (-# w_s25v 1) (+# 1 ww_s25y); True -> (# (), (I# (+# 1 ww_s25y)) #) } The reason this stalled last time is that Edward and I agreed that I should first investigate if there is a "smaller" type that gives the same behavior. Now I'm revisiting the issue because I can safely conclude that the answer is "no". The StateT implementation is the smallest type that gives the correct behavior. To explain why, it helps to compare the definition of `(>>=)` for both WriterT and StateT: m >>= k = WriterT $ do (a, w) <- runWriterT m (b, w') <- runWriterT (k a) return (b, w `mappend` w') m >>= k = StateT $ \s -> do (a, s') <- runStateT m s runStateT (k a) s' The `WriterT` fails to run in constant space because of the pattern of binding the continuation before mappending the results. This results in N nested binds before it can compute even the very first `mappend`. This not only leaks space, but also punishes the case where your base monad is a free monad, since it builds up a huge chain of left-associated binds. The canonical solution to avoid this sort of nested bind is to use a continuation-passing-style transformation where you pass the second `runWriterT` a continuation saying what you want to do with its monoid result. My first draft of such a solution looked like this: newtype WriterT w m a = WriterT { unWriterT :: (w -> w) -> m (a, w) } m >>= k = WriterT $ \f -> do (a, w) <- runWriterT m f runWriterT (k a) (mappend w) tell w = WriterT $ \f -> return ((), f w) runWriterT m = unWriterT m id ... but then I realized that there is no need to pass a general function. I only ever use mappend, so why not just pass in the monoid that I want to mappend and let `tell` just supply the `mappend`: newtype WriterT w m a = WriterT { unWriterT :: w -> m (a, w) } m >>= k = WriterT $ \w -> do (a, w') <- runWriterT m f runWriterT (k a) w' tell w' = WriterT $ \w -> return ((), mappend w w') runWriterT m = unWriterT m mempty Notice that this just reinvents the StateT monad transformer. In other words, StateT *is* the continuation-passing-style transformation of WriterT, which is why you can't do any better than to reformulate WriterT as StateT internally. So I propose that we add an additional stricter WriterT (under say, "Control.Monad.Trans.Writer.Stricter") which is internally implemented as StateT, but hide the constructor so we don't expose the implementation: newtype WriterT w m a = WriterT { unWriterT :: w -> m (a, w) } instance (Monad m, Monoid w) => Monad (WriterT w m) where return a = WriterT $ \w -> return (a, w) m >>= f = WriterT $ \w -> do (a, w') <- unWriterT m w unWriterT (f a) w' And define `tell` and `runWriterT` as follows: tell :: (Monad m, Monoid w) => w -> WriterT w m () tell w = WriterT $ \w' -> let wt = w `mappend` w' in wt `seq` return ((), w `mappend` w') runWriterT :: (Monoid w) => WriterT w m a -> m (a, w) runWriterT m = unWriterT m mempty If we do that, then WriterT becomes not only usable, but actually competitive with expertly tuned code.

5 6

new MonadRandom instance; and maintainership
by Brent Yorgey 26 Apr '13

26 Apr '13

Hi all, I would like to add a derived MonadPlus instance for both Rand and RandT. Also, since it seems that MonadRandom has no maintainer I propose to take on its maintainership. Any comments/objections/etc. welcome. -Brent

3 7

Proxy, new Typeable, and type-level equality
by Richard Eisenberg 24 Apr '13

24 Apr '13

Hi all, Combining ideas from a number of people/threads ("Proxy and new-typeable" [on libraries] and "RFC: Singleton equality witnesses" [on ghc-devs]), I propose this: > module GHC.TypeReasoning where > > data a :~: b where > Refl :: a :~: a > > -- with credit to Conal Elliott for 'ty' and Erik Hesselink & Martijn van Steenbergen for 'type-equality' > sym :: (a :~: b) -> (b :~: a) > trans :: (a :~: b) -> (b :~: c) -> (a :~: c) > coerce :: (a :~: b) -> a -> b > liftEq :: (a :~: b) -> (f a :~: f b) > liftEq2 :: (a :~: a') -> (b :~: b') -> (f a b :~: f a' b') > liftEq3 :: ... > liftEq4 :: ... > > instance Eq (a :~: b) where ... > instance Show (a :~: b) where ... > instance Read (a :~: a) where ... > instance Ord (a :~: b) where ... > -- what other instances? > > data Void > -- instances as in Edward Kmett's 'void' package > > absurd :: Void -> a > > type Refuted a = a -> Void > type Decision a = Proved a > | Disproved (Refuted a) > > class EqT f where > eqT :: f a -> f b -> Maybe (a :~: b) > > class EqT f => DecideEqT f where > decideEqT :: f a -> f b -> Decision (a :~: b) > > defaultEqT :: DecideEqT f => f a -> f b -> Maybe (a :~: b) -- for easy writing of EqT instances > > instance EqT ((:~:) a) where ... > instance DecideEqT ((:~:) a) where ... > module Data.Proxy where > -- as in Ben Gamari's version > module Data.Typeable ( … , Proxy(..), (:~:)(..) ) where > > ... > import GHC.TypeReasoning > import {-# SOURCE #-} Data.Proxy > > ... > eqTypeable :: (Typeable a, Typeable b) => Maybe (a :~: b) > decideEqTypeable :: (Typeable a, Typeable b) => Decision (a :~: b) > -- can't use EqT and DecideEqT because Typeable is in Constraint, not * > > gcast :: (Typeable a, Typeable b) => c a -> Maybe (c b) -- it is now polykinded > > {-# DEPRECATED gcast1 ... #-} > {-# DEPRECATED gcast2 ... #-} > ... On top of features others have proposed/written in packages, I have added DecideEqT and related definitions. I would indeed have use for this definition, and I imagine others will, too, once it's out there. We could theoretically hold off on that one, but it seems easy enough just to put it in now, while we're all thinking about it. I've tested the definition by writing instances of singletons, and it works as desired. If this proposal is accepted, we can then look at changing some of the definitions around TypeLits as well, linking in much of the ghc-devs thread "RFC: Singleton equality witnesses". I don't see any dependencies from the code above on the TypeLits/singleton stuff, so I think we can take those changes in a second round. One question in the above code: What other instances should there be for (:~:)? Comments? Thoughts? Thanks, Richard

8 9

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

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