March 2019 - Haskell-Cafe

[ANN] Haskell.Org Discourse Instance
by Jasper Van der Jeugt 08 Apr '19

08 Apr '19

Hello all, We would like to announce a new discourse-based forum for the Haskell community, at: https://discourse.haskell.org/ This is inspired by the Rust, Nix and Elm discourse instances, where these forums have had a strong positive effect on the community. We will run this as a "beta" for 6 months and then evaluate its usefulness. It is meant as an extra alternative to Haskell-cafe, reddit and Haskell IRC, but it does not replace any of those. Discourse is completely open source and easily accessible using an email client. We would like to thank the Haskell.Org admin team for provisioning a server and Matthew Pickering for suggesting this and doing the hard work setting up the instance. Warm regards, Jasper Van der Jeugt on behalf of the Haskell.Org Committee

4 3

Feedback on plan for checking code requirements in a GHC plugin
by Chris Smith 03 Apr '19

03 Apr '19

Hey everyone, I'm converging on a design for a new feature of CodeWorld, the Haskell-based educational programming environment that I teach with. I'm wondering if anyone has done something like this before. The goal is that when I give an assignment in a class (e.g., "modify this starting code to generalize the repeated pattern using a function"), I want the user to see a checklist of assignment requirements when they run the code. A prototype implementation is here: https://code.world/haskell#PpwpTF1wv3qIvwhohCfvSrQ There are all sorts of possible requirements, such as: "No lines longer than 80 characters", or "there must be a function called foo", or "all top-level definitions must have type signatures", or "your code must define at least 10 top-level variables, and use at least 3 where clauses", or "your definition of var should be equivalent to this one" (see Joachim Breitner's inspection testing work), or even "the function f must satisfy this QuickCheck property". It's been suggested that the requirements language also include the ability to match patterns in the AST, which I think is a good idea. The current prototype uses a pre-compile step that parses the code using haskell-src-exts, and doesn't implement dynamic requirements (runtime-evaluated) at all. My ultimate plan, though, is to send these requirements to GHC via a plugin, then have it evaluate the static ones at compile time, and generate code to check the dynamic ones. Finally, the plugin would add new code to the beginning of main that will invoke a configurable function with the results of the requirement check (hard-coding the static ones, and evaluating dynamic ones on the fly). (In the CodeWorld environment, this function would display the checklist in the web UI, for example.) Has anyone done anything like this before? Any wisdom to share, or ideas to contribute? Thanks, Chris

3 3

I fell in love with System.Console.Haskeline.getExternalPrint
by Mario Lang 31 Mar '19

31 Mar '19

Hi. Since I discovered getExternalPrint, I found a ton of use cases for it. In particular, it makes it possible to write background threads that report stuff to the console without disturbing the prompt. I ended up writing a sort of uGHCi with the help of hint and the unreleased master branch of haskeline[1] to make externalPrint available from within the interpreter. Combined with Shh, this opens the door for a lot of useful functionality. Here is a simplified example based on shell programming with the help of Shh: % let watch r p = forkIO . forever $ printProc p >> readIORef r >>= OS.sleep % delay <- newIORef 10 % clock <- watch delay OS.date Sat Mar 2 21:32:28 CET 2019 Sat Mar 2 21:32:38 CET 2019 % writeIORef delay 5 Sat Mar 2 21:32:48 CET 2019 Sat Mar 2 21:32:53 CET 2019 Sat Mar 2 21:32:58 CET 2019 Sat Mar 2 21:33:03 CET 2019 % killThread clock printProc uses externalPrint from haskeline to print the output of a shell command to the console without disturbing the prompt. The OS module in this example simply exports all executables as haskell functions, thanks to the TH magic from Shh. I am relying on a pretty crude hack to make this work: (rFd, wFd) <- liftIO createPipe eprint <- getExternalPrint -- from haskeline liftIO . forkIO . forever $ do (s, bc) <- fdRead rFd 1024 eprint s -- ... -- define a function in the interpreter using hint runStmt $ "let externalPrint s = fdWrite (read " <> show (show wFd) <> ") s >> pure ()" This hack is basically the whole magic of my own hand-rolled uGHCi. I'd love to not reinvent the wheel there, and just be able to use standard GHCi to make use of externalPrint. Question is, would a similar thing be possible to implement in GHCi directly, and if so, what would be required to make this work? I am likely far too much a rooky to get this working on my own, so I am asking for help. What steps should I follow to eventually achieve my goal? I guess submitting a feature request would be a start. However, I want progress, so I am wondering: * The pipe trick is likely too hacky for GHCi. Are there any other portable alternatives for getting data from within the interpreter to the haskell process running it? * Or is there a way to serialize an IO action into the interpreter that I've missed? The problem here is the boundary between the process that runs the interpreter, and the interpreter itself. I am a bit whacky on terminology here, but as I see it, getExternalPrint returns a function that has internal state. So it isn't really possible to make such a function available from within the interpreter. Hence, the pipe hack above, which just sends the *argument* to externalPrint from the interpreter to the process running it. Any insights that might help me make that available in standard GHCi? I really think this is a pretty unique feature that would enable all sorts of interesting interactive code. [1] Haskeline < 0.8.0 doesn't allow to combine IntterpreterT from hint with InputT because of the way exceptions are done. The master branch of haskeline fixes that, so finally you can have a transformer stack that combines both, allowing for pretty simple interactive haskell interpreters with readline functionality. Thanks for that! -- CYa, ⡍⠁⠗⠊⠕

