May 2021 - Haskell-Cafe

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 19 May '21

19 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 16 May '21

16 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 14 May '21

14 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