- Haskell-Cafe - Haskell.org

International Conference on Applied Data Science and Intelligence - (ADSI 2021) Prague
by matteo＠confscience.com 21 Jun '21

21 Jun '21

Call for papers ************************************************* International Conference on Applied Data Science and Intelligence - (ADSI 2021) Prague- Czech Republic, October 14-15, 2021 https://confscience.com/adsi/ All papers accepted in ADSI 2021 will be published in Springer CCIS (Communications in Computer and Information Science). CCIS is abstracted/indexed in Scopus, SCImago, EI-Compendex, Mathematical Reviews, DBLP, Google Scholar, and Thomson Reuters Conference Proceedings Citation (Former ISI Proceedings) *************************************************************************** IMPORTANT DATES: - Paper Submission: June 30, 2021 (extended) - Acceptance Notification: July 15, 2021 - Final Manuscript Due: September 1, 2021 *************************************************************************** The ADSI 2021 conference will be held in Conjunction with: International Conference on Recent Theories and Applications in Transportation and Mobility (RTATM 2021) International Conference on Informatics Revolution for Smarter Healthcare (IRSH 2021) *************************************************************************** TOPICS: Authors are invited to submit their original papers to address the topics of the conference, including but not limited to: FUNDAMENTALS AND THEORIES - Theoretical Models - Spatial and temporal multi-models - Multi-dimensional data - Data acquisition and pre-processing - Data inference - Data Classification and Taxonomy - Data Metrics - New approaches for collaboration and competition - Self-organization, self-healing, fault-tolerance approaches - Spatial reasoning - Context awareness - Intelligent mobility - New approaches to supervised and unsupervised learning - New approaches for security, privacy, trust, and ethics in data science - Real-time data analytics - Multi-Agent Systems for data science - Distributed data analytics - Data authenticity - New theories and approaches for Deep learning - New approaches for Business Intelligence - Fuzzy logic - Decision trees - Support vector machines - Evolutionary computation - Statistical methods - Collaborative filtering - Data engineering - Content mining - Indexing schemes - Information retrieval - Metadata use and management INTELLIGENT DATA PROCESSING AND ANALYTICS - Multi-level data processing - Data analytics optimization - Smart data mining - Machine Learning - Deep Learning - Bio-Inspired Computing - Secure data analytics - Privacy in data analytics - Trust in Big Data - Business intelligence - Visualization Analytics - Intelligence as a Service (IaaS) - Data Science as a Service (DSaaS) - Natural Language Processing - Signal Processing - Simulation and Modeling - Data-Intensive Computing SYSTEMS AND INFRASTRUCTURES - Data storage infrastructure - Data warehouses - Data Query and Indexing Technologies - Software Defined Infrastructures - Software Defined Networks (SDN) - Distributed data systems - Smart grid computing - Intelligent data management - Big Data computing - Smart data networking - Internet of Things - Cyber Physical Systems - Blockchain - Fog and Edge intelligence - Parallel Computing systems - Open Source systems for data science - Embedded intelligence - Embedded data science - In-Memory computing - Intelligent drones - Internet of Drones - Real-time data acquisition systems APPLICATIONS - Intelligent Hazard management - Intelligent data science in healthcare - Intelligent data science in farming - Intelligent data science in Oil and Gas - Smart logistics - Intelligent data science in transportation - Intelligent data science in surveillance - Xtech (Fintech, Agritech, etc.) - Intelligent drones - Digital transformation - Bioinformatics - Marketing - Social Science - E-learning and E-services *************************************************************************** OUTSTANDING PAPERS: Based on the peer review scores as well as the presentations at the conference, the authors of outstanding papers will be invited to extend their works for a potential publication in journals special issues with high impact factors. *************************************************************************** PAPER SUBMISSION: Papers must be submitted electronically as PDF files via easychair (https://easychair.org/conferences/?conf=adsi2021) All papers will be peer reviewed. Length of Full papers: 12-15 pages long (written in the LNCS/CCIS one-column page format, 400 words per page) Length of Short papers: less than 12 pages For more information, please refer to the conference website: https://confscience.com/adsi/ *************************************************************************** CONTACT For more information, please send an email to info-adsi(a)confscience.com

1 0

International Conference on Recent Theories and Applications in Transportation and Mobility - (RTATM 2021) Prague
by matteo＠confscience.com 21 Jun '21

21 Jun '21

Call for papers ************************************************* International Conference on Recent Theories and Applications in Transportation and Mobility - (RTATM 2021) Prague - Czech Republic, October 14-15, 2021 https://confscience.com/rtatm/ All papers accepted in RTATM 2021 will be published in Springer CCIS (Communications in Computer and Information Science). CCIS is abstracted/indexed in Scopus, SCImago, EI-Compendex, Mathematical Reviews, DBLP, Google Scholar, and Thomson Reuters Conference Proceedings Citation (Former ISI Proceedings) *************************************************************************** IMPORTANT DATES: - Paper Submission: June 30, 2021 (extended) - Acceptance Notification: July 15, 2021 - Final Manuscript Due: September 1, 2021 *************************************************************************** The RTATM 2021 conference will be held in Conjunction with: International Conference on Applied Data Science and Intelligence (ADSI 2021) International Conference on Informatics Revolution for Smarter Healthcare (IRSH 2021) *************************************************************************** TOPICS: Authors are invited to submit their original papers to address the topics of the conference, including but not limited to: FUNDAMENTALS AND THEORIES - Modelling and Simulation Algorithms - Vehicular Wireless Medium Access Control - V2X communications - Routings and Protocols for Connected Vehicles - Mobility Models and Architectures - Distribution Strategies - Traffic Incident Management Systems - Bio-Inspired Approaches - Optimization and Collaboration - Automatic Control in Vehicular Networks - Energy-aware Connected Mobility - Programming Languages - Sustainable Transportation - Multimodal Transportation Networks and Systems - Systemsb Integration - Driver Behavior Models and Simulation - Human Factors and Travel Behaviour - Green Mobility - Regulations and Bylaws for Intelligent - Transportation and Mobility SMART TRANSPORTATION AND LOGISTICS - Mobility Management - Connected Vehicles - VANETs - Predictive Logistics - Spatio-Temporal Event Tracking - Decision Support Systems - Emergency Management - Logistics and E-Commerce - Supply Chain Design and Execution - Supply Chain Management - Advanced Planning Systems - Fleet Management - Multi-Agent Systems - Machine Learning for Smart Logistics - Intelligent Infrastructures - Real-time Analysis of Comprehensive Supply Chain Data - Smart Synchronization of Logistics Processes - New Approaches for Cost Transparency - Big Data for Smart Logistics - Logistics 4.0 - Mobile Networks - Next-Generation Smart Logistics - Performance Management Approaches - Tests and Deployment - Software Defined Networks - Smart Freight Management - Smart Shipment Management - Smart Warehousing - Smart Inventory management DATA AND SERVICES - Real-Time transportation Data Acquisition - Event Detection and Monitoring - Data Warehouses for connected mobility - Data mining and Data analytics - Data Worthiness in Connected Vehicles - Data Trustworthiness for effective transportation and mobility - Road Traffic Data Analytics - Structured and Unstructured Data for Connected Mobility - Volunteered Geographic Information (VGI) - Data Representation for Connected Mobility - Transportation Data Mining - Transportation and mobility Data Visualization - Cognitive and Context-aware Intelligence - Transportation Decision Support Systems - Mobility as a Service (MaaS) - Intelligent Transportation Services - Smart Mobility Services - Big Data and Vehicle Analytics - Massive Data Management - Collective and connected Intelligence - Next Generation Services - Driver Behaviour Analysis - Geo-Spatial Services - Service-Oriented Architecture (SOA) - Web and Mobile Services SAFETY, SECURITY, AND HAZARD MANAGEMENT - Security Issues in Vehicular Communications - Safety Applications of Connected Vehicles - Weather-related Safety solutions - V2V, V2I and I2V Road Safety Applications - Connected Mobility for Hazard Management - Risk Management - Road Traffic Crashes Analytics - Traffic Jam Prediction - Resource Allocation for Hazard Management - Trust and Privacy Issues in Logistics - Management of Exceptional Events - New approaches to Networking Security for Transportation Applications - Failure modes, human factors, software safety - Automated Failure Analysis - Performance and Human Error Analysis - Design and Reliability of Control Systems - Dispersion Modelling Software - Quantification of Risk *************************************************************************** OUTSTANDING PAPERS: Based on the peer review scores as well as the presentations at the conference, the authors of outstanding papers will be invited to extend their works for a potential publication in journals special issues with high impact factors. *************************************************************************** PAPER SUBMISSION: Papers must be submitted electronically as PDF files via easychair (https://easychair.org/conferences/?conf=rtatm2021) All papers will be peer reviewed. Length of Full papers: 12-15 pages long (written in the LNCS/CCIS one-column page format, 400 words per page) Length of Short papers: less than 12 pages For more information, please refer to the conference website: https://confscience.com/rtatm/ *************************************************************************** CONTACT For more information, please send an email to info-rtatm(a)confscience.com

1 0

Fwd: Haskell colour package repository
by Harendra Kumar 20 Jun '21

20 Jun '21

Does anyone know who maintains the "colour" package or where the repository is hosted? I tried to contact Russell O'Connor but did not get a response. -harendra ---------- Forwarded message --------- From: Harendra Kumar <harendra.kumar(a)gmail.com> Date: Mon, 17 May 2021 at 05:38 Subject: Haskell colour package repository To: <roconnor(a)theorem.ca> Hi, I was building something that depends on https://hackage.haskell.org/package/colour package using GHC-9.3, and it's failing to build. I was wondering if it is possible to add a URL to the package repository in the cabal file of the package so that I can clone/fix/send a PR? Or maybe a URL for reporting issues/bugs? Thanks, Harendra

3 2

Tips for debugging seg. faults?
by David Banas 20 Jun '21

20 Jun '21

Does anyone have any helpful tips for debugging seg. faults in a Haskell program that calls out to a C library, via the FFI?

3 2

Pearl! I just proved theorem about impossibility of monad transformer for parsing with (1) unbiased choice and (2) ambiguity checking before running embedded monadic action (also, I THREAT I will create another parsing lib)
by Askar Safin 17 Jun '21

17 Jun '21