2 1

Compose Second CFP & Keynote Speaker Announcement
by MightyByte 31 Mar '19

31 Mar '19

The April 23 submission deadline for Compose NYC is rapidly approaching, so get your submissions in soon. We are also excited to announce that we now have two confirmed keynote speakers: David Spivak - Compositional Graphical Logic Donya Quick - Making Algorithmic Music Compose is a conference focused specifically on strongly typed functional programming languages. It will be held in New York on Monday and Tuesday, June 24 -25, 2019. Registration will be open shortly. http://www.composeconference.org/2019 To get a sense of Compose, you can check out the great talks from past conferences: https://www.youtube.com/channel/UC0pEknZxL7Q1j0Ok8qImWdQ Below is our call for presentations. http://www.composeconference.org/2019/cfp/ In past years, we have also hosted an unconference over the weekend adjacent to the conference. The unconference details this year have not been finalized yet, but if you’re interested you may want to keep that in mind when making travel plans. *** Compose Conference NYC 2019 Second Call for Presentations June 24 -25, 2019 New York City The audience for Compose is people using Haskell, PureScript, OCaml, F#, SML, and other strongly typed functional programming languages who are looking to increase their skills or learn new technologies and libraries. Presentations should be aimed at teaching or introducing new ideas or tools. We are also interested in presentations aiming at taking complex concepts, such as program derivation, and putting them into productive use. However presentations on anything that you suspect our audience may find interesting are welcome. The following are some of the types of talks we would welcome: *Library/Tool Talks* — Exploring the uses of a powerful toolkit or library, be it for parsing, testing, data access and analysis, or anything else. *Production Systems* — Experience reports on deploying functional techniques in real systems; insights revealed, mistakes made, lessons learned. *Theory made Practical* — Just because it’s locked away in papers doesn’t mean it’s hard! Accessible lectures on classic results and why they matter to us today. Such talks can include simply introducing the principles of a field of research so as to help the audience read up on it in the future; from abstract machines to program derivation to branch-and-bound algorithms, the sky’s the limit. Check out the Compose YouTube channel ( https://www.youtube.com/playlist?list=PLNoHgLVTxtaoolkQo4hLy4ZsA1prUJ51m ) to see videos of talks we've had previously and get an idea of the kinds of topics we usually feature. We also welcome presentations for more formal tutorials. Tutorials should be aimed at a smaller audience of beginner-to-novice understanding, and ideally include hands-on exercises. The due date for submissions is *April 23, 2019*. We will send out notice of acceptance by *April 30th*. We prefer that submissions be via the EasyChair website ( https://easychair.org/conferences/?conf=compose2019 ). Please suggest a title, and describe the topic you intend to speak on. Talks can be either 30 or 45 minutes, please indicate how much time you would prefer to take. You may submit multiple talks if you have several ideas and are unsure which would be the most likely to be accepted. Accepted talks will be asked to submit slides for review prior to the conference. Feel free to include any additional information on both your expertise and interesting elements of your topic that would be appropriate for inclusion in the public abstract. Furthermore, if your abstract doesn't feel "final"—don't worry! We'll work with you to polish it up. If you want to discuss your presentation(s) before submitting, or to further nail down what you intend to speak on, please feel free to contact us at n...(a)composeconference.org ( n...(a)composeconference.org ). We're happy to work with you, even if you are a new or inexperienced speaker, to help your talk be great. Diversity We would like to put an emphasis on soliciting a diverse set of speakers - anything you can do to distribute information about this CFP and encourage submissions from under-represented groups would be greatly appreciated. We welcome your contributions and encourage you to apply! Best, Doug Sent via Superhuman ( https://sprh.mn/?vip=mightybyte@gmail.com )

