January 2016 - Haskell-Cafe

long-range performance comparisons (GHC over the years)
by Johannes Waldmann 07 Jan '16

07 Jan '16

Dear Cafe, I recently noticed a performance problem due to a fusion rule not firing for a straightforward piece of code. In fact it turned out this was already fixed in HEAD, see https://ghc.haskell.org/trac/ghc/ticket/11344 https://ghc.haskell.org/trac/ghc/ticket/9848 What worries me is that such a regression had been sitting there for over a year (and did not make it to 7.10.3) and I got to thinking: What long-range performance metering do we have? So I tried to made nofib runs for some ghc-{6,7} versions http://www.imn.htwk-leipzig.de/~waldmann/etc/nofib/comparison-k.text This is slightly broken (not all tests can be built for all compilers, and I don't known how to fix this) but there are some interesting numbers already. It seems nofib programs are self-contained (not using any libraries) so they are mainly using numbers, lists, tuples, and user-defined data. This is the heart of (traditional) Haskell, so this is supposed to work really well. The table shows that there are a lot of benchmarks where performance has been increasing. That's good. But not for all! We should certainly ignore all runtimes that are absolutely small. I think it is most interesting to look allocation numbers. A few examples from this list: * exp3_8 (allocation goes up 50 % from 6.* to 7.*) this is addition of Peano numbers. * gcd (allocation goes up 20 % from 7.8 to 7.10) using Integers, tuples (for extended Euclid), lists (for control) * tak (runtime goes up 20 % from 7.6 to 7.8) the plain Takeuchi function, just Int and recursion (it should not allocate at all?) (and I confirmed these by manually running them for more inputs, all measurements done on debian on x86_64 X5365, ghc-6.* installed from binary packages, ghc-7.* built from source) So, can this be explained? Improved? I think we should resist the temptation to change these benchmarks (using seq and ! and Int# and whatnot) Assuming nofib contains typical code, it is the task of the compiler to handle it well. In case you're wondering about my motivation - this was prompted by teaching, I wanted to show that ghc creates efficient code (by fusion) - but it's not just for the show, I generally try to believe in what I teach and I do rely on this for my real code. (Well, by definition, "real" for me might still be "academic" for others...) - Johannes.

3 3

ideas for extending 'tensor'
by Petr Pudlák 06 Jan '16

06 Jan '16

Hi Nicola, I was very excited to see your type-safe tensor package. Are the sources available somewhere for contributing? I'd be interested in trying to extend it to use unboxed vectors, or perhaps even repa or yarr. Are there any future plans like that? Also it'd be interesting to add the distinction between covariant and contravariant indices, although this would be most likely a major change. Or perhaps it'd be possible to add it just as some kind of a wrapper. All the best, Petr

1 1

Regarding GSoC 2016
by Abhijit Patel 06 Jan '16

06 Jan '16

I am Abhijit Patel, B.Tech second year student from Dhirubhai Ambani Institute of Information and Communication Technology (DA-IICT) . I have learnt haskell from the learnyouahaskell.com and I was informed that the tasks for GSoC .I need some guidance and someone who can give me some tasks to raise my level to start contributing to the haskell community.

2 1

FRP : Best way to save signal history if the program needs to temporarily terminate?
by Zans Tangle 06 Jan '16

06 Jan '16