Hi. I hope people here, at haskell-cafe, like various theorem, pearls on parsing, monads, monad transformers and anything like that, right? So, I just proved something interesting for you! Theorem about impossibility of monad transformer for parsing with (1) unbiased choice and (2) ambiguity checking before running embedded monadic action. I already presented it on #haskell in Libera chat, now let me send it here. This is not quite theorem, i. e. I would not say that it keeps with mathematical standards of rigor. --------------------------- I want monad transformer (let's name it ParserT) with following properties (hint: I proved such transformer doesn't exist): - it has unbiased choice (i. e. (<|>) :: ParserT m a -> ParserT m a -> ParserT m a) (this means running parser can give you multiple results) - you can run parser without executing embedded monadic actions. i. e. "run" function should look like this: run :: ParserT m a -> String -> [m a] {- Not m [a] -} I want such function, because I want to do this: run parser, then count number of possible parses, then (if count is equal to one) actually execute embedded monadic action. I. e. I want something like this: parser :: ParserT (Either String) () parser = ..... main :: IO () main = do { input <- ....; case run parser input of { [res] -> do { -- Cool! we got exactly one result! Let's run it case res of { Left e -> putStr $ "Parsing succeed, but we have semantic error: " ++ e; Right () -> putStr "Everything OK"; }; }; _ -> putStr "Cannot parse. 0 parse trees or >1 parse trees"; }; } Now let me state theorem. Theorem. Such transformer doesn't exist. Moreover, even if I replace arbitrary monad "m" with particular monad "Maybe" (or "Either String") the task is still unsolvable. But the task seems achievable using arrows ------------------------------------- Proof. Let's imagine such "ParsecT Maybe" exists. Let's imagine we have such function: char :: Char -> ParserT Maybe Char {- matches supplied char -} Also, keep in mind we have "lift": lift :: Maybe a -> ParserT Maybe a Now let's write this: parseA = char 'a' parseAorA = char 'a' <|> char 'a' contr = do { a <- lift $ Nothing; if a > 5 then parseA else parseAorA; return (); } Now, please, say, what is (run contr "a")? How many elements will (run contr "a") have? If "a > 5", then (run contr "a") will contain one element. If "a <= 5", then (run contr "a") will contain two elements. But we cannot know whether "a > 5", because we cannot extract "a" from "Nothing". So, we got contradiction. QED ----------------- In other words, function "run" with type "ParserT m a -> String -> [m a]" means that we should somehow be able to know count of parses before executing monadic action. But this is impossible, because our parser can contain code like this: (do { a <- lift $ ...; if a then ... else ...; }). I. e. count of parses can depend on value, embedded in inner monad, so we cannot know count of parses before we run embedded inner monadic action. This theorem is not simply out of curiosity. I actually need parsing lib with this properties. 1. I need unbiased choice, because it is compatible with CFGs, and I love CFGs (as opposed to PEG) 2. I need embedding monads, because this allows me to check semantic errors (such as "type mismatch") in time of parsing. I. e. I can simply embed (Either String) monad into parsing monad, and use this (Either String) monad for checking semantic errors 3. I need to know number of parse trees before executing monadic actions (i. e. i need ([m a]) as opposed to (m [a])), because I want to check that number of parses is equal to 1 (if not, then print error), and then extract inner monad (which will contain information about semantic errors). In other words, I want check the input for ambiguity (and print error if it is ambiguous), and if it is not ambiguous, then print possible semantic errors (if any). The possibility of ambiguity detection is whole point of using CFGs as opposed to PEGs (which are always unambiguous, but this unambiguity is simply trick). 4. Every terminal and nonterminal should carry location info (i. e. begin and end of this string). And this location info should be passed implicitly. And it should not be embedded deeply in ASTs I will use. (This means that "happy" is not for me. As well as I understand it cannot implicitly pass location info. In https://github.com/ghc/ghc/blob/master/compiler/GHC/Parser.y I see explicit location management all the time.) 5. Left recursion is not needed So, does such lib exist? Well, I already know such lib should be arrow based (as opposed to monad). So, is there such arrow parsing lib? Embedding arbitrary inner monad is not needed, just embedding (Either String) will go. If there is no such lib, I plan to create my own. This is threat! :) Also, I wrote letter long ago asking for parsing lib with different properties. I included desire for reversibility, among others. Well, this was other task. For my current task I don't need reversibility. == Askar Safin http://safinaskar.com https://sr.ht/~safinaskar https://github.com/safinaskar

3 5

ICFP 2021 Student Research Competition: Call for Submissions
by Sam Tobin-Hochstadt 17 Jun '21

17 Jun '21

ICFP 2021 Student Research Competition Call for Submissions ICFP invites students to participate in the Student Research Competition, which will be held virtually alongside the main conference, in order to present their research and receive feedback from prominent members of the programming language research community. As usual, the SRC consists of three rounds: * Extended abstract * Poster session at ICFP 2021 * ICFP presentation To make the virtual competition fruitful, we will make sure that every student will have an "invited audience" during the poster session. We are also planning to organize a social event for the students. Please visit the SRC website for updates. ### Important Dates Submissions due: 2 July 2021 (Friday) https://icfp21src.hotcrp.com Notification: 16 July 2021 (Friday) Conference: 22 August (Sunday) - 27 August (Friday) ### Submission Details 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://icfp21.sigplan.org/track/icfp-2021-Student-Research-Competition Program Committee: Chair: Anders Miltner (UT Austin) Andreea Costea (NUS Singapore) Andrew Hirsch (MPI-SWS) Liam O'Connor (University of Edinburgh) Lionel Parreaux (HKUST) Daming Zou (ETH Zurich)

1 0

An emotional retrospective on my Haskell journey so far
by Chris Smith 17 Jun '21

17 Jun '21

Hi everyone, I started out writing a blog post about why I chose to become a contributor to the Haskell Foundation. It ended up being a bit of a bigger picture recap of my whole Haskell journey. I would like to share it with you, since many of the people here have been really influential to me over the past 15 years. Thank you all so much. Link: https://cdsmithus.medium.com/why-i-support-the-haskell-foundation-1ac3cda1f… Yes, it's Medium, but it isn't part of their soft paywall, so please don't be afraid to click on it. Cheers, Chris Smith

1 0

Fwd: Haskell grammar ambiguity
by Jon Purdy 16 Jun '21

16 Jun '21

Email fail, pardon the noise; original message below. ---------- Forwarded message --------- From: Jon Purdy <evincarofautumn(a)gmail.com> Date: Wed, Jun 16, 2021 at 1:35 PM Subject: Re: [Haskell-cafe] Haskell grammar ambiguity To: Sven Panne <svenpanne(a)gmail.com> On Wed, Jun 16, 2021 at 12:49 AM Sven Panne <svenpanne(a)gmail.com> wrote: > I consider ambiguous grammars a serious usability bug. > I agree. I always make a point of telling ‘%expect 0’ to Happy. (“More often than not the grammar you write will have conflicts”? Excuse you!) > The BlockArguments proposal introduced lots of additional ambiguities, and > that's the reason why I'm still opposed to it. > I consider BlockArguments a fix for a bug in the Haskell grammar, namely, a redundant production, requiring an unnecessary operator, which causes confusion for some people coming from other languages. In being fixed, however, it exposed other serious grammar issues. So I’d be strongly in favour of fixing those unclear/ambiguous parses by further (incremental) simplification of the grammar. It would be very nice if the extent of lambda/if/&c. were unambiguous, so I think this idea is a step in the right direction. I would also be very pleased if the layout rule were reformulated as a simpler desugaring step, from a token stream annotated with source locations to such a stream with explicit braces and semicolons inserted, rather than being defined in terms of parse errors and papering over edge cases. My ideal would be a simple formal grammar (LALR, PEG, or even operator-precedence) which is machine-validated as unambiguous, with an implementation written by hand to produce nice contextual error messages, which is typed to prove that it accepts the same language as the formal grammar.

1 0

Haskell grammar ambiguity
by Li-yao Xia 16 Jun '21

16 Jun '21

Hello Café, With the BlockArguments proposal[1], the formal grammar of Haskell has become much nicer, with all of the "boring" expression constructs (i.e., other than function or operator application) under one non-terminal: https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0090-b… Its one flaw, inherited from Haskell2010, is ambiguity. I wonder whether that ambiguity is necessary. Currently, a meta-rule fixes that flaw: > The grammar is ambiguous regarding the extent of lambda abstractions, let expressions, and conditionals. The ambiguity is resolved by the meta-rule that each of these constructs extends as far to the right as possible. That is quite informal, so interpreting it takes a bit of thinking. 1. Does the rule make sense? That seems quite likely, but at the same time it seems to depend on some good behavior of the grammar. Like, aren't there grammars where such an "extend far to the right" meta-rule would itself be ambiguous? What's the key criterion for that meta-rule to make sense? 2. How to implement this rule? It might be obvious, with shift-reduce parsing ("shift always"). It also seems feasible with Earley parsing (the only other technique I am familiar with). But, either way, you have to dig into the internals of the chosen parsing method to resolve ambiguities. Instead, what if the grammar were unambiguous to start with? I share an attempt at the bottom of this email. Which brings me to my main two questions: 3. Is this grammar unambiguous? 4. Does it match the meta-rule? I also can't help but think about how it might look like in a hypothetical language report. 5. What are the pros and cons of using a ambiguous or unambiguous grammar for a programming language standard? A plausible starting point is thus: - An ambiguous grammar may be more readable (since there are strictly more choices available), especially if you care more about the AST than the concrete syntax. - An unambiguous grammar is easier to implement: just throw it into an Earley parser. This unambiguous grammar can somewhat easily be "flattened" into the ambiguous one from the report. That challenges the assumption that ambiguous grammars are generally more readable. In fact, the current ambiguous grammar already exposes other concrete syntax concerns (via the distinction between exp, infixexp, fexp, and aexp). In contrast, turning an ambiguous grammar into an unambiguous one takes a bit of effort (when it's possible at all). So if there are ambiguities worth keeping, is there a clear threshold? One other possible issue is that non-ambiguity is a fragile property, so extending the grammar requires extra care. Furthermore, even if the updated grammar is unambiguous, it might not be obvious that it still encodes the intent behind the meta-rule. That meta-rule may still be worth clarifying as a requirement for language extensions at least. Haskell syntax can be pretty, but the process behind it is a wee bit complicated. Regards, Li-yao --- # Unambiguous grammar for expressions (some rules omitted for brevity) # Compared to Haskell2010+BlockArguments, we move the rules for if, lambdas and lets into their own non-terminal rexp, and add four extra rules in exp, ensuring that rexp occurs only to the right end of function/operator applications. # Possibly simplifiable more # * and + represent repetition. # Expressions. exp -> iexp "::" type | iexp # EXTRA RULES with rexp | rexp | iexp qop rexp | iexp qop frexp | frexp # EXTRA SYMBOL rexp # Expressions with right-recursive syntax. rexp -> "if" exp "then" exp "else" exp | "\\" var "->" exp | "let" decls "in" exp # EXTRA (AUXILIARY) SYMBOL frexp # Function application with a trailing block argument. frexp -> aexp aexp* rexp # Infix expression (was infixexp). OLD iexp -> fexp (qop fexp)* # Optional function applications. OLD fexp -> aexp | aexp aexp+ # Atomic expressions. OLD with removed if/lambda/let aexp -> qvar | "[" "]" | "(" ")" | qcon | "(" exp ")" | "do" "{" stmts "}" | "case" exp "of" "{" alts "}"