1 0

[Job] Cloudseal seeks Haskell Software Engineers
by Ryan Newton 30 Mar '19

30 Mar '19

Dear fellow Haskellers, We're hiring! See below. -Ryan Newton Cloudseal co-founder, Professor of Computer Science (on leave), Functional programmer for 28 years, Haskeller for 10 *========================================================* We are looking for a Haskell software engineer who is passionate about developer technologies and changing how the world tests and runs software. Cloudseal is an early-stage startup, a spin-out from academic research on reliable (deterministic) software execution. Our core technology is a new containerization mechanism for Linux/x86 programs that enables reproducible builds and functional tests that never flake. You will be joining a growing team with decades of collective experience contributing to developer tools, including the GHC compiler and ecosystem, as well as developer products at Intel and Microsoft. *Skills sought* *-------------------* We are seeking curious and independent people ready to become involved with every part of product development. We are a Haskell+Rust shop, corresponding to the high- and low-level components of our stack, respectively, with this position focused on the former. Familiarity with low-level Linux systems software is not required but would be a positive. Experience with building services (authentication, billing) is a plus for this role. You should be comfortable with modern infrastructure essentials like AWS, Docker, CI, etc. and have passable sysadmin skills. Ability to work independently as part of a distributed development team is essential. This full-time position carries an option for remote work (within the U.S.), but geographic proximity to Philadelphia, Indianapolis, or Bloomington, IN would be preferred. During a ramp-up phase we will work on site together at a higher rate (25-50% travel), after which in-person team meetups will be less frequent. *Benefits* *------------* - Competitive salary & fringe benefits - Significant early-stage stock options - Flexible working hours and vacation time *Applying* *-------------* Email your resume to jobs(a)cloudseal.io. In your message, please share links to your previous work, such as running websites or open source contributions.

1 0

Resources/papers on lazy I/O
by Vanessa McHale 29 Mar '19

29 Mar '19

