- Haskell-Cafe - Haskell.org

Request for Nominations to the GHC Steering Committee
by Joachim Breitner 13 Jun '19

13 Jun '19

Dear Haskell community, the GHC Steering committee is seeking nominations for two or three new member. The committee scrutinizes, nitpicks, improves, weights and eventually accepts or rejects proposals that extend or change the language supported by GHC and other (public-facing) aspects of GHC. Our processes are described at https://github.com/ghc-proposals/ghc-proposals which is also the GitHub repository where proposals are proposed. We are looking for a member who has the ability * to understand such language extension proposals, * to find holes and missing corner cases in the specifications, * foresee the interaction with other language features and specifications, * comment constructively and improve the proposals, * judge the cost/benefit ratio and * finally come to a justifiable conclusion. We look for committee members who have some of these properties: * have substantial experience in writing Haskell applications or libraries, which they can use to inform judgements about the utility or otherwise of proposed features, * have made active contributions to the Haskell community, for some time, * have expertise in language design and implementation, in either Haskell or related languages, which they can share with us. The committee’s work requires a small, but non-trivial amount of time, especially when you are assigned a proposal for shepherding. We estimate the workload to be around 2 hours per week, and our process works best if members usually respond to technical emails within 1-2 weeks (within days is even better). Please keep that in mind if your email inbox is already overflowing. The GHC developers themselves are already well represented already. We seek Haskell _users_ more than GHC hackers. There is no shortage of people who are eager to get fancy new features into the language, both in the committee and the wider community. But each new feature imposes a cost, to implement, to learn, (particularly) through its unexpected interaction with other features. We need to strike a balance, one that encourages innovation (as GHC always has) while still making Haskell attractive for real-world production use and for teaching. We therefore explicitly invite “conservative” members of the community to join the committee. To make a nomination, please send an email to me (as the committee secretary) at mail(a)joachim-breitner.de until June 23th. I will distribute the nominations among the committee, and we will keep the nominations and our deliberations private. We explicitly encourage self-nominations. You can nominate others, but please obtain their explicit consent to do so. (We don’t want to choose someone who turns out to be unable to serve.) On behalf of the committee, Joachim Breitner -- Joachim Breitner mail(a)joachim-breitner.de http://www.joachim-breitner.de/

1 0

Is there any place with nightly/master builds of GHC?
by Changlin Li 13 Jun '19

13 Jun '19

I'm interested in benchmarking GHC compile times (that is how long it takes GHC to compile a given file) on a more granular basis than official releases. It would be nice to save myself the hassle of re-building GHC across many different commits if there already was some archive of GHC builds (e.g. from master), even if it's a rolling archive over a short time window (e.g. per-week). Changlin

3 3

Final Call for Participation: Compose Conference [NYC, Jun 22- 23 2019]
by Gershom B 12 Jun '19

12 Jun '19

=============================================== Final Call for Participation Compose Conference 2019 Mon June 24 - Tue June 25 2019 (Unconference on Sat Jun 22 - Sun Jun 23) New York, NY Deadline for registration: June 14 at 11pm EST. http://www.composeconference.org/2019 =============================================== 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 two days of great and wide-ranging talks * Invited Keynotes Donya Quick - Making Algorithmic Music David Spivak - Compositional Graphical Logic * Accepted Talks and Tutorials Kenny Foner - Functors of the World, Unite! Phillip Carter - The anatomy of the F# tools for Visual Studio Sebastien Mondet - Genspio: Generating Shell Phrases In OCaml Justin Le - Applicative Regular Expressions using the Free Alternative Gaetano Checinski - Buckaroo SAT - Solving a partially revealed SAT problem for Package Management Richard Feldman - From Rails to Elm and Haskell Samuel Gélineau - Stuck macros: deterministically interleaving macro-expansion and typechecking Vaibhav Sagar - Yes, IHaskell Can Do That! Fintan Halpenny - Bowl Full of Lentils Aditya Siram - A Tase Of ATS Ward Wheeler, Alex Washburn, Callan McGill - Phylogenetic Software in Haskell Igor Trindade Oliveira - Type Driven Secure Enclave Development using Idris David Christiansen - Bidirectional Type Checking Chris Smith - Teaching the intersection of mathematics and functional programming Brandon Kase - Fast Accumulation on Streams James Koppel - The Best Refactoring You’ve Never Heard Of Allister Beharry - Using Dependent Types in an F# DSL for Linear Algebra Diego Balseiro - Bridge Haskell and ReasonML in Production * Full abstracts: http://www.composeconference.org/2019/program * Conference Registration: https://www.eventbrite.com/e/new-york-compose-2019-tickets-56751182314 * Unconference Registration: https://www.eventbrite.com/e/new-york-compose-unconference-2019-tickets-603… * Follow @composeconf on twitter for news: https://twitter.com/composeconf * On freenode irc, chat with 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

creating dll fails: missing references
by Kees Bleijenberg 11 Jun '19

11 Jun '19