5 8

IFL2021 second call for papers
by Pieter Koopman 15 Jun '21

15 Jun '21

================================================================================ IFL 2021 33rd Symposium on Implementation and Application of Functional Languages venue: online 1 - 3 September 2021 https://ifl21.cs.ru.nl <https://ifl21-publicity-dot-yamm-track.appspot.com/Redirect?ukey=1NdKhGOLpm…> ================================================================================ News - Paper submission is now open: https://easychair.org/conferences/?conf=ifl21 <https://ifl21-publicity-dot-yamm-track.appspot.com/Redirect?ukey=1NdKhGOLpm…> . - Invited speakers are added: Stephanie Weirich and John Hughes - Sponsor added: Facebook Research <https://ifl21-publicity-dot-yamm-track.appspot.com/Redirect?ukey=1NdKhGOLpm…> 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 2021 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. Industrial track and topics of interest This year's edition of IFL explicitly solicits original work concerning *applications* of functional programming in industry and academia. These contributions will be reviewed by experts with an industrial background. 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 specialisation * run-time code generation * partial evaluation * (abstract) interpretation * meta-programming * 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 * testing and proofing * virtual/abstract machine architectures * validation, verification of functional programs * tools and programming techniques * applications of functional programming in the industry, including ** functional programming techniques for large applications ** successes of the application functional programming ** challenges for functional programming encountered ** any topic related to the application of functional programming that is interesting for the IFL community Post-symposium peer-review Following IFL tradition, IFL 2021 will use a post-symposium review process to produce the formal proceedings. Before the symposium authors submit draft papers. These draft papers will be screened by the program chairs to make sure that they are within the scope of IFL. The draft papers will be made available to all participants at the symposium. Each draft paper is presented by one of the authors at the symposium. After the symposium every presenter is invited to submit a full paper, incorporating feedback from discussions at the symposium. Work submitted to IFL may not be simultaneously submitted to other venues; submissions must adhere to ACM SIGPLAN's republication policy. 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 for the formal proceedings. We plan to publish these proceedings in the International Conference Proceedings Series of the ACM Digital Library, as in previous years. Moreover, the proceedings will also be made publicly available as open access. Important dates Submission deadline of draft papers: 17 August 2021 Notification of acceptance for presentation: 19 August 2021 Registration deadline: 30 August 2021 IFL Symposium: 1-3 September 2021 Submission of papers for proceedings: 6 December 2021 Notification of acceptance: 3 February 2022 Camera-ready version: 15 March 2022 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 <https://ifl21-publicity-dot-yamm-track.appspot.com/Redirect?ukey=1NdKhGOLpm…> The submission Web page for IFL21 is https://easychair.org/conferences/?conf=ifl21 <https://ifl21-publicity-dot-yamm-track.appspot.com/Redirect?ukey=1NdKhGOLpm…> . Peter Landin Prize The Peter Landin Prize is awarded to the best paper presented at the symposium every year. The honoured 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. Organisation IFL 2021 Chairs: Pieter Koopman and Peter Achten, Radboud University, The Netherlands IFL Publicity chair: Pieter Koopman, Radboud University, The Netherlands PC: Peter Achten (co-chair) - Radboud University, Netherlands Thomas van Binsbergen - University of Amsterdam, Netherlands Edwin Brady - University of St. Andrews, Scotland Laura Castro - University of A Coruña, Spain Youyou Cong - Tokyo Institute of Technology, Japan Olaf Chitil - University of Kent, England Andy Gill - University of Kansas, USA Clemens Grelck - University of Amsterdam, Netherlands John Hughes - Chalmers University, Sweden Pieter Koopman (co-chair) - Radboud University, Netherlands Cynthia Kop - Radboud University, Netherlands Jay McCarthey - University of Massachussetts Lowell, USA Neil Mitchell - Facebook, England Jan De Muijnck-Hughes - Glasgow University, Scotland Keiko Nakata - SAP Innovation Center Potsdam, Germany Jurriën Stutterheim - Standard Chartered, Singapore Simon Thompson - University of Kent, England Melinda Tóth - Eötvos Loránd University, Hungary Phil Trinder - Glasgow University, Scotland Meng Wang - University of Bristol, England Viktória Zsók - Eötvos Loránd University, Hungary Virtual symposium Because of the Covid-19 pandemic, this year IFL 2021 will be an online event, consisting of paper presentations, discussions and virtual social gatherings. Registered participants can take part from anywhere in the world. [image: beacon]

1 0

ccall vs capi
by Julian Ospald 14 Jun '21

14 Jun '21

Hi, recently during a ghcup release, we stumbled over yet another `ccall` bug on Darwin: https://github.com/biegunka/terminal-size/pull/16 This took Ben some time to debug (thanks again) and it isn't always clear with such bugs whether something is wrong with GHC/RTS/GC or a library, so this can be a time-sink. It's also not the first time it happened: * https://github.com/haskell/unix/pull/110#issuecomment-613384845 * https://github.com/hasufell/hpath/commit/74d686547e67da3eeae327c84c63f83833… I can't say that I fully understood what the exact difference here is and why it seems to matter much more on Darwin than on other systems. So I think it would be helpful if we could come up with: 1. a clear description of the differences of ccall vs capi 2. an explanation why ccall can lead to terrible bugs on darwin 3. a guideline of when using one over the other is appropriate Not everyone deals with ffi on a regular basis, so I hope the experts here can shed some light! Cheers, Julian

3 2

Need advise with using Quickcheck
by Han Joosten 12 Jun '21

12 Jun '21

Dear café, I want to implement a roundtrip test for a parser/prettyprinter combination. Let me try to explain what I am struggling with. I start with some type definitions of functions I have *data Guarded a =* * Errors (NE.NonEmpty CtxError) | Checked a [Warning]* *parseFoo :: Text -> Guarded Foo* *prettyFoo :: Foo -> Text* The idea is that for all foo :: Foo, the following holds: *parseFoo . prettyFoo $ foo* should be equal to *Checked foo []* Now, if there is a counterexample, I would like to see prettyFoo foo as output, folowed by the show of the Errors part. I have been struggling to get this working, but without luck so far. I am not very familiar with Quickcheck, so that could be the problem too. Any help would be appreciated! Thanks Han

5 6

ZuriHac 2021 is happening in a week!
by Jasper Van der Jeugt 12 Jun '21

12 Jun '21

Hey folks, This is a final reminder that ZuriHac is taking place next weekend, Friday 18 June - Sunday 20 June 2021. Here are a couple of things to know: - You can register and join the Discord server through the following link: https://zureg.zfoh.ch/register/ - There will be the traditional pre-event socializing on Thursday, starting at 19:00 CEST. - We finalised the schedule, and there have been a couple of really cool additions. You can seee the calendar at https://zfoh.ch/zurihac2021/#schedule If you submitted a project, please ping us anytime on Discord in the #helpdesk channel, and we'll set up text and video channels for you. Happy hacking! The Zurich Friends of Haskell - https://zfoh.ch/

1 0

Optimizing Eq instances with reallyUnsafePtrEquality#
by Simon Jakobi 12 Jun '21

12 Jun '21

Hi everyone! In https://github.com/haskell-unordered-containers/unordered-containers/issues… we're wondering whether certain Eq instances, for example record types or strings, could be optimized by including a pointer equality check that detects when an object is compared with itself. Does anyone here have experience with such an optimization? Has this been considered before, for example in GHC's deriving machinery? One complication seems to be the correct handling of fields with irreflexive instances, for example Float and Double. In such a case, pointer equality doesn't imply "==-equality". I'm looking forward to hearing your thoughts on this! :) Cheers, Simon

6 7

Could optimize attoparsec if GHC would collapse `runParser (Parser parser)` to `parser`
by Tyson Whitehead 11 Jun '21

11 Jun '21

Hi. I'm hoping someone with some knowledge about GHC optimizations can weigh in and help out here. The attoparsec library has a `<|>` combinator for choice. Since attoparsec does arbitrary backtracking, you would expect that `recursiveLhs <|> rhs` would stack up a bunch of `rhs` alternatives to the depth of the recursion. Looking at the definitions though, would make you believe that so long as the `rhs` is constant as it usually is (e.g., `pure []` if you are collecting a list), inlining should result in it not stacking up a bunch of the `rhs` alternatives (intuitively the most recent one will always succeed so there is no reason to hold on to more than one). Unfortunately, it doesn't seem to work. The full details can be found in this bug report https://github.com/haskell/attoparsec/issues/186 but I believe it comes down to the fact that GHC is not collapsing a packing and immediate unpacking of the parser datatype ``` runParser (Parser parser) -> parser ``` which is resulting in the fact that the `rhs` always succeeds (i.e., doesn't use the failure continuation) not being exposed. I am hoping someone knowledgeable in these matters could weigh in. Thanks! -Tyson PS: The parser datatype is a wrapper on CPS style lambda ``` newtype Parser i a = Parser { runParser :: forall r. State i -> Pos -> More -> Failure i (State i) r -> Success i (State i) a r -> IResult i r } ``` where Failure and Success are type synonyms for the continuations ``` type Failure i t r = t -> Pos -> More -> [String] -> String -> IResult i r type Success i t a r = t -> Pos -> More -> a -> IResult i r ```

2 1

A matrix.org client library proposal
by Tristan Cacqueray 11 Jun '21

11 Jun '21

Dear Café, I'd like to publish a rather simple `matrix-client` package on hackage based on this implementation: https://github.com/softwarefactory-project/matrix-client-haskell Please let me know if you are interested or if you have a similar implementation we could collaborate on. Kind Regards, -Tristan

2 2

Hiring two Haskell devs at Standard Chartered bank
by José Pedro Magalhães 09 Jun '21

09 Jun '21

Hello, I'm hiring two Haskell devs for my team at Standard Chartered bank, in London, Singapore, or Hong Kong. My team sits in front office and has about 20 Haskell devs (well, technically Mu, our in-house variant). We work in close collaboration with trading, sales, and structuring to build diverse software, from desktop GUI applications to server-side financial analytics reports and services. The current roles are at a relatively junior level -- 2 to 5 years industrial experience expected, or a relevant PhD. Feel free to reach out to me directly if you're interested and have any questions, but applications should go via the links below. Singapore: https://scb.taleo.net/careersection/ex/jobdetail.ftl?job=2100014272 Hong Kong: https://scb.taleo.net/careersection/ex/jobdetail.ftl?job=2100014571 London: https://scb.taleo.net/careersection/ex/jobdetail.ftl?job=2100012204 Standard Chartered supports (practically fully) remote working, but only from the country of payroll. We will cover visa and relocation costs for successful applicants. Cheers, Pedro

