- Haskell-Cafe - Haskell.org

Re: [Haskell-cafe] zipWith and divide
by Rehno Lindeque 07 Jun '15

07 Jun '15

Hi! > zipWith(\) z1 z2 ........ this fails but works when using * or + or - > ....... I also tried using div and `div` but they failed to. > The divide operator is slash (/) not backslash (\): > zipWith (/) [0.1, 0.2] [0.2, 0.4] [0.5,0.5] Also, div should work as long you're using a Integral type like Int (you may be using Float or Double): > zipWith div [1, 2] [2, 2] [0,1] Cheers

1 0

ANN: nonce package
by Felipe Lessa 07 Jun '15

07 Jun '15

(Please forgive me if you received multiple copies of this e-mail.) Hello, The nonce package [1] contains functions to easily generate cryptographic nonces for many situations. Some places where these generated nonces can be used include: - Password recovery e-mail tokens. - XSRF protection tokens. - Session IDs sent on cookies. - Initialization vectors. It uses an AES CPRNG periodically reseeded from /dev/urandom (or equivalent). It has no frills, no knobs, so it's hard to misuse. It's been available for an year but I just realized I've never properly announced it. Regrettably, I've seen many uses of the random package (System.Random) when generating nonces. It's a bad choice: it is not a cryptographically secure PRNG, contains low entropy (64-bit state), and its default usage is seeded predictably (using a constant seed). Please avoid using the random package for generating nonces at all costs. In its stead, use the nonce package or something similar. Cheers, [1] http://hackage.haskell.org/package/nonce -- Felipe.

3 4

Re: [Haskell-cafe] Attacking Attachment "Cancelled Event" Bayhac 15
by Byron Hale 07 Jun '15

07 Jun '15

Bayhac 15 has not been cancelled. See http://bayhac.org/ @bayhac2015 Do NOT open the attachment to the cancelling email. It is likely a sophisticated attack. The listed "organizer" is not. We may, however, have modifications. For example, we are still seeking donors for food. We are still seeking speakers, maybe even some repeats of last year's speakers. You might just dust off last year's presentation, until we run out of room. Best Regards, Byron Hale byron.hale(a)einfo.com @Hale_ByronL

1 0

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