HI all, I try to create a dll with ghc (ver 8.6.5) on Windows 7 64 bits. I 'am using the dll with loadLibrary in a cpp program in Visual Studio. I create the dll with: ghc Vogels.hs ghc -c StartEnd.c ghc --make -static -shared -fPIC Vogels.o StartEnd.o -o Vogels.dll StartEnd.o defines HsStart and HsEnd to initialize and close the Haskell runtime. This works. I can create the dll and use the dll in VS. But, if I replace in Vogels.hs the line b=True with b <- doesFileExist vogelsFn, creating the dll fails with error message: Vogels.o:fake:(.text+0x35c): undefined reference to `directoryzm1zi3zi3zi2zmB9tglvOQ6L9Cf7zzVEJ1S6t_SystemziDirectory_doesFileEx ist_closure' Vogels.o:fake:(.text+0x37d): undefined reference to `directoryzm1zi3zi3zi2zmB9tglvOQ6L9Cf7zzVEJ1S6t_SystemziDirectory_doesFileEx ist_closure' Vogels.o:fake:(.data+0xd0): undefined reference to `directoryzm1zi3zi3zi2zmB9tglvOQ6L9Cf7zzVEJ1S6t_SystemziDirectory_doesFileEx ist_closure' It looks like GHC can't find the Directory package. I've installed this package. What can I do about it and how can I find out the dependencies in a *.hs or *.o file? Almost all documentation about dll's is about Linux or about using dll's in Haskell. Kees {-# LANGUAGE BlockArguments #-} {-# LANGUAGE ForeignFunctionInterface #-} module Vogels ( loadVogels ) where import System.Directory import Foreign.Ptr import Foreign.Storable import Foreign.C.String loadVogels :: String -> IO (Either String String) loadVogels vogelsFn = do -- b <- doesFileExist vogelsFn let b=True if b then return $ Left $ "Can\'t find " ++ vogelsFn else do txt <- readFile vogelsFn return $ Right txt loadVogelsFFI :: Ptr Int -> CString -> IO CString loadVogelsFFI messageKind vogelsFnFFI = do vogelsFn <- peekCString vogelsFnFFI eitherRes <- loadVogels vogelsFn case eitherRes of Left errMsg -> do poke messageKind 1 newCString errMsg Right txt -> do poke messageKind 0 newCString txt foreign export ccall loadVogelsFFI :: Ptr Int -> CString -> IO CString --- Dit e-mailbericht is gecontroleerd op virussen met Avast antivirussoftware. https://www.avast.com/antivirus

2 1

Assistant/Associate Professorships in Nottingham
by Graham Hutton 10 Jun '19

10 Jun '19

Dear all, As part of a strategic expansion, the School of Computer Science at the University of Nottingham is seeking to make multiple new appointments at the Assistant or Associate Professor level: https://tinyurl.com/y4qfdqps https://tinyurl.com/y2uw6tsa Applications in the area of the Functional Programming (FP) lab are strongly encouraged! The FP lab is keen to receive applications from candidates with an excellent publication record (e.g. papers in leading venues such as LICS, POPL, ICFP, JFP, TOPLAS, etc) and the ability to secure external funding to support their research. Further information about the FP lab is available from: https://tinyurl.com/y2ekdkqa The deadline for applications is Monday 8th July 2019. The advert mentions some specific research areas, but the positions are open to applicants from any area of Computer Science. -- Graham Hutton and Thorsten Altenkirch This message and any attachment are intended solely for the addressee and may contain confidential information. If you have received this message in error, please contact the sender and delete the email and attachment. Any views or opinions expressed by the author of this email do not necessarily reflect the views of the University of Nottingham. Email communications with the University of Nottingham may be monitored where permitted by law.

1 0

Re: [Haskell-cafe] conduit/pipes/streaming and prompt cleanup - using a decorator
by Daniel Díaz 10 Jun '19

10 Jun '19

I tried to tackle this problem in my "streaming-bracketed" library http://hackage.haskell.org/package/streaming-bracketed, by using a "decorator" that wraps regular streams, as opposed to having a resource-aware base monad. When lifting take-like functions to the decorator, new deallocation actions are inserted. On Tue, Jun 4, 2019 at 2:53 PM <haskell-cafe-request(a)haskell.org> wrote: > 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 1

Final call for regular papers for IFL 2019 (Implementation and Application of Functional Languages)
by Jurriaan Hage 07 Jun '19

07 Jun '19