1 0

Using stack outside the project box
by Galaxy Being 08 Jun '21

08 Jun '21

As a beginner, I was told to use stack. And I seemed to get something Haskell installed initially on my Ubuntu 21.04. But stack seems to be geared toward projects and compiling executables with ghc, and not a global ghci REPL-based way. I'm using Emacs org mode "Babel" which allows for a very nice "literate" programming in tandem with a running REPL in many REPL-friendly languages, e.g., here are code blocks in an org-mode file #+begin_src haskell :results silent :exports code data Peano = Zero | Succ Peano deriving (Show) #+end_src #+begin_src haskell :results silent :exports code myThree = Succ (Succ (Succ Zero)) #+end_src #+begin_src haskell :results verbatim :exports both myThree #+end_src #+RESULTS: : Succ (Succ (Succ Zero)) I simply hit Evaluate (Ctr-C Ctr-C) and the evaluation is handled by a running ghci REPL started up in another Emacs buffer. Supposedly, a haskell-mode and a specific Babel ob-haskell package are working together to enable this. And so it works okay, once quirks (must enclose multi-lined code in :{..:} and every REPL session seems to need a :set +m as well). I'm really quite happy with this way of doing things and have resisted the whole monolithic 1) create project in a directory, 2) put code into .hs file, 3) compile with ghc. But what I'm constantly having problems with is getting additional packages beyond the Prelude basics. My org files are in various directories, but I want (like most languages offer) to simply interact with that language on a global level wherever I am, whatever files and directories and Haskell code I'm working on. Sometimes doing an import works; often enough not. Then I have to do something with stack -- hopefully globally . . . and there the confusion and inconsistencies begin. Lately I can't seem to get Safe installed. And all docs about editing some yaml stuff get me lost in the weeds quickly. What yaml where for my "global" situation? If you simply say to me, Don't try to work outside of the project--hs files--compile to executable framework I'll say okay, then have to decide whether I want to stay within the org-mode world or leave Haskell for an org-mode friendlier language. And no, lhs and jupyter are primitive compared to org-mode literate programming. Both are a step backwards. Any help on working outside the project box with stack, e.g., how to install and use packages (and even how to update/upgrade ghc and ghci would be a start!). - ⨽ Lawrence Bottorff Grand Marais, MN, USA borgauf(a)gmail.com

6 14

[ANN] hindley-milner-type-check-0.1.1.0 - type-checker for extended lambda-calculus
by Anton Kholomiov 08 Jun '21

08 Jun '21

I am happy to announce the first release of hindley-milner-type-check. It is generic type checker for lambda-calculus augmented with let-expressions, case-expressions pattern-matching and polymorphism. Library can report source code locations and returns the list of all errors if any. The library is generic in terms of source code locations, names for variables, literals of the language. You can find tutorials and examples in the github repo. Links: Hackage: https://hackage.haskell.org/package/hindley-milner-type-check Github: https://github.com/anton-k/hindley-milner-type-check Happy type-checking! Cheers, Anton

1 0

Re: [Haskell-cafe] [Haskell] [ANNOUNCE] GHC 8.10.5 released
by Zubin Duggal 06 Jun '21

06 Jun '21

The correct link to the release notes is: https://downloads.haskell.org/ghc/8.10.5/docs/html/users_guide/8.10.5-notes… (Note the missing tilde) Apolgies, Zubin

1 0

[Haskell] [ANNOUNCE] GHC 8.10.5 released
by Zubin Duggal 06 Jun '21

06 Jun '21