Hi all, I recently finished up writing streaming facilities via libarchive bindings and lazy bytestrings. It ended up working nicely - reading from a file lazily and then unpacking the archive was more efficient in time + allocations than reading the file all at once. That got me thinking - what exactly is wrong with lazy I/O? I've seen Oleg Kiselyov's paper (http://okmij.org/ftp/Haskell/#lazyIO-not-True) and I've run into issues myself (basically the issue here: https://stackoverflow.com/questions/31342012/read-and-writing-to-file-in-ha…) but none of those seem so pathological - the second issue could be better resolved with linear types! Are the any explanations of why Haskell *does* use lazy I/O? Laziness allows symmetries between values and generators of values - surely it is not *that* immoral to enforce this even in the IO monad? Cheers, Vanessa McHale

4 3

Open Position: Lecturer in Cybersecurity - University of Exeter
by Achim D. Brucker 29 Mar '19

29 Mar '19

Dear all, As part of the recent expansion of the Department of Computer Science (www.ex.ac.uk/computer-science/) at the University of Exeter, we are recruiting for a new Lecturer in Cybersecurity. You will join a growing department and will contribute to a new research focus in cybersecurity. This is a *unique* opportunity to join a new cybersecurity group as founding member and to influence its future development. Application in all areas of cybersecurity are welcome. Please apply by 4th of April 2019! See the full announcement and apply here: https://jobs.exeter.ac.uk/hrpr_webrecruitment/wrd/run/ETREC107GF.open?VACAN… Feel free to contact me for informal inquires about the post. Best, Achim -- Dr. Achim D. Brucker | Chair of Cybersecurity | University of Exeter https://www.brucker.ch | https://logicalhacking.com/blog @adbrucker | @logicalhacking

1 0

a bug in Read instance of Int?
by Javran Cheng 28 Mar '19

28 Mar '19

Hi Cafe, Not sure if there are existing discussions, but I recently run into a problem with Read instance of Int: Prelude> :set -XTypeApplications Prelude> reads @Int "123." [(123,".")] Prelude> reads @Int "123.aaa" [(123,".aaa")] Prelude> reads @Int "123.456aaa" [] -- I expected this to be [(123,".456aaa")] Prelude> reads @Double "123.234aaa" [(123.234,"aaa")] Further investigation shows that [realNumber]( http://hackage.haskell.org/package/base/docs/src/GHC.Read.html#readNumber) is used for Read instance of Int. I think what happened is that when the leading parser input can be parsed as a floating number, it will do so and commit to that decision, making backtracking impossible. I do understand that Read just need to be able to parse whatever Show can produce and is not designed to deal with raw inputs, but this is still a surprising behavior to me. When I'm using Text.ParserCombinators.ReadP, I really appreciates it that I can use `readP_to_S read` to parse simple values (integers and floating points in particular), but it bothers me that parsing Int from "123.aaa" is fine but "123.1aa" will fail simply because the not-yet-consumed part of input is different. Javran

3 3

art exhibition in London, April 2019
by Claude Heiland-Allen 28 Mar '19

28 Mar '19

Hi all, I have an art exhibition opening soon in London, UK. https://sonicelectronicsfestival.org/exhibition/ Featuring: - raytracing in curved space - badly-played tetris - generative techno - audiovisual sliding tile puzzle - interactive graph-directed IFS - zooming hybrid fractals Opening 11th April 2019 6pm, until 27th April, at Chalton Gallery, 96 Chalton Street, Camden, London NW1 1HJ, UK. Check website for times. Two of the works are realized with Haskell: - "Wedged" implements aesthetic constraints to search tetris packings - "Hybrids" uses a formula compiler to generate C code for rendering fractals Curated by Laura Netz. Supported using public funding by the National Lottery through Arts Council England. Claude -- https://mathr.co.uk

1 0

Call for Tutorial Proposals: ICFP 2019
by Sam Tobin-Hochstadt 27 Mar '19

27 Mar '19

CALL FOR TUTORIAL PROPOSALS ICFP 2019 24th ACM SIGPLAN International Conference on Functional Programming August 18 - 23, 2019 Berlin, Germany https://icfp19.sigplan.org/ The 24th ACM SIGPLAN International Conference on Functional Programming will be held in Berlin, Germany on August 18-23, 2019. ICFP provides a forum for researchers and developers to hear about the latest work on the design, implementations, principles, and uses of functional programming. Proposals are invited for tutorials, lasting approximately 3 hours each, to be presented during ICFP and its co-located workshops and other events. These tutorials are the successor to the CUFP tutorials from previous years, but we also welcome tutorials whose primary audience is researchers rather than practitioners. Tutorials may focus either on a concrete technology or on a theoretical or mathematical tool. Ideally, tutorials will have a concrete result, such as "Learn to do X with Y" rather than "Learn language Y". Tutorials may occur after ICFP co-located with the associated workshops, from August 22 till August 23. ---------------------------------------------------------------------- Submission details Deadline for submission: May 10th, 2019 Notification of acceptance: May 17th, 2019 Prospective organizers of tutorials are invited to submit a completed tutorial proposal form in plain text format to the ICFP 2018 workshop co-chairs (Jennifer Hackett and Christophe Scholliers), via email to icfp-workshops-2019(a)googlegroups.com by May 10th, 2019. Please note that this is a firm deadline. Organizers will be notified if their event proposal is accepted by May 17, 2019. The proposal form is available at: http://www.icfpconference.org/icfp2019-files/icfp19-tutorials-form.txt ---------------------------------------------------------------------- Selection committee The proposals will be evaluated by a committee comprising the following members of the ICFP 2019 organizing committee. Tutorials Co-Chair: Jennifer Hackett (University of Nottingham) Tutorials Co-Chair: Christophe Scholliers (University of Ghent) General Chair: Derek Dreyer (MPI-SWS) Program Chair: François Pottier ( Inria, France) ---------------------------------------------------------------------- Further information Any queries should be addressed to the tutorial co-chairs ( Jennifer Hackett and Christophe Scholliers), via email to icfp-workshops-2019(a)googlegroups.com

1 0