Hello, Please, find below the call for papers for IFL 2019. With respect to the previous call, the deadline for submitting regular papers has been changed to June 15th. Please forward these to anyone you think may be interested. Apologies for any duplicates you may receive. best regards, Jurriaan Hage Publicity Chair of IFL --- ================================================================================ IFL 2019 31st Symposium on Implementation and Application of Functional Languages National University of Singapore September 25th-27th, 2019 http://2019.iflconference.org ================================================================================ ### Scope The goal of the IFL symposia is to bring together researchers actively engaged in the implementation and application of functional and function-based programming languages. IFL 2019 will be a venue for researchers to present and discuss new ideas and concepts, work in progress, and publication-ripe results related to the implementation and application of functional languages and function-based programming. Topics of interest to IFL include, but are not limited to: - language concepts - type systems, type checking, type inferencing - compilation techniques - staged compilation - run-time function specialization - run-time code generation - partial evaluation - (abstract) interpretation - metaprogramming - generic programming - automatic program generation - array processing - concurrent/parallel programming - concurrent/parallel program execution - embedded systems - web applications - (embedded) domain specific languages - security - novel memory management techniques - run-time profiling performance measurements - debugging and tracing - virtual/abstract machine architectures - validation, verification of functional programs - tools and programming techniques - (industrial) applications ### Keynote Speaker * Olivier Danvy, Yale-NUS College ### Submissions and peer-review Differently from previous editions of IFL, IFL 2019 solicits two kinds of submissions: * Regular papers (12 pages including references) * Draft papers for presentations ('weak' limit between 8 and 15 pages) Regular papers will undergo a rigorous review by the program committee, and will be evaluated according to their correctness, novelty, originality, relevance, significance, and clarity. A set of regular papers will be conditionally accepted for publication. Authors of conditionally accepted papers will be provided with committee reviews along with a set of mandatory revisions. Regular papers not accepted for publication will be considered as draft papers, at the request of the author. Draft papers will be screened to make sure that they are within the scope of IFL, and will be accepted for presentation or rejected accordingly. Prior to the symposium: Authors of conditionally accepted papers and accepted presentations will submit a pre-proceedings version of their work that will appear in the draft proceedings distributed at the symposium. The draft proceedings does not constitute a formal publication. We require that at least one of the authors present the work at IFL 2019. After the symposium: Authors of conditionally accepted papers will submit a revised versions of their paper for the formal post-proceedings. The program committee will assess whether the mandatory revisions have been adequately addressed by the authors and thereby determines the final accept/reject status of the paper. Our interest is to ultimately accept all conditionally accepted papers. If you are an author of a conditionally accepted paper, please make sure that you address all the concerns of the reviewers. Authors of accepted presentations will be given the opportunity to incorporate the feedback from discussions at the symposium and will be invited to submit a revised full article for the formal post-proceedings. The program committee will evaluate these submissions according to their correctness, novelty, originality, relevance, significance, and clarity, and will thereby determine whether the paper is accepted or rejected. ### Publication The formal proceedings will appear in the International Conference Proceedings Series of the ACM Digital Library. At no time may work submitted to IFL be simultaneously submitted to other venues; submissions must adhere to ACM SIGPLAN's republication policy: http://www.sigplan.org/Resources/Policies/Republication ### Important dates Submission of regular papers: June 15, 2019 Submission of draft papers: July 15, 2019 Regular and draft papers notification: August 1, 2019 Deadline for early registration: August 15, 2019 Submission of pre-proceedings version: September 15, 2019 IFL Symposium: September 25-27, 2019 Submission of papers for post-proceedings: November 30, 2019 Notification of acceptance: January 31, 2020 Camera-ready version: February 29, 2020 ### Submission details All contributions must be written in English. Papers must use the ACM two columns conference format, which can be found at: http://www.acm.org/publications/proceedings-template Authors submit through EasyChair: https://easychair.org/conferences/?conf=ifl2019 ### Peter Landin Prize The Peter Landin Prize is awarded to the best paper presented at the symposium every year. The honored article is selected by the program committee based on the submissions received for the formal review process. The prize carries a cash award equivalent to 150 Euros. ### Organization and Program committee Chairs: Jurrien Stutterheim (Standard Chartered Bank Singapore), Wei Ngan Chin (National University of Singapore) Program Committee: - Olaf Chitil, University of Kent - Clemens Grelck, University of Amsterdam - Daisuke Kimura, Toho University - Pieter Koopman, Radboud University - Tamas Kozsik, Eotvos Lorand University - Roman Leschinskiy, Facebook - Ben Lippmeier, The University of New South Wales - Marco T. Morazan, Seton Hall University - Sven-Bodo Scholz, Heriot-Watt University - Tom Schrijvers, Katholieke Universiteit Leuven - Alejandro Serrano, Utrecht University - Tony Sloane, Macquarie University - Simon Thompson, University of Kent - Marcos Viera, Universidad de la Republica - Wei Ngan Chin, NUS - Jurrien Stutterheim, Standard Chartered Bank ### Venue The 31st IFL is organized by the National University of Singapore. Singapore is located in the heart of South-East Asia, and the city itself is extremely well connected by trains and taxis. See the website for more information on the venue. ### Acknowledgments This call-for-papers is an adaptation and evolution of content from previous instances of IFL. We are grateful to prior organizers for their work, which is reused here. A part of IFL 2019 format and CFP language that describes conditionally accepted papers has been adapted from call-for-papers of OOPSLA conferences.

1 0

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 05 Jun '19

05 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 04 Jun '19

04 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