The GHC team is very pleased to announce the availability of GHC 8.10.5. Source and binary distributions are available at the [usual place](https://downloads.haskell.org/ghc/8.10.5/). This release adds native ARM/Darwin support, as well as bringing performance improvements and fixing numerous bugs of varying severity present in the 8.10 series: - First-class support for Apple M1 hardware using GHC's LLVM ARM backend - Fix a bug resulting in segmentation faults where code may be unloaded prematurely when using the parallel garbage collector (#19417) along with other bugs in the GC and linker (#19147, #19287) - Improve code layout fixing certain performance regressions (#18053) and other code generation bug fixes (#19645) - Bug fixes for signal handling when using the pthread itimer implementation. - Improvements to the specializer and simplifier reducing code size and and memory usage (#17151, #18923,#18140, #10421, #18282, #13253). - Fix a bug where typechecker plugins could be run with an inconsistent typechecker environment (#19191). - Fix a simplifier bug which lead to an exponential blow up and excessive memory usage in certain cases A complete list of bug fixes and improvements can be found in the release notes: [release notes](https://downloads.haskell.org/~ghc/8.10.5/docs/html/users_guide/8.10… As always, feel free to report any issues you encounter via [gitlab.haskell.org](https://gitlab.haskell.org/ghc/ghc/-/issues/new).

1 0

printf using values more than once
by Olaf Klinke 04 Jun '21

04 Jun '21

Dear Café, since the topic recently was rendering text, I'd like to ask a related design question. I want a version of printf that - is more type-safe because unused or surplus arguments cause compile-time errors, - the formatting instructions can use arguments out of order and more than once, - is polymorphic in the text type being built: Suppose I want to build a Pandoc Block but the holes are of type Inline. The format string must therefore be able to promote the Block type's constructors to constructors with holes. The closest match I know of is HoleyMonoid [1] but it only provides printf-like holes, whereas I need named positional arguments like arg1, arg2 etc. that can be repeated. Document templating libraries provide these, but all templating libraries I looked at are type-unsafe. In order to fulfill the second requirement, one could use the free monad over a Reader functor, e.g. Free ((->) (forall a. Show a => a)) String with some custom instances. Here one can use the nesting levels of the free monad to encode the argument position. But it is just as type-unsafe as printf. Funneling return type constructors through this works sort of, but it's awkward. One can achieve type saftey with type classes like printf does: class Eventually r a where eventually :: r -> a instance Eventually r r where eventually = id instance (Eventually r a) => Eventually r (b -> a) where eventually r = const (eventually r) This class can be used to inject constant Text into any nesting of (Text -> ... -> Text -> Text) and argument position is indeed function argument position. But using this system often leads to type ambiguity errors. Also, it is so type-safe that it is impossible to write a function taking a natural number and returning the hole of the corresponding position: Such a function would be dependently-typed. My current best implementation uses a combination of Eventually and HoleyMonoid, but I'm not entirely satisfied. Olaf [1] https://hackage.haskell.org/package/HoleyMonoid

3 3

[ANN] ttc-1.0.0.0 - Textual Type Classes
by Travis Cardwell 04 Jun '21

04 Jun '21

I am happy to announce the 1.0 release of TTC (Textual Type Classes). The library provides the following functionality: * The Textual type class is used to convert between common textual data types. It can be used to write functions that accept or return values of any of these textual data types. * The Render type class is used to render a value as text. Avoid bugs by only using Show for debugging/development purposes. * The Parse type class is used to parse a value from text. Unlike Read, it has support for error messages. * Validate constants at compile-time using Parse instances. Links: * GitHub: https://github.com/ExtremaIS/ttc-haskell * Hackage: https://hackage.haskell.org/package/ttc * Guided Tour: https://www.extrema.is/articles/ttc-textual-type-classes Best regards, Travis

4 10

Call for Tutorial, Panel, and Discussion Proposals: ICFP 2021
by Sam Tobin-Hochstadt 02 Jun '21

02 Jun '21

CALL FOR TUTORIAL, PANEL, AND DISCUSSION PROPOSALS ICFP 2020 25th ACM SIGPLAN International Conference on Functional Programming August 22 - 27, 2021 Virtual https://icfp21.sigplan.org/ The 25th ACM SIGPLAN International Conference on Functional Programming will be held virtually on August 22-27, 2021. 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". Just like last year, following the success of the #ShutDownPL event @ ICFP, we are also inviting proposals for panels and discussions on topics of broader interest to the PL community. Tutorials, panels, and discussions may occur before or after ICFP, co-located with the associated workshops, on August 22 or August 26-27. ---------------------------------------------------------------------- Submission details Deadline for submission: June 28th, 2020 Notification of acceptance: July 5th, 2020 Prospective organizers of tutorials are invited to submit a completed tutorial proposal form in plain text format to the ICFP 2021 workshop co-chairs (Leonidas Lampropoulos and Zoe Paraskevopoulou), via email to icfp-workshops-2021(a)googlegroups.com by June 28th, 2021. Please note that this is a firm deadline. Organizers will be notified if their event proposal is accepted by July 5th, 2021. The proposal form is available at: http://www.icfpconference.org/icfp2021-files/icfp21-panel-form.txt http://www.icfpconference.org/icfp2021-files/icfp21-tutorials-form.txt ---------------------------------------------------------------------- Selection committee The proposals will be evaluated by a committee comprising the following members of the ICFP 2021 organizing committee. Tutorials Co-Chair: Zoe Paraskevopoulou (Northeastern) Tutorials Co-Chair: Leonidas Lampropoulos (University of Maryland) General Chair: Sukyoung Ryu (KAIST) Program Chair: Ron Garcia (University of British Columbia) ---------------------------------------------------------------------- Further information Any queries should be addressed to the tutorial co-chairs ( Leonidas Lampropoulos and Zoe Paraskevopoulou), via email to icfp-workshops-2021(a)googlegroups.com

1 0

Generic Traversal of ASTs
by Richard Yu 02 Jun '21

02 Jun '21

I have a question about generic traversal/transformation of nested data structures. From what I understand the main options available are SYB, Uniplate, GHC.Generics and Data.Lens (although I am under the impression this requires record types). The data structure I am attempting to traverse is similar to this simplified version: data SExpr = Expr | Const data Const = B bool | I int data Expr = Lambda String SExpr | If Expr ... I have attempted to use Uniplate and GHC.Generics to traverse the built AST and modify for example, the string of a Lambda type, but have not been able to figure out how to get any of the libraries to typecheck. The examples or docs I found were not quite enough. Does anyone know of examples that might help or explain how I should be using the generic libraries? In addition if I moved to writing the AST with GADTs, do some generic traversal strategies/libraries stop working? Many thanks, Richard

4 4

Wrapping external process communication in a nice API?
by Mario Lang 31 May '21

31 May '21

Hi. For my chessIO package, I wrote a module to communicate with UCI (Universal Chess Interface) speaking chess engines. This sort of thing is pretty new to me. I settled to use attoparsec for parsing and TChan to feed incoming data to the library users. This is the first thing that I found which looked like it could work... I would be thrilled if someone with more experience in this area would give my approach a review. Let me know if something is glaringly unidiomatic, I am sure you will find things. https://github.com/mlang/chessIO/blob/master/src/Game/Chess/UCI.hs This is for me to learn, and to avoid putting weird stuff on hackage... I actually prefer private mail, but a GitHub issue or even a PR are also highly welcome. Thanks. -- CYa, ⡍⠁⠗⠊⠕

4 9

bottom/unconditionally false in Haskell
by Galaxy Being 31 May '21

31 May '21

I just ran into this formula head = foldr (<<) ⊥ where x << y = x in Bird and Gibbons' *Algorithm Design with Haskell* and I understand it's a sort of pseudo-code. Intuitively, I understand that foldr will take "bottom" as its "starter seed", but I don't know how to convert the << into Haskell code. This works myHead = foldr choose1st undefined where choose1st x y = x but I can't get myHead2 = foldr (<<) undefined where << x y = x to work. How do you create a non-alphanumeric operator like <<? -- ⨽ Lawrence Bottorff Grand Marais, MN, USA borgauf(a)gmail.com

3 2

Is there some tool for inferring wide dependency ranges?
by Askar Safin 31 May '21

31 May '21

Hi. Is there some tool for inferring dependency ranges for my cabal packages? I know about "cabal gen-bounds", but this command gives too short ranges. I want to get as wide range as possible. I. e. I want tool, which tries to build and test my package on various versions of dependencies, and reports resulting range. Successful testing should mean that the version of dependency is compatible. That tool should work also on "base" package, this means that it should test various ghc versions, too. If there is no such tool, then at least I want some tool, which will check already specified dependency range. Such tool should do this: - Extract dependencies from cabal file - Install smallest versions of specified dependencies (this will include "base" and thus ghc) - Test on this versions - Install largest versions - Test on this versions I will put invocation of such tool to continuous integration. I hope there are a lot of package maintainers here. How do you manage dependencies? == Askar Safin http://safinaskar.com https://sr.ht/~safinaskar https://github.com/safinaskar

3 6

Request for Haskell wiki editing account
by Michael Turner 30 May '21

30 May '21

I've been a contributor to Wikipedia for a long time https://en.wikipedia.org/wiki/Special:Contributions/Yakushima and I'm a Haskell newbie. As I run across problems in getting started, I'd like to improve the Haskell wiki so that others can avoid similar problems. Requested username for Haskell Wiki: Yakushima Regards, Michael Turner Executive Director Project Persephone 1-25-33 Takadanobaba Shinjuku-ku Tokyo 169-0075 Mobile: +81 (90) 5203-8682 turner(a)projectpersephone.org Understand - http://www.projectpersephone.org/ Join - http://www.facebook.com/groups/ProjectPersephone/ Donate - http://www.patreon.com/ProjectPersephone Volunteer - https://github.com/ProjectPersephone "Love does not consist in gazing at each other, but in looking outward together in the same direction." -- Antoine de Saint-Exupéry

2 3

ML Family Workshop 2021: deadline extension
by Jonathan Protzenko 28 May '21

28 May '21

The deadline for the ML family workshop has been extended by a week. If you were on the fence, please submit! --- We are happy to announce that the ML Family Workshop is back for its 2021 edition, which we will be held online on Thursday August 26th, in conjunction with ICFP 2021. The ML family workshop warmly welcomes submission touching on the programming languages traditionally seen as part of the "ML family" (Standard ML, OCaml, F#, CakeML, SML#, Manticore, MetaOCaml, etc.). The scope of the workshop includes all aspects of the design, semantics, theory, application, implementation, and teaching of the members of the ML family. We also encourage presentations from related languages (such as Haskell, Scala, Rust, Nemerle, Links, Koka, F*, Eff, ATS, etc), to exchange experience of further developing ML ideas. ## Submission details Submissions must be at most three pages long; see the full call for papers <https://icfp21.sigplan.org/home/mlfamilyworkshop-2021#Call-for-Presentations> for details. Submission site: https://ml21.hotcrp.com/ ## Important dates Thu, Jun 3th 2021 (AoE): submission deadline Thu, Jun 24th 2021 (AoE): author notification Thu, Aug 26th: workshop (time slots TBD) ## Program committee Danel Ahman (University of Ljubljana) Robert Atkey (University of Strathclyde) Frédéric Bour (Tarides) Ezgi Çiçek (Facebook London) Youyou Cong (Tokyo Institute of Technology) Richard A. Eisenberg (Tweag I/O) Martin Elsman (University of Copenhagen, Denmark) Ohad Kammar (University of Edinburgh) Naoki Kobayashi (University of Tokyo, Japan) Benoît Montagu (Inria) Jonathan Protzenko (Microsoft Research) (Chair) Kristina Sojakova (INRIA Paris) Don Syme (Microsoft) Matías Toro (University of Chile) Katsuhiro Ueno (Tohoku University)

1 0

Munich Virtual Haskell Meeting, 2021-05-31 @ 19:30
by Leah Neukirchen 28 May '21

28 May '21

Dear all, Next week, our monthly Munich Haskell Meeting will take place again on Monday, May 31 on Google Meet at 19:30 CEST. **Due to meetup limitations in Bavaria, this meeting will take place online!** For details see here: https://muenchen.haskell.bayern/dates.html A Google Meet link to join the room is provided on the page. Everybody is welcome, especially the Haskellers from Bavaria that do not usually come to our Munich meetings due to travel distance! cu, -- Leah Neukirchen <leah(a)vuxu.org> https://leahneukirchen.org/

1 0

PhD position on program verification in Coq
by David Nowak 28 May '21

28 May '21

Dear all, We have an opening for a 3-year PhD position at University of Lille, France. The successful applicant will be funded -- including salary and (international) conference travel -- through a new French-German ANR-funded project. There will also be an opportunity to collaborate with a research team in Japan. Lille is at the heart of Europe: 45 minutes from Bruxelles, 1 hour from Paris, 1 hour and half from London. This is an important university hub that hosts the annual International Cybersecurity Forum (FIC). The start date is September 1st, but might possibly be postponed to October 1st. The PhD position is about the formal proof in Coq for shallow-embedded imperative programs and their compilation into C (more details below). Interested students should meet the following requirements: - Be interested by the topic of the PhD :-) - Have or be about to complete a Master in Computer Science or a related field (Logic, Mathematics, etc.). If you are interested in applying for this opportunity please begin by contacting us {gilles.grimaud,samuel.hym,david.nowak}(a)univ-lille.fr as soon as possible with the following information: - CV/Resume - A brief introduction of yourself, your scientific interests, and if you are familiar with any of the following topics: * formal proof / formal verification, * functional programming * monads * semantics ——————————————————————————————————— Summary: The topic of this PhD offer is the formal proof in Coq for shallow-embedded imperative programs and their compilation into C. More precisely, the objective is to conceive and develop formal tools to simplify code writing and proof of system software for low-end devices. Context: The Coq proof assistant [1] allows to prove properties of programs. Its language, called Gallina, is purely functional. In the Pip project [2], we have considered a monadic subset of C-like Gallina enough to formally write an OS kernel. Objectives: A first objective of this PhD is to extend the monadic subset in order to include further imperative features (such as loops, references or exceptions) that will simplify code writing and proof of system software for low-end devices. For security properties the monadic Hoare logic used for Pip will have to be extended to deal with the new imperative features. For functional properties, there are two possible directions: either use the monadic Hoare logic or monadic equational reasoning as developed in Monae [3]. The relation with FreeSpec [4] should also be investigated. A second objective is to automatically translate programs written in this monadic subset into an AST of the CompCert C verified compiler [5] and to prove formally that this translation is correct, in the sense that properties proved on the monadic subset are also true of the generated C code. [1] https://coq.inria.fr [2] http://pip.univ-lille1.fr [3] https://github.com/affeldt-aist/monae [4] https://github.com/lthms/FreeSpec [5] https://compcert.org ——————————————————————————————————— All the best, -- Gilles Grimaud, Samuel Hym, David Nowak

1 0

International Conference on Informatics Revolution for Smarter Healthcare (IRSH 2021) Prague
by matteo＠confscience.com 27 May '21

27 May '21

Call for papers ************************************************* International Conference on Informatics Revolution for Smarter Healthcare (IRSH 2021) Prague- Czech Republic, October 14-15, 2021 https://confscience.com/irsh/ All papers accepted in IRSH 2021 will be published in Springer CCIS (Communications in Computer and Information Science). CCIS is abstracted/indexed in Scopus, SCImago, EI-Compendex, Mathematical Reviews, DBLP, Google Scholar, and Thomson Reuters Conference Proceedings Citation (Former ISI Proceedings) *************************************************************************** IMPORTANT DATES: - Paper Submission: June 13, 2021 (extended) - Acceptance Notification: July 1, 2021 - Final Manuscript Due: September 1, 2021 *************************************************************************** The IRSH 2021 conference will be held in Conjunction with: International Conference on Applied Data Science and Intelligence (ADSI 2021) International Conference on Recent Theories and Applications in Transportation and Mobility - (RTATM 2021) *************************************************************************** TOPICS: Authors are invited to submit their original papers to address the topics of the conference, including but not limited to: FUNDAMENTALS AND THEORIES - Interoperability and Data Integration - Confidentiality and Data Security - Data protection - Data Sharing - Security, Privacy, and Trust - Emergent healthcare standards - Emergent healthcare architectures - ICT, Ageing and Disability - Physiological and behavioural modelling - Pandemic and disease modeling - Usability and user experience of medical devices - Human behaviour - Clinical investigation regulatory frameworks - Integrated healthcare approaches - eHealth data standards and interoperability (e.g. HL7/FHIR) - Databases and data warehousing - Big Data and Open Data for healthcare - Design and Development of Methodologies for Healthcare - Emergent Communication Technologies - Real-time interaction theories - Emergent Technologies for Ambient Assisted Living - User Interface Design for healthcare - Sustainability - New approaches for accuracy and effectiveness - Data mining and bioinformatics - Enhanced living environments - Analysis and evaluation of healthcare systems INTELLIGENT HEALTHCARE - Pattern recognition and Machine - Learning for healthcare - Cognitive Informatics - Big Data in Healthcare - Wellbeing Informatics - Data Mining and Data Analytics - Data Visualization - Smart environments - Smart Ambient Assisted Living - Intelligent healthcare solutions - Agent-based solutions for healthcare - Collaboration systems - Intelligent Electronic Health Records - Internet of Things for healthcare - Cyber-Physical Systems for healthcare - Ambient Computing and Reasoning - Context Awareness - Smart devices for eldercare - Autonomy and active ageing - Emergent technologies for intelligent Computer Vision - Service production and delivery - Gamification - Multi-modal interaction - Computer-aided detection and diagnosis - Crowdsourcing for smarted healthcare SERVICES, SYSTEMS, AND INFRASTRUCTURES - Emergent healthcare services - Pervasive health systems and services - Remote healthcare management - Emergent healthcare infrastructure - Industry Revolution 4.0 for healthcare - eHealth - Electronic health records - Assistive technologies - Disease surveillance and patient monitoring systems - Prevention and detection systems - Home monitoring - Healthcare management systems - ICT-based therapeutic systems - ICT-based rehabilitation technologies - Wearable health informatics - Emergent technologies for data analytics - Ambient Assisted Leaving (AAL) - Decision Support Systems - Emergent Technologies for Remote AAL Monitoring - Emergent Technologies and Accessibility - 5G for healthcare - Healthcare supply chain and logistics - Wireless Body Networks - Telemedicine and mobile telemedicine - Mobile Systems - Software Defined infrastructures - Patient empowerment systems - Smart technology for remote patient visits - Biosensors - Medical devices APPLICATIONS - eHealth applications - Application of health informatics in clinical cases - Mobile technologies for healthcare applications - Software Systems in healthcare - Social networking and healthcare - Case Studies - Personalization and patient experience - AR and VR applications - Patient billing - Accounting systems - Personnel and payroll - Materials management - Voice recognition systems - Asset management solutions - Disease management - Feedback integration - Clinical software - Crowd-computing applications - Future directions - Drone-based solutions - Software Defined Networks for healthcare *************************************************************************** OUTSTANDING PAPERS: Based on the peer review scores as well as the presentations at the conference, the authors of outstanding papers will be invited to extend their works for a potential publication in journals special issues with high impact factors. *************************************************************************** PAPER SUBMISSION: Papers must be submitted electronically as PDF files via easychair (https://easychair.org/conferences/?conf=irsh2021) All papers will be peer reviewed. Length of Full papers: 12-15 pages long (written in the LNCS/CCIS one-column page format, 400 words per page) Length of Short papers: less than 12 pages For more information, please refer to the conference website: https://confscience.com/irsh/ *************************************************************************** CONTACT For more information, please send an email to info-irsh(a)confscience.com

2 1

PhD position on the formalization of logical calculi in Saarbrücken
by Andrei Popescu 26 May '21

26 May '21

A PhD position is open at the MPI for Informatics in Saarbrücken, supervised by Christoph Weidenbach, Jasmin Blanchette and Sophie Tourret. The project is about using Isabelle/HOL to formalize logical calculi. See https://www.cs.vu.nl/~jbe248/sb_job.html for more information.

1 0

(Online) Utrecht Summer School on Advanced functional programming
by Swierstra, W.S. (Wouter) 25 May '21

25 May '21

SUMMER SCHOOL ON ADVANCED FUNCTIONAL PROGRAMMING Online - 05-9 July 2021 http://www.afp.school # Call for Participation ## About The Advanced Functional Programming summer school has been running for more than ten years. We aim to educate aspiring Haskell programmers beyond the basic material covered by many textbooks. This year the course will be offered *online only*. A typical day will consist a 2-3 hours of lectures, sandwiched between supervised lab sessions. Lectures will be held in the (European) afternoon, but recordings will be made available if attending live is problematic. The lectures will cover several more advanced topics regarding programming with types in Haskell, including topics such as: * monads and applicative functors; * lambda calculus; * generalized algebraic datatypes; * datatype generic programming * type families and type-level programming; ## Lecturers Utrecht staff: * Gabriele Keller * Trevor McDonell * Wouter Swierstra ## Prerequisites We expect students to have a basic familiarity with Haskell already. You should be able to write recursive functions over algebraic data types, such as lists and trees. There is a great deal of material readily available that covers this material. If you've already started learning Haskell and are looking to take your functional programming skills to the next level, this is the course for you. Soft registration deadline: 1 June, 2021 School: 05-09 July, 2021 ## Costs 50 euro - Registration fee We ask ask participants to pay a small registration fee to cover some of our organizational expenses. If this is problematic for you *for whatever reason*, please let us know and we can waive your registration fee. ## Further information Further information, including instructions on how to register, is available on our website: http://www.afp.school

3 2

Package takeover: int-cast
by Mikolaj Konarski 24 May '21

24 May '21

To whom it may concern, I'd like to take over package https://hackage.haskell.org/package/int-cast (I'd maintain it privately, though I'm subscribed to this mailing list from a company address). People have trouble compiling the roguelike game I maintain, because int-cast is not updated to GHC 9.0.1: https://github.com/LambdaHack/LambdaHack/issues/250 Also the test suite QuickCheck dependency is outdated. I've tried contacting the author, but without success. I'm fine giving the package back once the maintainer re-appears, but I'd also be honoured to maintain it indefinitely --- it's a splendid package. I'd also love to share the maintenance burden, mostly to raise the bus factor, so if anybody would like to get the Hackage permissions together with me, please let me know. Cheers, Mikolaj

1 0

Using field accessors both ways in the same block of code?
by David Banas 23 May '21

23 May '21

Is it possible to use record field accessors both in their “normal” way and as values, via RecordWildCards and MyData{..}, in the same block of code?

2 1

Trouble compiling Data.PriorityQueue?
by David Banas 22 May '21

22 May '21

Has anyone else bumped into this compilation error when trying to use Data.PriorityQueue? Building library for priority-queue-0.2.1.. [1 of 1] Compiling Data.PriorityQueue ( src/Data/PriorityQueue.hs, dist/build/Data/PriorityQueue.o ) src/Data/PriorityQueue.hs:120:50-54: error: Ambiguous occurrence ‘unzip’ It could refer to either ‘List.unzip’, imported from ‘Data.List’ at src/Data/PriorityQueue.hs:55:1-24 (and originally defined in ‘GHC.List’) or ‘Seq.unzip’, imported from ‘Data.Sequence’ at src/Data/PriorityQueue.hs:54:1-27 (and originally defined in ‘Data.Sequence.Internal’) | 120 | batches = map ((head *** fromList) . unzip) grouped | ^^^^^ cabal: Failed to build priority-queue-0.2.1 (which is required by exe:ex1 from haskarch-0.1.0.0). See the build log above for details. -db

2 1

[ANN] Darcs 2.16.4 release
by Ben Franksen 21 May '21

21 May '21

On behalf of the Darcs team, I would like to announce the release of Darcs 2.16.4 [1]. Quoting from the release notes [2]: This release is mostly to fix http://bugs.darcs.net/issue2674 which can lead to repository corruption. This is not quite as bad as it sounds, since the broken changes that you could have recorded were consistently ignored when applying the patch. This bug has been in darcs for a very long time and even our own repos contain (ancient) patches with broken move changes, and so far it hasn't caused us any trouble. That said, there are certain patch commutations that will erroneously (and unexpectedly) fail when such a patch is involved. We therefore recommend to upgrade. You may also (after upgrading) run 'darcs check' on your repositories to see if you are affected, and 'darcs repair' them if that is the case. Fortunately, the broken move changes can be safely eliminated from existing patches, and the improved repair command now does exactly that. Thanks to Henning Thielemann for bringing this bug to our attention. [1] https://hackage.haskell.org/package/darcs-2.16.3 [2] https://hackage.haskell.org/package/darcs-2.16.3/changelog Cheers Ben -- I would rather have questions that cannot be answered, than answers that cannot be questioned. -- Richard Feynman

1 1

ML Family Workshop 2021: final call for short abstracts and presentations
by Jonathan Protzenko 21 May '21

21 May '21

(tl;dr) The ML family workshop is back, and the deadline is in a week. The workshop does not have proceedings, making it the perfect venue to run some ideas with the community or present some work in progress within a friendly environment. The PC has a broad expertise and submissions are 3 pages long: when in doubt, just submit! (long version) We are happy to announce that the ML Family Workshop is back for its 2021 edition, which we will be held online on Thursday August 26th, in conjunction with ICFP 2021. The ML family workshop warmly welcomes submission touching on the programming languages traditionally seen as part of the "ML family" (Standard ML, OCaml, F#, CakeML, SML#, Manticore, MetaOCaml, etc.). The scope of the workshop includes all aspects of the design, semantics, theory, application, implementation, and teaching of the members of the ML family. We also encourage presentations from related languages (such as Haskell, Scala, Rust, Nemerle, Links, Koka, F*, Eff, ATS, etc), to exchange experience of further developing ML ideas. ## Submission details Submissions must be at most three pages long; see the full call for papers <https://icfp21.sigplan.org/home/mlfamilyworkshop-2021#Call-for-Presentations> for details. Submission site: https://ml21.hotcrp.com/ ## Important dates Thu, May 27th 2021 (AoE): submission deadline Thu, Jun 17th 2021 (AoE): author notification Thu, Aug 26th: workshop (time slots TBD) ## Program committee Danel Ahman (University of Ljubljana) Robert Atkey (University of Strathclyde) Frédéric Bour (Tarides) Ezgi Çiçek (Facebook London) Youyou Cong (Tokyo Institute of Technology) Richard A. Eisenberg (Tweag I/O) Martin Elsman (University of Copenhagen, Denmark) Ohad Kammar (University of Edinburgh) Naoki Kobayashi (University of Tokyo, Japan) Benoît Montagu (Inria) Jonathan Protzenko (Microsoft Research) (Chair) Kristina Sojakova (INRIA Paris) Don Syme (Microsoft) Matías Toro (University of Chile) Katsuhiro Ueno (Tohoku University)

1 0

faster faster faster but not uglier (how to make nice code AND nice core)?
by Johannes Waldmann 20 May '21

20 May '21

Dear Cafe, * how to un-uglify the following program? * and is it even ugly enough? The following is some artificial example but I think it illustrates some general questions - for which I don't have answers. Do you? I wanted a really fast implementation of a vector addition system where the "vector" contains small numbers only. and I want it packed into a machine word (and finally put these into Data.IntSet). I can write this in low-level Haskell (I did), and I could even use some low-level language (I also did) but I was hoping that I don't need to. https://gitlab.imn.htwk-leipzig.de/waldmann/tf/-/blob/master/TF4.hs#L108 * this is too low-level: This is for vectors of one fixed size - but I want the code to be more generic, and have the compiler do the specialization/unrolling. * and not low-level enough: How do I tell GHC to pack (coerce?) `data Pos` into `Word64`? (It's not https://ghc.gitlab.haskell.org/ghc/doc/users_guide/exts/pragmas.html#unpack… ?) And would it help? Or is it even needed? If I have the data spread over several words, it could still be fine - as long as it's kept in registers? How can I then check that "it's fine"? Yes I know, just look at the core. (That seems to be the ultima ratio of https://ghc.gitlab.haskell.org/ghc/doc/users_guide/hints.html#faster-produc…) But is there/could there be some higher-level mechanism? Perhaps a (type?) annotation that guarantees or checks that core (locally) looks "good"? (does not allocate, ...) NB: For the concrete application (evaluation of positions in some game): 1. graph size is exponential, so a linear speed-up won't really help. 2. brute-force gameplay should be replaced by some symbolic evaluation and simplification. That is in fact my goal. But - as long as we don't have this, the program may be useful for generating conjectures. - J.

4 3

ICFP 2021: First Call for Students Volunteers
by Jaemin Hong 20 May '21

20 May '21

Please don't hesitate to share this information with your students, classmates or colleagues! ICFP'21 FIRST CALL FOR STUDENT VOLUNTEERS ========================================= ICFP provides a forum for researchers and developers to hear about the latest work on the design, implementations, principles, and uses of functional programming. The conference covers the entire spectrum of work, from practice to theory, including its peripheries. In order to smoothly run the conference, associated workshops, and tutorials, we need student volunteers to help out on the practical aspect of the organization. All the events associated with ICFP'21 will take place **virtually** from Sun 22 - Fri 27 August 2021. Even though the event will be virtual, we will more than ever need the help of student volunteers to make sure everything runs smoothly. In return, as an ICFP 2021 student volunteer, you will get more visibility and be able to interact closely with researchers, academics and practitioners from various disciplines and discuss with other students from around the world. While the exact structure of the conference is still being discussed, job assignments for student volunteers will probably include: 1- Assisting with technical sessions, workshops, tutorials, Q&A sessions, social activities, and panels. 2- Helping to get authors' videos prepped and ready for broadcast. 3- Managing channels on a virtual event platform. To be considered as a student volunteer for ICFP, please fill in the following application form. https://forms.gle/cEXE4GfXzm24f6mF6 The permanent link to this form can be found on the official conference website. https://icfp21.sigplan.org/track/icfp-2021-student-volunteers There are two rounds of calls with the following deadlines: * deadline for first round: June 11th, 2021 AoE (notification: June 15th) * deadline for second round: July 16th, 2021 AoE (notification: July 20th)

1 0

Default implementation of Floating (**)
by Fabrício Olivetti de França 19 May '21

19 May '21

Hi, I was using Numeric.Interval in my code and found an issue with the (**) operator, if the interval contains negative values, it will return a wrong result (as reported in this open issue https://github.com/ekmett/intervals/issues/50) Investigating the source of this problem, I found that it uses the default implementation of (**) from base defined as x ** y = exp (log x * y). So I was wondering, is there any reason to have this (potentially dangerous) default implementation on base? Best, Fabricio Olivetti de França

4 7

Position of Lecturer or Senior Lecturer in Cybersecurity at University of Sheffield
by Andrei Popescu 19 May '21

19 May '21

Greetings, The Department of Computer Science at University of Sheffield has an open position of Lecturer or Senior Lecturer in Cybersecurity. Details can be found here: https://www.jobs.ac.uk/job/CFN168/lecturer-senior-lecturer-in-cybersecurity Note that "formalisation and proof of system security properties" is listed as a topic of interest. Women are particularly encouraged to apply. All applicants will be given equal consideration. Best wishes, Andrei

1 0

GSoC 2021, Pandoc Figures accepted proposal and introduction
by Aner Lucero 18 May '21

18 May '21

Hello, My name is Aner[0] and I'm happy to announce that my proposal for this year's pandoc project idea has been accepted. I've uploaded the current version of the proposal here [1] for those interested. Although we might make some changes. I hope I can meet the project's objectives with your help and I'll post updates as the project moves forwards. Best regards Aner [0] https://en.wiktionary.org/wiki/%E1%BC%80%CE%BD%CE%AE%CF%81 [1] https://github.com/argent0/gsoc-2021-proposal

1 0

Final call for the *regular* round of Papers for the Haskell Symposium 2021
by Hage, J. (Jurriaan) 18 May '21

18 May '21

Dear all, This is the final call for the *regular* round of papers for the upcoming Haskell Symposium. Please forward to anyone that you believe might be interested. The deadline for this round is May 21. Apologies for receiving multiple copies of this announcement. Best regards, Jurriaan Hage Chair ================================================================================ ACM SIGPLAN CALL FOR SUBMISSIONS Haskell Symposium 2021 ** virtual ** Thu 26 -- Fri 27 August, 2021 http://www.haskell.org/haskell-symposium/2021/ ================================================================================ The ACM SIGPLAN Haskell Symposium 2021 will be co-located with the 2021 International Conference on Functional Programming (ICFP). Due to COVID-19 it will take place **virtually** this year. Like last year, we will be using a lightweight double-blind reviewing process. See further information below. Different from last year is that we offer a new submission category: the tutorial. Details can be found below. The Haskell Symposium presents original research on Haskell, discusses practical experience and future development of the language, and promotes other forms of declarative programming. Topics of interest include: * Language design, with a focus on possible extensions and modifications of Haskell as well as critical discussions of the status quo; * Theory, such as formal semantics of the present language or future extensions, type systems, effects, metatheory, and foundations for program analysis and transformation; * Implementations, including program analysis and transformation, static and dynamic compilation for sequential, parallel, and distributed architectures, memory management, as well as foreign function and component interfaces; * Libraries, that demonstrate new ideas or techniques for functional programming in Haskell; * Tools, such as profilers, tracers, debuggers, preprocessors, and testing tools; * Applications, to scientific and symbolic computing, databases, multimedia, telecommunication, the web, and so forth; * Functional Pearls, being elegant and instructive programming examples; * Experience Reports, to document general practice and experience in education, industry, or other contexts; * Tutorials, to document how to use a particular language feature, programming technique, tool or library within the Haskell ecosystem; * System Demonstrations, based on running software rather than novel research results. Regular papers should explain their research contributions in both general and technical terms, identifying what has been accomplished, explaining why it is significant, and relating it to previous work, and to other languages where appropriate. Experience reports and functional pearls need not necessarily report original academic research results. For example, they may instead report reusable programming idioms, elegant ways to approach a problem, or practical experience that will be useful to other users, implementers, or researchers. The key criterion for such a paper is that it makes a contribution from which other Haskellers can benefit. It is not enough simply to describe a standard solution to a standard programming problem, or report on experience where you used Haskell in the standard way and achieved the result you were expecting. A new submission category for this year's Haskell Symposium is the tutorial. Like with the experience report and the functional pearl, the key criterion for such a paper is that it makes a contribution from which other Haskellers can benefit. What distinguishes a tutorial is that its focus is on explaining an aspect of the Haskell language and/or ecosystem in a way that is generally useful to a Haskell audience. Tutorials for many such topics can be found online; the distinction here is that by writing it up for formal review it will be vetted by experts and formally published. System demonstrations should summarize the system capabilities that would be demonstrated. The proposals will be judged on whether the ensuing session is likely to be important and interesting to the Haskell community at large, whether on grounds academic or industrial, theoretical or practical, technical, social or artistic. Please contact the program chair with any questions about the relevance of a proposal. If your contribution is not a research paper, please mark the title of your experience report, functional pearl, tutorial or system demonstration as such, by supplying a subtitle (Experience Report, Functional Pearl, Tutorial Paper, System Demonstration). Submission Details ================== Formatting ---------- Submitted papers should be in portable document format (PDF), formatted using the ACM SIGPLAN style guidelines. Authors should use the `acmart` format, with the `sigplan` sub-format for ACM proceedings. For details, see: http://www.sigplan.org/Resources/Author/#acmart-format It is recommended to use the `review` option when submitting a paper; this option enables line numbers for easy reference in reviews. Functional pearls, experience reports, tutorials and demo proposals should be labelled clearly as such. Lightweight Double-blind Reviewing ---------------------------------- Haskell Symposium 2021 will use a lightweight double-blind reviewing process. To facilitate this, submitted papers must adhere to two rules: 1. Author names and institutions must be omitted, and 2. References to authors' own related work should be in the third person (e.g., not "We build on our previous work" but rather "We build on the work of "). The purpose of this process is to help the reviewers come to an initial judgment about the paper without bias, not to make it impossible for them to discover the authors if they were to try. Nothing should be done in the name of anonymity that weakens the submission or makes the job of reviewing the paper more difficult (e.g., important background references should not be omitted or anonymized). In addition, authors should feel free to disseminate their ideas or draft versions of their paper as they normally would. For instance, authors may post drafts of their papers on the web or give talks on their research ideas. A reviewer will learn the identity of the author(s) of a paper after a review is submitted. Page Limits ----------- The length of submissions should not exceed the following limits: Regular paper: 12 pages Functional pearl: 12 pages Tutorial: 12 pages Experience report: 6 pages Demo proposal: 2 pages There is no requirement that all pages are used. For example, a functional pearl may be much shorter than 12 pages. In all cases, the list of references is not counted against these page limits. Deadlines --------- Regular track and demos: Submission deadline: 21 May 2021 (Fri) Notification: 23 June 2021 (Wed) Deadlines are valid anywhere on Earth. Submission ---------- Submissions must adhere to SIGPLAN's republication policy (http://sigplan.org/Resources/Policies/Republication/) and authors should be aware of ACM's policies on plagiarism (https://www.acm.org/publications/policies/plagiarism) Program Committee members are allowed to submit papers, but their papers will be held to a higher standard. The paper submission deadline and length limitations are firm. There will be no extensions, and papers violating the length limitations will be summarily rejected. Papers should be submitted through HotCRP at: https://haskell21.hotcrp.com/ Improved versions of a paper may be submitted at any point before the submission deadline using the same web interface. Supplementary material: Authors have the option to attach supplementary material to a submission, on the understanding that reviewers may choose not to look at it. This supplementary material should not be submitted as part of the main document; instead, it should be uploaded as a separate PDF document or tarball. Supplementary material should be uploaded at submission time, not by providing a URL in the paper that points to an external repository. Authors can distinguish between anonymized and non-anonymized supplementary material. Anonymized supplementary material will be visible to reviewers immediately; non-anonymized supplementary material will be revealed to reviewers only after they have submitted their review of the paper and learned the identity of the author(s). Resubmitted Papers: authors who submit a revised version of a paper that has previously been rejected by another conference have the option to attach an annotated copy of the reviews of their previous submission(s), explaining how they have addressed these previous reviews in the present submission. If a reviewer identifies him/herself as a reviewer of this previous submission and wishes to see how his/her comments have been addressed, the conference chair will communicate to this reviewer the annotated copy of his/her previous review. Otherwise, no reviewer will read the annotated copies of the previous reviews. Proceedings =========== Accepted papers will be included in the ACM Digital Library. Their authors will be required to choose one of the following options: - Author retains copyright of the work and grants ACM a non-exclusive permission-to-publish license (and, optionally, licenses the work with a Creative Commons license); - Author retains copyright of the work and grants ACM an exclusive permission-to-publish license; - Author transfers copyright of the work to ACM. For more information, please see ACM Copyright Policy (http://www.acm.org/publications/policies/copyright-policy) and ACM Author Rights (http://authors.acm.org/main.html) Accepted proposals for system demonstrations will be posted on the symposium website but not formally published in the proceedings. Publication date: The official publication date of accepted papers is the date the proceedings are made available in the ACM Digital Library. This date may be up to two weeks prior to the first day of the conference. The official publication date affects the deadline for any patent filings related to published work. Artifacts ========= Authors of accepted papers are encouraged to make auxiliary material (artifacts like source code, test data, etc.) available with their paper. They can opt to have these artifacts published alongside their paper in the ACM Digital Library (copyright of artifacts remains with the authors). If an accepted paper's artifacts are made permanently available for retrieval in a publicly accessible archival repository like the ACM Digital Library, that paper qualifies for an Artifacts Available badge (https://www.acm.org/publications/policies/artifact-review-badging#available) Applications for such a badge can be made after paper acceptance and will be reviewed by the PC chair. Program Committee ================= Edwin Brady University of St Andrews Koen Claessen Chalmers University of Technology Dominique Devriese Vrije Universiteit Brussel Andy Gill University of Kansas Jurriaan Hage (chair) Universiteit Utrecht Zhenjiang Hu Peking University Ranjit Jhala University of California Patricia Johann Appalachian State University Yukiyoshi Kameyama University of Tsukuba George Karachalias Tweag Ralf Laemmel University of Koblenz-Landau Daan Leijen Microsoft Research Ben Lippmeier Ghost Locomotion Neil Mitchell Facebook Alberto Pardo Universidad de la Republica, Uruguay Matt Roberts Macquarie University Janis Voigtlaender University of Duisburg-Essen Nicolas Wu Imperial College London If you have questions, please contact the chair at: j.hage(a)uu.nl ================================================================================

1 0

Compile time checking of space leaks
by Clinton Mead 17 May '21

17 May '21

I've asked a question on stackoverflow, which is basically a typical question about folds and space leaks due to laziness, in this case complicated by a Maybe and foldM: https://stackoverflow.com/questions/67559724/constant-space-short-circuitin… That's getting answered, but when I saw the answers, I noticed people are using a fairly mechanical process, basically going through how the code would be evaluated step by step, to determine whether there's a space leak or not. And that tends to be the case for most of these questions. It's complicated enough that it's hard to keep track of in my head, but I thought to myself, wouldn't a computer be able to check this much more quickly and reliably? There doesn't seem to be much human intuition required here, just a lot of pen and paper work to try to determine whether you've got an unevaluated thunk hanging around at the end of an iteration. I understand doing this analysis for the whole program may be impossible, but we can certainly do it for parts, because flesh and blood human beings can do it for stackoverflow answers. Is there anything I can get that helps me identify space leaks like this at compile time (that is, pre-runtime)? Either from GHC or from another tool? Or do we just have to rely on squishy humans to do this as compile time and our only automated tools have to be delayed til runtime? Thanks, Clinton

2 1

Second Call for Talks: Haskell Implementors' Workshop @ ICFP'21
by Ningning Xie 17 May '21

17 May '21

Call for Talks ACM SIGPLAN Haskell Implementors' Workshop https://icfp21.sigplan.org/home/hiw-2021 Virtual, 22 Aug, 2021 Co-located with ICFP 2021 https://icfp21.sigplan.org/ Important dates --------------- Deadline: Wednesday, 30 June, 2021 (AoE) Notification: Wednesday, 14 July, 2021 Workshop: Sunday, 22 August, 2021 The 13th Haskell Implementors' Workshop is to be held alongside ICFP 2021 this year virtually. It is a forum for people involved in the design and development of Haskell implementations, tools, libraries, and supporting infrastructure, to share their work and discuss future directions and collaborations with others. Talks and/or demos are proposed by submitting an abstract, and selected by a small program committee. There will be no published proceedings. The workshop will be informal and interactive, with open spaces in the timetable and room for ad-hoc discussion, demos, and lightning short talks. Scope and target audience ------------------------- It is important to distinguish the Haskell Implementors' Workshop from the Haskell Symposium which is also co-located with ICFP 2021. The Haskell Symposium is for the publication of Haskell-related research. In contrast, the Haskell Implementors' Workshop will have no proceedings -- although we will aim to make talk videos, slides and presented data available with the consent of the speakers. The Implementors' Workshop is an ideal place to describe a Haskell extension, describe works-in-progress, demo a new Haskell-related tool, or even propose future lines of Haskell development. Members of the wider Haskell community encouraged to attend the workshop -- we need your feedback to keep the Haskell ecosystem thriving. Students working with Haskell are specially encouraged to share their work. The scope covers any of the following topics. There may be some topics that people feel we've missed, so by all means submit a proposal even if it doesn't fit exactly into one of these buckets: * Compilation techniques * Language features and extensions * Type system implementation * Concurrency and parallelism: language design and implementation * Performance, optimisation and benchmarking * Virtual machines and run-time systems * Libraries and tools for development or deployment Talks ----- We invite proposals from potential speakers for talks and demonstrations. We are aiming for 20-minute talks with 5 minutes for questions and changeovers. We want to hear from people writing compilers, tools, or libraries, people with cool ideas for directions in which we should take the platform, proposals for new features to be implemented, and half-baked crazy ideas. Please submit a talk title and abstract of no more than 300 words. Submissions should be made via HotCRP. The website is: https://icfp-hiw21.hotcrp.com/ We will also have lightning talks session. These have been very well received in recent years, and we aim to increase the time available to them. Lightning talks be ~7mins and are scheduled on the day of the workshop. Suggested topics for lightning talks are to present a single idea, a work-in-progress project, a problem to intrigue and perplex Haskell implementors, or simply to ask for feedback and collaborators. Logistics --------- Due to the on-going COVID-19 situation, ICFP (and, consequently, HIW) will be held remotely this year. However, the organizers are still working hard to provide for a great workshop experience. While we are sad that this year will lack the robust hallway track that is often the highlight of HIW, we believe that this remote workshop presents a unique opportunity to include more of the Haskell community in our discussion and explore new modes of communicating with our colleagues. We hope that you will join us in making this HIW as vibrant as any other. Program Committee ----------------- * Dominique Devriese (Vrije Universiteit Brussel) * Daan Leijen (Microsoft Research) * Andres Löh (Well-Typed LLP) * Julie Moronuki (Typeclass Consulting) * John Wiegley (DFINITY) * Ningning Xie (the University of Hong Kong) * Edward Z. Yang (Facebook AI Research) Contact ------- * Ningning Xie <xnning at hku.hk>

1 0

foldMap for semigroups
by coot＠coot.me 15 May '21

15 May '21

Base has: * foldMap :: (Foldable t, Monoid a) => (x -> a) -> t x -> a * foldr1 :: (Foldable t) => (a -> a -> a) -> t x -> a Is there a good reason why it does not have: ``` foldMap1 :: (Foldable t, Semigroup a, Functor f) => (a -> a) -> t x -> a foldMap1 = fodlr1 (<>) . fmap f ``` Like `foldr1` it is partial for any foldable that can be empty. Best regards, Marcin Szamotulski Sent with ProtonMail Secure Email.

3 3

OCaml Users and Developers Workshop 2021: call for presentations
by Frédéric Bour 15 May '21

15 May '21

It is my pleasure to invite submissions to the OCaml Users and Developers Workshop 2021, which is again co-located with ICFP and will be held virtually this year. The OCaml Users and Developers Workshop brings together industrial users of OCaml with academics and hackers who are working on extending the language, type system, and tools. Previous editions have been co-located with ICFP 2012 in Copenhagen, ICFP 2013 in Boston, ICFP 2014 in Gothenburg, ICFP 2015 in Vancouver, ICFP 2016 in Nara, ICFP 2017 in Oxford, ICFP 2018 in St Louis, ICFP 2019 in Berlin, and was virtual for ICFP 2020, following the OCaml Meetings in Paris in 2010 and 2011. Please note that the deadline for abstract submission is set on May 20, a week from now. Don't wait to start preparing your submission :-). ## Important Links - workshop site: https://icfp21.sigplan.org/home/ocaml-2021 - submission site: https://ocaml2021.hotcrp.com ## Important dates * Thursday 20th May (any time zone): Abstract submission deadline * Friday 18th July: Author notification * Friday 27th August: OCaml Workshop ## Scope Presentations and discussions focus on the OCaml programming language and its community. We aim to solicit talks on all aspects related to improving the use or development of the language and its programming environment, including, for example (but not limited to): * compiler developments, new backends, runtime and architectures * practical type system improvements, such as GADTs, first-class modules, generic programming, or dependent types * new library or application releases, and their design rationales * tools and infrastructure services, and their enhancements * prominent industrial or experimental uses of OCaml, or deployments in unusual situations. ## Presentations Presentations will be held in the online format. Each presentation comprise a prerecorded presentation and an interactive live Q&A session after the talk. Each talk will be re-translated three times in different time zones. Session chairs and volunteers will assist the authors in preparing and casting the presentation. Each presentation will be made available through the ocaml.org website. ## Submission To submit a presentation, please register a description of the talk (about 2 pages long) at https://ocaml2021.hotcrp.com/ providing a clear statement of what will be provided by the presentation: the problems that are addressed, the solutions or methods that are proposed. LaTeX-produced PDFs are a common and welcome submission format. For accessibility purposes, we ask PDF submitters to also provide the sources of their submission in a textual format, such as .tex sources. Reviewers may read either the submitted PDF or the text version. ## Camera ready presentations A pre-recorded versions of accepted presentation shall be provided before August, 13th. Volunteers will provide technical assistance to authors as well as provide necessary feedback and ensure that all videos match our quality standards. ## ML family workshop The ML family workshop, held on the previous day, deals with general issues of the ML-style programming and type systems, focuses on more research-oriented work that is less specific to a language in particular. There is an overlap between the two workshops, and we have occasionally transferred presentations from one to the other in the past. Authors who feel their submission fits both workshops are encouraged to mention it at submission time and/or contact the Program Chairs. ## Program Commitee Frédéric Bour, Tarides, France Cristina Rosu, Janestreet, UK Hakjoo Oh, Korea University, Korea Hugo Heuzard, France Jeffrey A. Scofield, Formalsim, USA Jonathan Protzenko, MSR, USA Joris Giovanangeli, Ahrefs, Singapore Jun Furuse, Dailambda, Japan Kihong Heo, KAIST, Korea Kate Deplaix, OCaml Labs, UK Mehdi Bouaziz, Nomadic Labs, France Simon Castellan, INRIA, France Ryohei Tokuda, Idein, Japan Vaivaswatha Nagaraj, Zilliqa, India Youyou Cong, Tokyo Institute of Technology, Japan

1 0