- Haskell-Cafe - Haskell.org

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 29 Mar '19

29 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 28 Mar '19

28 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

[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