- Libraries - Haskell.org

authorspellings
by Bas van Dijk 15 Oct '10

15 Oct '10

Hello, In the current thread about "Making it easier to contribute non-functional changes" Johan Tibell asked about the contributors to the base library. Darcs has a nifty command for this: darcs show authors[1]. This command shows the total number of patches per author. Unfortunately authors email addresses or nicknames change over time which obfuscates this list. Fortunately darcs has a simple way of figuring out which email address or nickname belongs to which author by consulting the .authorspellings file. In this file you can specify the: official author name <official(a)emailaddress.com>, followed by regular expressions for matching old email addresses and nicknames. The attached patch adds an initial .authorspellings file to the base library. It would be nice if somebody could commit it. It would be even nicer still if we could somehow share the same .authorspellings file between GHC and the different boot libraries. Is it possible (and desirable) to create a symlink from the base library to the ghc repositorie's .authorspellings file (which doesn't exist yet). Or maybe we should create a script that synchronizes the different files. Regards, Bas P.S. If you know the real name that belongs to some obscure nickname used in base or if you know which email addresses belong to the same person, please tell, so I can add them. [1] http://darcs.net/manual/Darcs_commands.html#SECTION007103100000000000000

4 5

Desired behaviour of rounding etc.
by Daniel Fischer 13 Oct '10

13 Oct '10

The methods of the RealFrac class produce garbage when the value lies outside the range of the target type, e.g. Prelude GHC.Float> truncate 1.234e11 :: Int -- 32-bits -1154051584 and, in the case of truncate, different garbage when the rewrite rule fires: Prelude GHC.Float> double2Int 1.234e11 -2147483648 I'm currently working on faster implementations of properFraction, truncate, round, ceiling and floor for Float and Double, so I'd like to know - does it matter at all what garbage is returned in the above case? - if it does, what is the desired behaviour (at least for Int, I can't cater for all possibilities)? On a related note, in my benchmarks, truncFloatGen :: Integral a => Float -> a truncFloatGen = fromInteger . truncFloatInteger truncFloatInteger :: Float -> Integer truncFloatInteger x = case decodeFloat x of (m,e) | e == 0 -> m | e < 0 -> let s = -e in if m < 0 then - ((-m) `shiftR` s) else m `shiftR` s | otherwise -> m `shiftL` e is more than twice as fast as GHC.Float.float2Int, the corresponding for Double almost twice as fast as double2Int. Can anybody confirm that the above is faster than float2Int on other machines/architectures? Cheers, Daniel

5 8

Re: Haskell Platform Proposal: add the 'text' library
by John Lato 12 Oct '10

12 Oct '10

> > Message: 3 > Date: Mon, 11 Oct 2010 21:51:46 +0100 > From: Ian Lynagh <igloo(a)earth.li> > Subject: Re: Haskell Platform Proposal: add the 'text' library > To: libraries(a)haskell.org > Message-ID: <20101011205146.GA29025(a)matrix.chaos.earth.li> > Content-Type: text/plain; charset=us-ascii > > On Mon, Oct 11, 2010 at 09:12:33PM +0100, Malcolm Wallace wrote: > > > > of the Data.Text package on the basis that Char/Text are the "same" > > thing, then it may become clearer how to resolve the apparent name/type > > clashes below. > > But this doesn't allow the multi-Char functions to be added to > byetstring/List with the same name. For example: > > >> split - - Text -> Text -> [Text] > >> - - split Char -> Text -> [Text] > > > > split - split Text -> Text -> [Text] > > > > Proposal: these are equivalent, no action, > > I can do > split "\r\n" > or > split ", " > etc with a text, but not with a bytestring, and if we agree to add that > functionality to bytestring then we'll have to call it splitString or > splitMany or some other, different, name. > Really you shouldn't be able to do split "\r\n" or even split '\n' with a bytestring at all.

1 0

RealFrac methods for Double and Float
by Daniel Fischer 12 Oct '10

12 Oct '10

Greetings, I have put together a package to test possible implementations of the RealFrac methods for Double and Float (base-2 IEEE754) and uploaded a .tar.gz bundle to http://hackage.haskell.org/trac/ghc/ticket/2271 . On the one hand, pure Haskell implementations, on the other hand implementations calling out to rint[f], trunc[f], floor[f] and ceil[f] from math.h. Both ways go via Integer by default, with a specialised faster implementation for Int (and narrower types, but those RULES haven't yet been written) enabled by a rewrite rule. Overall, the pure Haskell implementations don't fare badly on my computer. All give a speedup compared to the current implementation, for most conversions, pure Haskell is on par with or faster than the C-call (although that would probably change if the C functions were made primops). The FFI calls are significantly faster for properFraction :: Double -> (Integer, Double) and for round (except round :: Integral a => Float -> a when compiled via C, then native and FFI are on par). Sample results for the speedups against the current implementation (note: for truncate :: x -> Int, the Prelude value is fst . properFraction, not the rewritten float2Int or double2Int) are included in the tarball. I would appreciate feedback from your tests/benchmarks on other platforms, especially 64-bit platforms (mine is x86 linux, 32 bit). To run the QuickCheck tests, you need QuickCheck-2.*, to run the benchmarks, criterion. More instructions in the README. Thanks, Daniel

3 9

Proposal: Move 'split' into a separate class in System.Random
by Thomas DuBuisson 11 Oct '10

11 Oct '10

The "split" routine in the RandomGen seems to be a sore spot for some people and is perceived to have few users (even as a percentage of RandomGen users). I propose: 1) Making a class "SplittableGen": class SplittableGen g where split :: g -> (g, g) 2) (re)moving the "split" routine from the RandomGen class. See ticket 4314 [1] for the patch. Period of discussion: Till October 8 (3.5 weeks, ending just over 1 week after ICFP) Cheers, Thomas [1] http://hackage.haskell.org/trac/ghc/ticket/4314

