June 2015 - Haskell-Cafe

ANN: bytestring-lexing 0.5.0
by wren romano 07 Jun '15

07 Jun '15

-------------------------------------------- -- bytestring-lexing 0.5.0 -------------------------------------------- The bytestring-lexing package offers extremely efficient bytestring parsers for some common lexemes: namely integral and fractional numbers. In addition, it provides efficient serializers for (some of) the formats it parses. As of version 0.3.0, bytestring-lexing offers the best-in-show parsers for integral values. (According to the Warp web server's benchmark of parsing the Content-Length field of HTTP headers.) And as of this version (0.5.0) it offers (to my knowledge) the best-in-show parser for fractional/floating numbers. -------------------------------------------- -- Changes since 0.4.3 (2013-03-21) -------------------------------------------- I've completely overhauled the parsers for fractional numbers. The old Data.ByteString.Lex.Double and Data.ByteString.Lex.Lazy.Double modules have been removed, as has their reliance on Alex as a build tool. I know some users were reluctant to use bytestring-lexing because of that dependency, and forked their own version of bytestring-lexing-0.3.0's integral parsers. This is no longer an issue, and those users are requested to switch over to using bytestring-lexing. The old modules are replaced by the new Data.ByteString.Lex.Fractional module. This module provides two variants of the primary parsers. The readDecimal and readExponential functions are very simple and should suffice for most users' needs. The readDecimalLimited and readExponentialLimited are variants which take an argument specifying the desired precision limit (in decimal digits). With care, the limited-precision parsers can perform far more efficiently than the unlimited-precision parsers. Performance aside, they can also be used to intentionally restrict the precision of your program's inputs. -------------------------------------------- -- Benchmarks -------------------------------------------- For the Criterion output of the benchmark discussed below, see <http://community.haskell.org/~wren/bytestring-lexing/bench/html/readExponen…>. The main competitors we compare against are the previous version of bytestring-lexing (which already surpassed text and attoparsec/scientific) and bytestring-read which was the previous best-in-show. The unlimited-precision parsers provide 3.3x to 3.9x speedup over the readDouble function from bytestring-lexing-0.4.3.3, as well as being polymorphic over all Fractional values. For Float/Double: these functions have essentially the same performance as bytestring-read on reasonable inputs (1.07x to 0.89x), but for inputs which have far more precision than Float/Double can handle these functions are much slower than bytestring-read (0.30x 'speedup'). However, for Rational: these functions provide 1.26x to 1.96x speedup compared to bytestring-read. The limited-precision parsers do even better, but require some care to use properly. For types with infinite precision (e.g., Rational) we can pass in an 'infinite' limit by passing the length of the input string plus one. For Rational: doing so provides 1.5x speedup over the unlimited-precision parsers (and 1.9x to 3x speedup over bytestring-read), because we can avoid intermediate renormalizations. Whether other unlimited precision types would see the same benefit remains an open question. For types with inherently limited precision (e.g., Float/Double), we could either pass in an 'infinite' limit or we could pass in the actual inherent limit. For types with inherently limited precision, passing in an 'infinite' limit degrades performance compared to the unlimited-precision parsers (0.51x to 0.8x 'speedup'). Whereas, passing in the actual inherent limit gives 1.3x to 4.5x speedup over the unlimited-precision parsers. They also provide 1.2x to 1.4x speedup over bytestring-read; for a total of 5.1x to 14.4x speedup over bytestring-lexing-0.4.3.3! -------------------------------------------- -- Links -------------------------------------------- Homepage: http://code.haskell.org/~wren/ Hackage: http://hackage.haskell.org/package/bytestring-lexing Darcs: http://community.haskell.org/~wren/bytestring-lexing Haddock (Darcs version): http://community.haskell.org/~wren/bytestring-lexing/dist/doc/html/bytestri… -- Live well, ~wren

1 0

Re: [Haskell-cafe] Proposal: Shorter Import Syntax
by Anthony Cowley 05 Jun '15

05 Jun '15

> On Jun 5, 2015, at 4:14 PM, Marcin Mrotek <marcin.jan.mrotek(a)gmail.com> wrote: > > +1, though something alleviating the burden of importing the same module twice, like: > > import qualified Text as Text > import Text ( {- something -} ) > > would be even better. That is what this does. You will be able to write: import Text ( {- something -} ) as Text Anthony

2 1

Re: [Haskell-cafe] Proposal: Shorter Import Syntax
by malcolm.wallace 05 Jun '15

05 Jun '15

Here are some more numbers. In our private code base of ~12,400 modules totalling >2,300,000 LoC, there are ~143,800 import lines, of which ~65,000 use the "as" syntax. Of those, ~8,000 have no "qualified", and the remaining ~57,000 use "qualified". So I make that about 5.6% of our imports. I think this is quite a lot higher than the Stackage figure, because this code is mostly applications rather than libraries, so it tends to use a larger range of imported functionality from lots of different semi-independent domains. The chance of naming-overlap for separate concepts is therefore much greater, leading to our common idiom for optional qualification of names with short module synonyms (often single letters). Regards, Malcolm On 03 Jun, 2015,at 08:08 PM, Anthony Cowley <acowley(a)seas.upenn.edu> wrote: I grepped through the source of all the packages in the Stackage Nightly package set and found that less 0.3% of imports use that syntax. It's a small number, but it's not zero, so the breakage would be unacceptable.

2 1

Rounding
by ok＠cs.otago.ac.nz 05 Jun '15

05 Jun '15

The Haskell 2010 report defines, in chapter 9, round :: (Real a, Fractional a, Integral b) => a -> b round x = let (n, r) = properFraction x -- n = truncate x, r = x-n (same sign as x) m = if r < 0 then n - 1 else n + 1 in case signum (abs r - 0.5) of -1 -> n -- round in if |r| < 0.5 1 -> m -- round out if |r| > 0.5 0 -> if even n then n else m (commented and slightly rearranged). The traditional definition of rounding to integer, so traditional that it is actually given in the OED, is basically round x = truncate (x + signum x * 0.5) There was a discussion of rounding recently in another mailing list and I put together this table: * Round x.5 OUT Ada, Algol W, C, COBOL, Fortran, Matlab, Pascal, PL/I, Python, Quintus Prolog, Smalltalk. The pre-computing tradition. * Round x.5 to EVEN Common Lisp, R, Haskell, SML, F#, Wolfram Language. * Round x.5 UP to positive infinity Java, JavaScript, ISO Prolog, Algol 60 * Rounding of x.5 UNSPECIFIED Algol 68, IMP 77 What I was wondering was whether anyone on this list knew why Haskell has the break-ties-to-even definition instead of the traditional break-ties-out one. (And please don't say that it is to get statistical unbiasedness, because given the kinds of data distribution I see, it _isn't_ unbiased.)

3 2

The evil GADTs extension in ghci 7.8.4 (maybe in other versions too?)
by Ki Yung Ahn 05 Jun '15

05 Jun '15

\y -> let x = (\z -> y) in x x is a perfectly fine there whose type is a -> a. (1) With no options, ghci infers its type correctly. (2) However, with -XGADTs, type check fails and raises occurs check. (3) We can remedy this by supplying some additional options (4) Howver, if you put -XGADTs option at the end, it fails again :( kyagrd@kyahp:~$ ghci GHCi, version 7.8.4: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. Prelude> :t \y -> let x = (\z -> y) in x x \y -> let x = (\z -> y) in x x :: t -> t Prelude> :q Leaving GHCi. kyagrd@kyahp:~$ ghci -XGADTs GHCi, version 7.8.4: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. Prelude> :t \y -> let x = (\z -> y) in x x <interactive>:1:30: Occurs check: cannot construct the infinite type: t0 ~ t0 -> t Relevant bindings include x :: t0 -> t (bound at <interactive>:1:11) y :: t (bound at <interactive>:1:2) In the first argument of ‘x’, namely ‘x’ In the expression: x x Prelude> :q Leaving GHCi. ~$ ghci -XGADTs -XNoMonoLocalBinds -XNoMonomorphismRestriction GHCi, version 7.8.4: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. Prelude> :t \y -> let x = (\z -> y) in x x \y -> let x = (\z -> y) in x x :: t -> t Prelude> :q Leaving GHCi. ~$ ghci -XNoMonoLocalBinds -XNoMonomorphismRestriction -XGADTs GHCi, version 7.8.4: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. Prelude> :t \y -> let x = (\z -> y) in x x <interactive>:1:30: Occurs check: cannot construct the infinite type: t0 ~ t0 -> t Relevant bindings include x :: t0 -> t (bound at <interactive>:1:11) y :: t (bound at <interactive>:1:2) In the first argument of ‘x’, namely ‘x’

2 1

Consecutive FFI calls
by David Turner 03 Jun '15

03 Jun '15

Hi, If I make a sequence of FFI calls (on a single Haskell thread) but which end up being called from different OS threads, is there any kind of ordering guarantee given? More specifically, is there a full memory barrier at the point where a Haskell thread migrates to a new OS thread? Many thanks, David

4 6

Pixel by pixel image processing
by Geraldus 03 Jun '15

03 Jun '15

Hi cafe! I want to do some trivial masking manipulation on PNG images: take a picture, crop it to square shape and then make a circular mask, i.e. take all pixels that lies outside circle with radius equal to half of image width and placed at image center and replace that pixels with zero opacity once (hope this description is clear enough). I've found two packages for image processing so far: `friday` [1] and `unm-hip` [2], but can't figure out which of them suits my needs, maybe there are some other packages I miss? [1] https://hackage.haskell.org/package/friday [2] https://hackage.haskell.org/package/unm-hip

4 4

Haskell dev role in Strats at Standard Chartered (Singapore)
by Don Stewart 03 Jun '15

03 Jun '15

I have an open position for a Haskell developer to join Standard Chartered's Strats team in Singapore. More details at: https://donsbot.wordpress.com/2015/06/03/haskell-dev-role-in-strats-at-stan… -- Don

1 0

Blog platform written in Haskell
by Nicola Gigante 02 Jun '15

02 Jun '15

Hi all, Is there a blog platform written in Haskell? I mean something dynamic (as opposed to a static site generator like hakyll) like WordPress but written in Haskell. Does something like that exist? Greetings, Nicola

9 13

Four Designs for a Monad
by Zemyla 02 Jun '15

02 Jun '15

I'm working on writing a Haskell wrapper for the GNU Lightning code generation library (http://www.gnu.org/software/lightning/) which in C consists of a series of macros that write to a certain global state in a pointer _jit, such as jit_add or jit_call. Now, I figure that can be wrapped fairly simply in a monad, which we'll call the Lightning monad: -- syntax given here is just a sample. incr = lightningEmit $ do prolog in <- arg getArg R0, in addi R0, R0, 1 retr R0 However, I've come up with four possible designs for the Lightning monad. All but one would be reader monad transformers holding the pointer to the JIT state. 1) Lightning m a, where m is a MonadIO. Pros: Users have the power of the monads they are using within. Cons: Complexity, especially with having to handle monads with multiple returns like ListT. 2) Lightning a, which just wraps IO, and is a MonadIO. Pros: Allows the use of other IO functions in the monad. Cons: Allows the use of other IO functions in the monad. 3) Lightning a, which just wraps IO, and is not a MonadIO. Pros: Simplicity; possibly permitting the code generation to be unwrapped with unsafePerformIO. Cons: Referential integrity could still be violated. 4) Lightning a, which would be a free monad over the Lightning operations allowed. Pros: Evaluation (in the IO monad) would be certain to be pure, which would permit or accommodate it being a monad transformer, or converted to a pure function on architectures where the Lightning library is not available. Cons: Assembling, then disassembling to reassemble, a long list of instructions produces significant overhead, rendering it less suitable for JIT purposes. Interacting with the generated code is more difficult. Are there any other options I am missing? Are there any possibly game-changing pros or cons I have failed to notice? Thanks, Paul Drees

1 0