June 2019 - Haskell-Cafe

Looking for a paper
by Michael Orlitzky 05 Jun '19

05 Jun '19

Everyone knows that parentheses suck for function application. But I'm looking for a CS paper that argues that function application should have its own explicit syntax in a functional programming language. I believe, in the paper, that a dot "." was used, but this would be analogous to Haskell's "$" function, except that it would be made part of the language definition. I think it came up on this mailing list (where else would I have seen it?), and if anyone remembers the name or author I'd be grateful.

5 9

conduit/pipes/streaming and prompt cleanup
by Evan Laforge 04 Jun '19

04 Jun '19

I'm using the 'streaming' library and realized it doesn't close files in a timely way for the way I'm using it, and in fact can't, due to how the library works. I know conduit has put a lot of thought into closing resources in a timely way, so I did an experiment to see what it does, but as far as I can tell, conduit has the same problem. Maybe I'm doing it wrong? The situation is that I'm opening multiple files and mixing their output. I want to close the inputs as soon as I'm done with them. But I can get done with them earlier than the end of the file. Since all of these libraries are based on pulling from downstream, if you don't pull all the way to the end, the close at the end doesn't happen, and has to wait until runResourceT returns, which is too late. I remember long ago reading Oleg's original iteratee paper, and it seems like he called out this problem with pull-based iterators, that the iterator doesn't know when its caller is done with it, so it can't close files on time. Here's a conduit version that I think illustrates the situation: import qualified Conduit as C import Conduit ((.|)) import qualified Control.Monad.Trans as Trans import qualified System.IO as IO main :: IO () main = C.runResourceT $ C.runConduit pipe pipe :: C.ConduitM a c (C.ResourceT IO) () pipe = fileLines "TODO" .| (C.takeC 3 >> C.yield "***") .| C.mapM_C (Trans.liftIO . putStrLn) fileLines :: C.MonadResource m => FilePath -> C.ConduitT i String m () fileLines fname = C.bracketP (IO.openFile fname IO.ReadMode) close handleLines handleLines :: Trans.MonadIO m => IO.Handle -> C.ConduitT i String m () handleLines hdl = loop where loop = do eof <- Trans.liftIO $ IO.hIsEOF hdl if eof then return () else do line <- Trans.liftIO $ IO.hGetLine hdl C.yield line loop close :: IO.Handle -> IO () close hdl = IO.hClose hdl >> putStrLn "=== close" This prints the first three lines of TOOD, then ***, and then "=== close", where the close should go before the ***s. As far as I can see, conduit can't do this any more than 'streaming' can, because 'C.takeC' is just some awaits and yields, with no indication that the final await is more special than any other await. I think what would be necessary to solve this is that combinators like 'take' have to be able to tell the stream to close, and that has to propagate back up to each producer that has registered a cleanup. Of course this renders the stream invalid, so it's not safe to have any other references to the stream around, but I guess streams are stateful in general so that's always true. Maybe I could accumulate the finalizers in the stream data type and have combinators like 'take' call it as soon as they've taken their last. What I actually wound up doing was make a 'takeClose' that also takes a 'close' action to run when its done with the stream. It's not exactly general but I'm not writing a library so I don't need general. Is there some kind of standard or built-in solution for this situation? I know others have given a lot more thought to streaming than I have, so surely this issue has come up. I know there is a lot of talk about "prompt finalisation" and streams vs. pipes vs. conduit, and talk about brackets and whatnot, but despite reading various documents (https://hackage.haskell.org/package/streaming-with, http://www.haskellforall.com/2013/01/pipes-safe-10-resource-management-and.…, etc.) I still don't really understand what they're talking about. It seems like they're really about reliable cleanup when there are exceptions, not really about prompt cleanup. Certainly pipes-safe doesn't do prompt cleanup, at least not the kind I'm talking about.

2 2

Second Call for Submissions: ICFP Student Research Competition
by Sam Tobin-Hochstadt 03 Jun '19

03 Jun '19

ICFP 2019 Student Research Competition Call for Submissions ICFP invites students to participate in the Student Research Competition in order to present their research and get feedback from prominent members of the programming language research community. Please submit your extended abstracts through the submission website. ### Important dates Submissions due: 14 Jun 2019 (Friday) https://icfp19src.hotcrp.com Notification: 28 Jun 2019 (Friday) Conference: 18 August (Sunday) - 23 August (Friday) Each submission (referred to as "abstract" below) should include the student author’s name and e-mail address; institutional affiliation; research advisor’s name; ACM student member number; category (undergraduate or graduate); research title; and an extended abstract addressing the following: * Problem and Motivation: Clearly state the problem being addressed and explain the reasons for seeking a solution to this problem. * Background and Related Work: Describe the specialized (but pertinent) background necessary to appreciate the work in the context of ICFP areas of interest. Include references to the literature where appropriate, and briefly explain where your work departs from that done by others. * Approach and Uniqueness: Describe your approach in addressing the problem and clearly state how your approach is novel. * Results and Contributions: Clearly show how the results of your work contribute to programming language design and implementation in particular and to computer science in general; explain the significance of those results. * Submissions must be original research that is not already published at ICFP or another conference or journal. One of the goals of the SRC is to give students feedback on ongoing, unpublished work. Furthermore, the abstract must be authored solely by the student. If the work is collaborative with others and*or part of a larger group project, the abstract should make clear what the student’s role was and should focus on that portion of the work. * Formatting: Submissions must be in PDF format, printable in black and white on US Letter sized paper, and interpretable by common PDF tools. All submissions must adhere to the "ACM Small" template that is available (in both LaTeX and Word formats) from https://www.acm.org/publications/authors/submissions. For authors using LaTeX, a lighter-weight package, including only the essential files, is available from http://sigplan.org/Resources/Author/#acmart-format. The submission must not exceed 3 pages in PDF format. Reference lists do not count towards the 3-page limit. Further information is available at the ICFP SRC website: https://icfp19.sigplan.org/track/icfp-2019-Student-Research-Competition ICFP Student Research Competition Chair: William J. Bowman (University of British Columbia)

1 0

ANN: stack-2.1 second release candidate
by Emanuel Borsboom 03 Jun '19

03 Jun '19

Announcing the second release candidate for Stack 2.1! This is the version that will be released one week from now if there aren't any major issues discovered, so please give it a try. You can download bindists for Linux, macOS, and Windows from https://github.com/commercialhaskell/stack/releases/tag/v2.1.0.3 **Changes since v2.1.0.1** Other enhancements: * Add `--docker-mount-mode` option to set the Docker volume mount mode for performance tuning on macOS. Bug fixes: * Fix regression where `stack --docker` would quit after 20 seconds on macOS.

1 0