Hi guys, so I'm getting my head around FRP, and the theory is starting to make sense (just seen Conal Elliott's explanation of the original formulation and it was very illuminative). Overall I'm finding signals to be a really nice level of abstraction to reason about my code state. However I'm a little bit stuck on something: lets say I want to switch off the program, but I want it to save the signal history so that I can resume where I left off when I switch it back on. Is there a ... simple.. way to do it? Because at the moment I'm thinking of something along the lines of "build an SQL schema that matches the semantics of each FRP signal, and then build functions to translate between signal and SQL when needed". And at this precise instant I don't really feel too excited about implementing Signal-to-SQL translation from scratch (and I'm not even completely sure what sort of SQL schema would be needed to support higher-order FRP either), so I was wondering if anything like that exists already? Or even something as simple as storing the signal history in a file and just parsing it to recover it? Zans

3 2

the state of Yarr?
by Petr Pudlák 06 Jan '16

06 Jan '16

Hi Dominic, what is the current state of Yarr? Is it being actively developed? Is there some tutorial or documentation available? I'm deciding between repa and yarr for some linear algebra computations. I found some references that yarr is more performant, but I couldn't find much documentation and the hackage page [1] hasn't indexed most modules for some reason, so there seems to be no good place to start from. And the last commit was 9 months ago. [1] https://hackage.haskell.org/package/yarr Thank you, Petr

1 0

hscolour color set for white/light background?
by Conal Elliott 05 Jan '16

05 Jan '16

Does anyone have handy an hscolour ColourPrefs for use with a white/light background? The defaultColourPrefs <https://hackage.haskell.org/package/hscolour-1.23/docs/Language-Haskell-HsC…> look okay with a dark background but not light. Thanks, - Conal

1 0

Spurious memory leak example from the wiki
by Christopher Allen 05 Jan '16

05 Jan '16

I can't get the two examples (sum/product) in: https://wiki.haskell.org/Memory_leak#Holding_a_reference_for_a_too_long_time to behave differently under O2 or O0. Same profile report each time. Have changes to prelude (FTP? Rewrite rules/build stuff for folds?) made these do the same thing? The foldl/foldl' examples behave the same as you might expect. (216mb vs. 1mb of heap) --- Chris Allen

2 2

Compose Conference Call for Participation [NYC, Feb 4-5]
by Gershom B 04 Jan '16

04 Jan '16

=============================================== Call for Participation Compose Conference 2016 February 4-5, 2016 New York, NY http://www.composeconference.org/ =============================================== The practice and craft of functional programming :: Conference Compose is a conference for typed functional programmers, focused specifically on Haskell, OCaml, F#, SML, and related technologies. Typed functional programming has been taken up widely, by industry and hobbyists alike. For many of us it has renewed our belief that code should be beautiful, and that programming can be as enjoyable as it is practical. Compose is about bringing together functional programmers of all levels of skill and experience — from technical leads to novices, and from long-time hackers to students just getting started. It will feature a keynote by Eugenia Cheng on her work popularizing mathematics, two days of great talks, and plans are underway for a weekend hackathon/unconference. * Invited Talks: Eugenia Cheng: How to Bake 'How to Bake Pi': reflections on making abstract mathematics palatable * Local Information (venue): http://www.composeconference.org/2016/ * Accepted Talks and Tutorials Aditya Siram: FLTKHS - Easy Native GUIs in Haskell, Today! Austin Seipp: Cryptography and Verification with Cryptol Kenneth Foner: 'There and Back Again' and What Happened After Krzysztof Cieslak: Ionide and state of F# open source environment Leonid Rozenberg: The Intersection of Machine Learning, Types and Testing Luite Stegeman: Fun with GHCJSi Markus Mottl: AD-OCaml - Parallel Algorithmic Differentiation for OCaml Mindy Preston: Composing Network Operating Systems Niki Vazou: Liquid Types for Haskell Paulmichael Blasucci: (Nearly) Everything You Ever Wanted to Know About F# Active Patterns but were Afraid to Ask Rachel Reese: Chaos Testing at Jet Riccardo Terrell: Functional Reactive Programming for Natural User Interface Stephen Compall: Add a type parameter! One 'simple' design change, a panoply of outcomes Stephanie Weirich: Dynamic Typing in GHC Tikhon Jelvis: Analyzing Programs with Z3 Zvonimir Pavlinovic, Tim King and Thomas Wies: Improving Type Error Localization for Languages with Type Inference * Full abstracts: http://www.composeconference.org/2016/speakers/ * Registration: http://composeconference.eventbrite.com * Follow @composeconf on twitter for news: https://twitter.com/composeconf * On freenode irc, chat will fellow attendees at #composeconference * Corporate sponsorships are welcome. Current sponsors list forthcoming. * Policies (diversity and anti-harassment): http://www.composeconference.org/conduct * Email us with any questions at info(a)composeconference.org * Please forward this announcement to interested parties and lists.

1 0

Haskell popularity
by Henk-Jan van Tuyl 03 Jan '16

03 Jan '16

L.S., Haskell scores quite high on GitHub and Stack Overflow, see: http://redmonk.com/sogrady/2015/07/01/language-rankings-6-15/ Regards, Henk-Jan van Tuyl -- Folding@home What if you could share your unused computer power to help find a cure? In just 5 minutes you can join the world's biggest networked computer and get us closer sooner. Watch the video. http://folding.stanford.edu/ http://Van.Tuyl.eu/ http://members.chello.nl/hjgtuyl/tourdemonad.html Haskell programming --

5 4

wxHaskell + GHCi
by Henk-Jan van Tuyl 03 Jan '16

03 Jan '16

L.S., For people who gave up on wxHaskell in the past, because wxHaskell didn't run (properly) in GHCi: I just found out, that wxHaskell programs run properly in GHCi on Windows, if you use the newest wxHaskell plus GHC 7.10.3 (both the 32 bit and the 64 bit version). Regards, Henk-Jan van Tuyl -- Folding@home What if you could share your unused computer power to help find a cure? In just 5 minutes you can join the world's biggest networked computer and get us closer sooner. Watch the video. http://folding.stanford.edu/ http://Van.Tuyl.eu/ http://members.chello.nl/hjgtuyl/tourdemonad.html Haskell programming --

3 5