March 2019 - Haskell-Cafe

[TFPIE'19] Call for papers: Trends in Functional Programming in Education 2019, 11 June 2019, Vancouver, BC, CA
by Peter Achten 27 Mar '19

27 Mar '19

TFPIE 2019 Call for papers http://www.staff.science.uu.nl/~hage0101/tfpie2019/index.html (June 11th, University of British Columbia, Vancouver Canada, co-located with TFP 2019) TFPIE 2019 welcomes submissions describing techniques used in the classroom, tools used in and/or developed for the classroom and any creative use of functional programming (FP) to aid education in or outside Computer Science. Topics of interest include, but are not limited to: FP and beginning CS students FP and Computational Thinking FP and Artificial Intelligence FP in Robotics FP and Music Advanced FP for undergraduates FP in graduate education Engaging students in research using FP FP in Programming Languages FP in the high school curriculum FP as a stepping stone to other CS topics FP and Philosophy The pedagogy of teaching FP FP and e-learning: MOOCs, automated assessment etc. Best Lectures Ð more details below In addition to papers, we are requesting best lecture presentations. What's your best lecture topic in an FP related course? Do you have a fun way to present FP concepts to novices or perhaps an especially interesting presentation of a difficult topic? In either case, please consider sharing it. Best lecture topics will be selected for presentation based on a short abstract describing the lecture and its interest to TFPIE attendees. The length of the presentation should be comparable to that of a paper. On top of the lecture itself, the presentation can also provide commentary on the lecture. Submissions Potential presenters are invited to submit an extended abstract (4-6 pages) or a draft paper (up to 16 pages) in EPTCS style. The authors of accepted presentations will have their preprints and their slides made available on the workshop's website. Papers and abstracts can be submitted via easychair at the following link: https://easychair.org/conferences/?conf=tfpie2019 After the workshop, presenters will be invited to submit (a revised version of) their article for review. The PC will select the best articles that will be published in the Electronic Proceedings in Theoretical Computer Science (EPTCS). Articles rejected for presentation and extended abstracts will not be formally reviewed by the PC. Dates Submission deadline: May 14th 2019, Anywhere on Earth. Notification: May 20th Workshop: June 11th Submission for formal review: August 18th 2019, Anywhere on Earth Notification of full article: October 6th Camera ready: November 1st Program Committee Alex Gerdes - University of Gothenburg / Chalmers Jurriaan Hage (Chair) - Utrecht University Pieter Koopman - Radboud University, the Netherlands Elena Machkasova - University of Minnesota, Morris, USA Heather Miller - Carnegie Mellon University and EPFL Lausanne Prabhakar Ragde - University of Waterloo, Waterloo, Ontario, Canada Simon Thompson - University of Kent, UK Sharon Tuttle - Humboldt State University, Arcata, USA Note: information on TFP is available at https://www.tfp2019.org/index.html

1 0

GSoC 2019 Student Applications now open
by Jasper Van der Jeugt 26 Mar '19

26 Mar '19

Hi all, We'd like to remind you that Google has opened student applications for Google Summer of Code 2019 [1]. Applications can be submitted through their dashboard [2]. If you are thinking of applying, there is a list of ideas submitted by our wonderful community [3] that can serve as inspiration. Of course, we also welcome other proposals! Please contact us [4] if you have any other question about the program. Warm regards Jasper Van der Jeugt on behalf of the Haskell.Org Committee [1]: https://summerofcode.withgoogle.com/ [2]: https://summerofcode.withgoogle.com/dashboard/ [3]: https://summer.haskell.org/ideas.html [4]: https://summer.haskell.org/contact.html

1 0

Munich Haskell Meeting, 2019-03-27 @ 19:30
by Leah Neukirchen 25 Mar '19

25 Mar '19

Dear all, Next week, our monthly Munich Haskell Meeting will take place again on Wednesday, March 27 at Rumpler at 19h30. For details see here: http://muenchen.haskell.bayern/dates.html If you plan to join, please add yourself to this dudle so we can reserve enough seats! It is OK to add yourself to the dudle anonymously or pseudonymously. https://dudle.inf.tu-dresden.de/haskell-munich-mar-2019/ Everybody is welcome! cu & see you perhaps tomorrow at Munich Lambda meetup, -- Leah Neukirchen <leah(a)vuxu.org> http://leahneukirchen.org/

3 2

sublime-haskell and hsdev
by Dennis Raddle 22 Mar '19

22 Mar '19

I'm just now learning Sublime Text 3 and trying to install sublime-haskell. It requires me to build hsdev, which I did with "cabal install hsdev". However the latter operation installs version > 3 of hsdev, while sublime-haskell requires < 3. So first question, how do I build and install an earlier version of hsdev? Also, I'm not clear if sublime-haskell is integrated with stack. I use stack for everything and I've been using Intero up til now in Emacs. The docs mention stack but seem to be clearer about cabal. D

2 1

RedMonk ranks Haskell among top 20 most popular programming languages
by Jeffrey Brown 22 Mar '19

22 Mar '19

based on GitHub and StackOverflow. https://redmonk.com/sogrady/2019/03/20/language-rankings-1-19/ -- Jeff Brown | Jeffrey Benjamin Brown Website <https://msu.edu/~brown202/> | Facebook <https://www.facebook.com/mejeff.younotjeff> | LinkedIn <https://www.linkedin.com/in/jeffreybenjaminbrown>(spammy, so I often miss messages here) | Github <https://github.com/jeffreybenjaminbrown>

1 0

More graph algorithms for Alga & Streaming JSON/YAML parser
by Shiv 22 Mar '19

22 Mar '19

Dear mentors, I am Shiv Pratap Singh from IIIT-Allahabad, India. I am currently in 4th year and Computer Science Undergraduate. After lot of brainstorming and carefully choosing the project idea based on my skills/expertise/experience, I am highly interested in project idea mentioned in Subject of the mail. As the proposal submission date is very close, I am keen to discuss the idea in depth so that various subtasks can be finalized .If any prior contribution/patch is requirement for applying, please let me know. Please mention some resources links in order to gain insights on project. Hoping to work together! Thank you, Shiv

2 2

[ANN] libarchive
by Vanessa McHale 20 Mar '19

20 Mar '19

Hi all, I just released libarchive (http://hackage.haskell.org/package/libarchive) which can be used to create and unpack tar archives as well as several other formats. It has a reasonably complete high-level API and full bindings to the C library. Cheers, Vanessa McHale

1 0

Yet another binary reader (10x faster than Hackage's binary; )
by Станислав Черничкин 20 Mar '19

20 Mar '19

I was investigating Haskell’s binary serialization libraries and has found that lot of them (binary, cereal and protocol-buffers) has pretty similar design. They capable to consume lazy bytestrings and either produce result, report error or produce partial result, indicating that more input data required. Such design leads to quite complex readers, and often ends up with producing closures in runtime. If you take a close look at binary’s microbenches (binary in general bit faster than cereal, so I focused on binary) you will discover, that it triggers GC even during simple tasks, such as reading a bunch of Word64 and summing results. And it relatively slow. Binary’s performance limited to hundreds of megabytes per second even in simple scenarios, but actual memory bandwidth should allow us process gigabytes per second. So, I decided to try a different approach. My approach is based on two assumptions so if it does not suit your case it obliviously will not work for you. First – when dealing with binary data we always know exactly how many bytes we want to read. This happens because we either read a fixed size primitive type or length-prefixed variable size data (possibly not “prefixed”, but you always know expected message length from somewhere). Second – chunks of data are continuous. I.e. we working with strict bytestrings more often. Even when you processing chunked stream of data with unknown number of messages (such as Mesos RecordIO Format) you should always be able to allocate continuous memory buffer for a single entity you want to deserialize. If it’s ok for you lets go on. First thing I’ve created was so called static reader. Static – because reader knows how mush bytes it wants to consume at compile time. Such readers suitable for reading combinations of primitive values. Here the implementation https://github.com/PROTEINE-INSAIDERS/lev-tolstoy/blob/master/src/Lev/Reade… Static reader is somewhat monadic (you can use do-syntax with RebindableSyntax extension like here https://github.com/PROTEINE-INSAIDERS/lev-tolstoy/blob/master/bench/Bench/L… ) but it actually indexed monad and it unfortunately incompatible with traditional monads. Offsets and sizes are calculates at type level during the compile time and according to microbences static reader does not introduced any overhead compared to hand-written reader using the low-level indexInt64OffAddr# function ( https://github.com/PROTEINE-INSAIDERS/lev-tolstoy/blob/master/bench/Bench/H… ) Next thing was a dynamic reader. Dynamic readers are composed from static readers, they are fully monadic and allow you to read length-prefixed data structures (you read length with wrapped static reader and then perform normal monadic binding to supply a reader which reads a value). Here the implementation https://github.com/PROTEINE-INSAIDERS/lev-tolstoy/blob/master/src/Lev/Reade… I’ve discovered, that typeclasses are surprisingly fast. So, it’s completely ok to have something like “(Cursor c) => … Reader” where cursor contains functions for overflow checking and memory buffer progression. I was not able to achieve same performance when I passed buffer callbacks explicitly, possibly because of inlining of specialization magic. So, I've created ByteStringCursor ( https://github.com/PROTEINE-INSAIDERS/lev-tolstoy/blob/master/src/Lev/Reade… ) which allows to read strict bytestrings. I suppose that cursors introduce flexibility: you may read strict bytestring or you may define custom cursor for reading custom memory buffers. Finally, I’ve written some microbenches for my cases and also ported one microbench from binary. And my implementation was able to run 10x-15x faster than binary on strict bytestring. Moreover, it does not trigger GC during the run at all! You may find the project and all the benches here https://github.com/PROTEINE-INSAIDERS/lev-tolstoy So, what's the purpose of my message? It’s quite unlikely that I’ll release my code on the Hackage. This is because I’m a hobbyist Haskell developer and doing it all in my free time. But before mr. Putin will close Internet in Russia I’d like to demonstrate that it’s possible to write very fast binary deserializer taking in account several assumptions which seems quite reasonably for me. So, feel free to borrow the ideas, or share the ideas, if you know how it could be implemented better. -- Sincerely, Stanislav Chernichkin.

4 4

Re: [Haskell-cafe] Yet another binary reader (10x faster than Hackage's binary)
by Olaf Klinke 20 Mar '19

20 Mar '19

My (admittedly limited) experience with parsers, of which deserializers are a special case, is that with complicated data structures the majority of computing time is spent transforming the raw data (i.e. chunks of bytes) into meaningful information such as Doubles, Timestamps, tree structures and so on. Of course you could argue that such conversions are not the scope of the deserializer and that these operations must be performed regardless which library one chooses. Nevertheless it somewhat relativizes the importance of the choice of serializing library. Your benchmarks do not go beyond adding integers as far as I can see, which is a relatively cheap operation. I'd be interested in a benchmark where e.g. a huge Set or an array of custom records are used. You seem to work in bioinformatics. There are plenty of examples from this field, e.g. genomic annotations. Cheers, Olaf

1 0

Re： Yet another binary reader (10x faster thanHackage's binary; )
by Dr.Koster 20 Mar '19

20 Mar '19

These two assumptions are basically the most challenging issues stop people from getting more performance, e.g. If somehow you want to support incremental parsing, a primitive like `ensureN` probably need to do something like ``` ensureN n = Parser $ \ buf ... k -> if n < length buf then k buf ... else partial buf ... k ``` The k appear twice inside `ensureN` 's both branch, which will stop parsers from getting inline sooner or later since inlining k into both branch will produce exponential amount of code, so instead GHC will allocate k and make a jump, the best we can get is probably to try make it a joint point, so no allocation is needed, but that's the best you can get from argument passing buffers. Regards Han Dong ------------------ 原始邮件 ------------------ 发件人: "Joachim Durchholz"<jo(a)durchholz.org>; 发送时间: 2019年3月20日(星期三) 中午1:28 收件人: "haskell-cafe"<haskell-cafe(a)haskell.org>; 主题: Re: [Haskell-cafe] Yet another binary reader (10x faster thanHackage's binary; ) Am 19.03.19 um 22:58 schrieb Станислав Черничкин: > possibly because of inlining of > specialization magic. I have seen people validate this kind of assumption, by looking at the various intermediate representations of code. If you're after performance, you may want to do that. You may find that things work differently than expected, with the potential for becoming a bottleneck when stuff is scaled up (more varied datatypes in the input stream, or more complex target datatypes, stuff hidden behind "oh I don't need GC yet", that kind of finding). Regards, Jo _______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post.

2 1