17 29

Re: Round benchmarks
by Daniel Fischer 11 Oct '10

11 Oct '10

On Monday 11 October 2010 07:05:20 you wrote: > Hi, > > These results seem different from the samples. Thanks. The numbers are quite impressive. Although the quotients (hence speedups) are generally much larger, the ranking doesn't differ much. For round :: x -> Int, via C is a big win. For round :: x -> Integer and properFraction :: Double -> (Integer, Double), going via C doesn't seem to make much difference on 64 bits, but they do on 32. That's probably because a Double mantissa is a smallInteger on 64 bits. Overall, your timings support going via C for round and properFraction :: Double -> (Integer, Double). In two cases, it makes not much difference on 64 bits but is a big gain on 32, for round :: x -> Int, it's a big win on both. > > I was surprised that the "via Integer" results appear faster than the > Int results. No, the numbers are (Prelude time / new time), so the larger the number, the better. Sorry for not making that clear in the README. > > Vivian Cheers, Daniel

1 0

sizedText function for Text.PrettyPrint
by Levent Erkok 11 Oct '10

11 Oct '10

Hello all, I've created a minor feature request ticket for the PrettyPrint library: http://hackage.haskell.org/trac/ghc/ticket/4377 following the instructions on http://haskell.org/haskellwiki/Library_submissions. Thanks! -Levent.

3 2

Proposal: Generalize the RandomGen and Random classes
by Thomas DuBuisson 10 Oct '10

10 Oct '10

Hello, RandomGen and Random classes assume generators produce Int values. This is non-ideal as many high speed generators produce special values (ex: doubles) or generic values (bit streams / bytestrings) that can be converted directly to types easier than coercing to Int then to an 'a' via the Random class. See 4315 [1] for the patch. Period of discussion: Till October 8 (3.5 weeks, giving a little time after ICFP for last minute debate) Specifically, this proposal: 1) Alters RandomGen: from: class RandomGen g where next :: g -> (Int, g) genRange :: g -> (Int, Int) to class RandomGen g v | g -> v where next :: g -> (v, g) genRange :: g-> (v,v) 2) Alters Random: From: class Random a where randomR :: RandomGen g => (a,a) -> g -> (a,g) random :: RandomGen g => g -> (a, g) randomRs :: RandomGen g => (a,a) -> g -> [a] randoms :: RandomGen g => g -> [a] randomRIO :: (a,a) -> IO a randomIO :: IO a to class Random a where randomR :: RandomGen g v => (a,a) -> g -> (a,g) random :: RandomGen g v => g -> (a, g) randomRs :: RandomGen g v => (a,a) -> g -> [a] randoms :: RandomGen g v => g -> [a] Additional Points of Debate 1) Because random[R]IO can not be part of the new Random instance with a sensible default, these have been moved to top-level functions: randomRIO :: (Random a Int) => (a,a) -> IO a randomIO :: (Random a Int) => IO a Other options exist and I'm open to them. I'm just being upfront about what the patch currently does. 2) All pre-existing instances of "Random x" for some concrete 'x' have been modified to be "instance Random x Int". As 'Int' was the previous (hardcoded) default for RandomGen this is simply matching the behavior. More instances are possible and probably make sense now. Alternatively, one could argue for zero default instance as they can collide with how a particular user wishes types to be coerced. 3) Not-so-new extensions are used to enable these changes. Extensions include MultiParamTypeClasses, FlexibleContexts, and FunDeps. 4) A patch is included bumping the version from 1.0.0.x to 1.1.0.0. Cheers, Thomas [1] http://hackage.haskell.org/trac/ghc/ticket/4315

12 20

Replaced throw to throwIO where type is IO
by Bas van Dijk 08 Oct '10

08 Oct '10

Hello, Attached is a small patch to: Control/Exception/Base.hs which replaces all uses of 'throw' to 'throwIO' where the type is IO. It would be nice if someone can review and apply it. Regards, Bas

5 12

Re: Notes from "Haskell takes over the world" BoF at ICFP
by Simon Marlow 07 Oct '10

07 Oct '10

On 07/10/2010 02:45, Jason Dagit wrote: >> + well documented workflow for lightweight changes >> + heavy weight process for major work. >> + bugs, tickets. >> + Simon Marlow "contributions are going up, and process is working well" > > That's reassuring. Is their workflow documented for the benefit of > other Haskell projects and the greater FOSS community in general? We have pretty extensive instructions on how to contribute to GHC here: http://hackage.haskell.org/trac/ghc/wiki/WorkingConventions If you find anything missing, or something that could be improved, please let us know! Cheers, Simon

1 0