October 2010 - Libraries

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

Notes from "Haskell takes over the world" BoF at ICFP
by Don Stewart 06 Oct '10

06 Oct '10

Here are the notes transcribed from the Future of Haskell BoF held after the Haskell Symposium last week. -- Don = Future of Haskell BoF Notes = A "birds of a feather" meeting was held at ICFP, organized by Bryan and Johan. We had 30 (?) people in a room, for 2 hours, discussing how to ensure Haskell succeeds. These are the transcribed notes. == Libraries == * Need to encourage special interest groups (SIGs) to form around particular domain areas in the libraries. AI, BioInf, Networking, etc. * Document the SIG process: what resources they have, how you get results. * Missing SIGs for certain platforms: Mac, CentOS etc. * More tutorials on use of Haskell in particular domains. * Keen for Hackage 2.0 quality review tools: embedded wikis, voting * Hackage analysis tools: reverse indexing of the code base. * There is no PVP tool. * Library fragmentation occuring due to type duplication (String, Text, ...) * Focus on intitiatives for common, core types. HP polish. * What is the "Son of Containers" going to be? * Build reports would help the community a lot. Integrated with Hackage. Haddock pages on hackage should be editable wikis (per-top-level function, dvcs backed? record history, captchas. roll back spam, by default assume good contributions) * Need to register patches to packages with lost maintainers. * Belgium Hackathon coming up. * Improve libraries process: esp. for small contributions. * Hackage maintainance: + maintainer timeout. + hackage package clobbering. + tweaks. hackage-local .cabal fixes. * Unclear what the rules for contributing are. Document them! * In particular, document how to contribute to: * ghc * cabal * core and HP * hackage * dockathon == IDEs == * A new ghci. + scriptable, scion-server? + repls on top of ghc-api + ruby repl + .ghci + documentation + hpaste/ghci. * IDE + scion. contributions. market places. + documentation. + EclipseFP, scion? + NetBeans. * Special Interest Groups + as the vehicle for domain projects. + formal process for forming a group. + a small amount of structure for groups + document process for forming a strike team. * haskell.org + polishing the wiki. + wikibooks. + call for sig. * haskell visual design group? + consistent color themes across haskell.org sites. + consistent haskell branding. * community server mailing lists in poor state * Move community more online ? Community services. + google groups + digests. + reply at the right point in the threads. + serious lists. + ghc users. libraries. + announces. + stackoverflow for new questions? + keep refering to SO. + reddit for news? == GHC == * ghc status + 50% split in room on moving ghc from darcs to git. + bug reports and interaction load with ghc + 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" * Release schedule. + RC at ICFP. + GHC release page. + HP/GHC release. + stage releases. + more clearly announced that ghc will be a beta prior to GHC HP. * HP, uses GHC installers as is. GHC zip. == Teaching / tutorials == * Tutorials. Documentation. + Writing a blog post that is wrong is a pretty good way to get feedback. + Find a forum to ask the question, so the answer is findable. + Ask on SO. + Clojure and Scala communities have active blog spheres. + they love descriptions of data structures + e.g. high fanout trees. + Aggregating the ephemera. + Archives: Haskell Reddit has all the interesting blog posts. -- Haskell Wikibook. * Cabal and integration with other languages. + Easier integration with C. + Higher barrier to entry on the Mac. + Playing well with other languages?

2 1