April 2024 - Haskell-Cafe

Call for Talks: Haskell Implementors' Workshop 2024
by Matthew Pickering 08 Jul '24

08 Jul '24

``` ACM SIGPLAN Haskell Implementors' Workshop https://icfp24.sigplan.org/home/hiw-2024 Milan, Italy, September 2, 2024 Co-located with ICFP 2024 https://icfp24.sigplan.org/ ``` ## Important dates * Deadline: July 19, 2024 (AoE) * Notification: August 2, 2024 * Workshop: September 2, 2024 The 16th Haskell Implementors’ Workshop is to be held alongside ICFP 2024 this year in Milan. 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 to 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 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 2024. 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 are encouraged to attend the workshop – we need your feedback to keep the Haskell ecosystem thriving. Students working with Haskell are especially 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, optimization 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 can be made via HotCRP at https://hiw2024.hotcrp.com until July 19 (anywhere on earth). We will also have a lightning talks session. These have been very well received in recent years, and we aim to increase the time available to them. Lightning talks should 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. ## Program Committee * Matthew Pickering (Well-Typed LLP) * David Binder (University of Tübingen) * Gabriella Gonzalez (Mercury) * Sylvain Henry (IOG) * Teofil Camarasu (Tracsis) ## Contact * Matthew Pickering

1 1

2nd Call for Papers: ACM Workshop on Functional Software Architecture [Deadline June 3]
by Michael Sperber 04 Jun '24

04 Jun '24

====================================================================== *** FUNARCH 2024 -- CALL FOR PAPERS *** Second ACM SIGPLAN Workshop on Functional Software Architecture - FP in the Large 6th September 2024, Milan, Italy Co-located with ICFP 2024 https://functional-architecture.org/events/funarch-2024/ ====================================================================== TIMELINE: Paper submission 3rd June 2024 Author notification 30th June 2024 Camera ready copy 18th July 2024 Workshop 6th Sept 2024 BACKGROUND: "Functional Software Architecture" refers to methods of construction and structure of large and long-lived software projects that are implemented in functional languages and released to real users, typically in industry. The goals for the workshop are: - To assemble a community interested in software architecture techniques and technologies specific to functional programming; - To identify, categorize, and document topics relevant to the field of functional software architecture; - To connect the functional programming community to the software architecture community to cross-pollinate between the two. The workshop follows on from the Functional Software Architecture open space that was held at ICFP 2022 in Slovenia. SCOPE: The workshop seeks submissions in a range of categories: - You're a member of the FP community and have thought about how to support programming in the large, for example by framing functional ideas in architectural terms or vice verse, comparing different languages in terms of their architectural capabilities, clarifying architectural roles played by formal methods, proof assistants and DSLs, or observing how functional concepts are used in other language and architecture communities. Great, submit a research paper! - You're a member of the architecture community, and have thought about how your discipline might help functional programmers, for example by applying domain-driven design, implementing hexagonal architecture, or designing self-contained systems. Excellent, submit a research paper! - You've worked on a large project using functional programming, and it's worked out well, or terribly, or a mix of both; bonus points for deriving architectural principles from your experience. Wonderful, submit an experience report! - You know a neat architectural idiom or pattern that may be useful to others developing large functional software systems. Fabulous, submit an architectural pearl! - You have something that doesn't fit the above categories, but that still relates to functional software architecture, such as something that can be written up, or that could be part of the workshop format like a panel debate or a fishbowl. Superb, submit to the open category! Research 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 architectural pearls need not necessarily report original research results. The key criterion for such papers is that they make a contribution from which others can benefit. It is not enough simply to describe a large software system, or to present ideas that are specific to a particular system. Open category submissions that are not intended for publication are not required to follow the formatting guidelines, and can submit in PDF, word or plain text format as preferred. Not knowing what kinds of submissions we will receive, we cannot be specific as to how they will be evaluated. However, submissions that seem likely to stimulate discussion around practices in functional architecture are encouraged. If you are unsure whether your contribution is suitable, or if you need any kind of help with your submission, please email the program chairs at <funarch2024(a)easychair.org>. Papers must be submitted by 3rd June 2024 using the EasyChair submission page: https://easychair.org/my/conference?conf=funarch2024 Formatting: submissions intended for publication must be in PDF format and follow the ACM SIGPLAN style guidelines, using the acmart format and the sigplan sub-format. Please use the review option when submitting, as this enables line numbers for easy reference in reviews. For further details, see SIGPLAN's author information: http://www.sigplan.org/Resources/Author/#acmart-format If your submission is not a research paper, please mark this using a subtitle (Experience Report, Architectural Pearl, Open Category). Length: submissions must adhere to the limits specified below. However, there is no requirement or expectation that all pages are used, and authors are encouraged to strive for brevity. Research papers 5 to 12+ pages Architectural pearls 5 to 12 pages Experience reports 3 to 6 pages Open category 1 to 6 pages Publication: The proceedings of FUNARCH 2024 will be published in the ACM Digital Library, and authors of accepted papers are required to agree to one of the standard ACM licensing options. Accepted papers must be presented at the workshop by one of the authors, but in special cases we may consider remote presentation. The official publication date is the date the papers 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. PROGRAM CHAIRS: Mike Sperber (Active Group, Germany) Perdita Stevens (University of Edinburgh, UK) PROGRAM COMMITTEE: Annette Bieniusa (University of Kaiserslautern) Jeffrey Young (IOG) Will Crichton (Brown University) Isabella Stilkerich (Schaeffler Technologies AG) Kiko Fernandez-Reyes (Ericsson) Ryan Scott (Galois) Satnam Singh (Groq) Facundo Dominguez (Tweag) Ilya Sergey (University of Singapore) Martin Elsman (University of Copenhagen) Benjamin Pierce (University of Pennsylvania) Matthew Flatt (University of Utah) Nada Amin (Harvard University) Richard Eisenberg (Jane Street) WORKSHOP VENUE: The workshop will be co-located with the ICFP 2024 conference at the Fiera Milano Congressi, Milan, Italy.

1 1

Call for Papers: Scheme '24
by Kristopher K Micinski 29 Apr '24

29 Apr '24

-------------------------------------------------------------------------------- CALL FOR PAPERS The 2024 Workshop on Scheme and Functional Programming Co-located with ICFP 2024 (Milan, Italy) https://icfp24.sigplan.org/home/scheme-2024 -------------------------------------------------------------------------------- The 2024 Scheme and Functional Programming Workshop is calling for submissions. We invite high-quality papers and talk proposals about novel research results, lessons learned from practical experience in an industrial or educational setting, and even new insights on old ideas. We welcome and encourage submissions that apply to any dynamic functional language, especially those that can be considered a Scheme: from strict subsets of RnRS to other "Scheme" implementations, to Racket, to Lisp dialects including Clojure, Emacs Lisp, Common Lisp, to functional languages with continuations and/or macros (or extended to have them) such as Dylan, ECMAScript, Hop, Lua, Scala, Rust, etc. The elegance of the paper and the relevance of its topic to the interests of Schemers will matter more than the surface syntax of the examples used. * Topics Topics of interest include (but are not limited to): - Interaction: program-development environments, debugging, testing, refactoring - Implementation: interpreters, compilers, tools, garbage collectors, benchmarks - Extension: macros, hygiene, domain-specific languages, reflection, and how such extension affects interaction - Expression: control, modularity, ad hoc and parametric polymorphism, types, aspects, ownership models, concurrency, distribution, parallelism, non-determinism, probabilism, and other programming paradigms - Integration: build tools, deployment, interoperation with other languages and systems - Formal semantics: theory, analyses and transformations, partial evaluation - Human factors: past, present and future history, evolution and sociology of the language Scheme, its standard and its dialects - Education: approaches, experiences, curricula - Applications: industrial uses of Scheme - Scheme pearls: elegant, instructive uses of Scheme * Dates - Submission deadline is Thursday July 18, 2024. - Authors will be notified by Monday August 12, 2024. - Camera-ready versions are due Thursday August 29, 2024. - Workshop will be held in Milan, Italy on Saturday September 7, 2024. All deadlines are 23:59 UTC-12, anywhere on Earth. * Submission Information We encourage all kinds of submissions, including full papers, experience reports, and lightning talks. Papers and experience reports are expected to be 10–24 pages in length using the single-column SIGPLAN acmart style. (For reference, this is about 5–12 pages of the older SIGPLAN 2-column 9pt style.) Abstracts submitted for lightning talks should be limited to 192 words. Authors of each accepted submission are invited to attend and be available for the presentation of that paper at the conference. The schedule for presentations will be determined and shared with authors after the full program has been selected. The size limits above exclude references and any optional appendices. There are no size limits on appendices, but the papers should stand without the need to read them, and reviewers are not required to read them. Authors are encouraged to publish any code associated to their papers under an open source license, so that reviewers may try the code and verify the claims. Proceedings will be uploaded to arXiv.org (https://arXiv.org/) Publication of a paper at this workshop is not intended to replace conference or journal publication, and does not preclude re-publication of a more complete or finished version of the paper at some later conference or in a journal. Please submit papers through the workshop's HotCRP site (https://scheme2024.hotcrp.com/) * Lightweight double-blind reviewing Scheme 2024 will use lightweight double-blind reviewing. Submitted papers must omit author names and institutions and reference the authors’ own related work in the third person (e.g., not “we build on our previous work…” but rather “we build on the work of…”). The purpose 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). * Formatting Information Full papers and experience reports should use the SIGPLAN acmsmall option to acmart. We recommend using the anonymous and review options to acmart when submitting a paper; these options hide the author names and enable line numbers for easy reference in review. LaTeX and Microsoft Word templates for this format are available through SIGPLAN (https://www.sigplan.org/Resources/Author/) Lightning talks can be submitted as either a text file or a PDF file. * Workshop Organization Organizing Committee: Kristopher Micinski (Syracuse University, United States) Youyou Cong (Tokyo Institute of Technology, Japan) Program Committee: Julia Belyakova (Purdue University, United States) Kimball Germane (Brigham Young University, United States) Yuki Nishida (Kyoto University, Japan) Gabriel Scherer (Inria Saclay, France) Philipp Schuster (University of Tübingen, Germany) Taro Sekiyama (National Institute of Informatice, Japan) Michael Sperber (Active Group GmbH, Germany)

1 0

Spurious [-Woverlapping-patterns] -- [cont] ghc should be able to deduce correct use of partial functions
by Olaf Klinke 29 Apr '24

29 Apr '24

> I think this is a similar 'failure to deduce' partiality as last > week's > thread; but the other way round (and with ViewPatterns) -- at GHC > 8.10.7: > > GHCi> :set -XViewPatterns > GHCi> :set -Wincomplete-patterns -- also warns overlapping > GHCi> (\x -> case x of {((\(Just j) -> j) -> j2) -> j2; Nothing -> > 'N'}) > Nothing > > ===> <interactive>: warning: [-Woverlapping-patterns] > Pattern match is redundant > In a case alternative: Nothing -> ... > *** Exception: <interactive>:16:21-34: Non-exhaustive patterns in > lambda > > (Same Warning then same Exception if I compile the code.) I think what we see here is an instance of the fact that all checks must break down in presence of view patterns. If I parsed your code correctly, the case analysis has two branches. The first uses a view pattern with a function, call it v for the moment. The result of v is bound to another pattern, in your case the wildcard j2 and that is returned as-is, so in pseudo-Haskell: case (v x) of j2 -> j2 case x of Nothing -> 'N' Now your view function v happens to be partial, it pattern-matches its argument and only provides a branch for the Just case. v = \(Just j) -> j = Data.Maybe.fromJust That is why you see the exception when you call this function with 'Nothing'. And indeed the second match is redundant insofar as the view pattern will evaluate v for any x. Since v could be anything, like unsafePerformIO (lauchMissiles >> return j) GHC does not examine this and thus can not decide that v does not match the cases that the Nothing branch does. If you swap the two branches and make the view pattern the last one, then both the exception and the warning go away. Olaf

2 2

Spurious [-Woverlapping-patterns] -- [cont] ghc should be able to deduce correct use of partial functions
by Anthony Clayden 27 Apr '24

27 Apr '24

I think this is a similar 'failure to deduce' partiality as last week's thread; but the other way round (and with ViewPatterns) -- at GHC 8.10.7: GHCi> :set -XViewPatterns GHCi> :set -Wincomplete-patterns -- also warns overlapping GHCi> (\x -> case x of {((\(Just j) -> j) -> j2) -> j2; Nothing -> 'N'}) Nothing ===> <interactive>: warning: [-Woverlapping-patterns] Pattern match is redundant In a case alternative: Nothing -> ... *** Exception: <interactive>:16:21-34: Non-exhaustive patterns in lambda (Same Warning then same Exception if I compile the code.) So GHC isn't smart enough, despite the explicit `(\(Just j) -> ...)`, to see that ViewPattern usage is incomplete? I thought ViewPatterns got desugarred into clunky chains of nested `case`s, so that the pattern coverage checker could see what's going on? I was testing this because if anything I expected it to report coverage was incomplete. To get both a claim "Pattern match is redundant" and "Non-exhaustive" seems particularly unhelpful. AntC

1 0

Is it possible to nest this kind of "continuation" (a -> b -> r)
by PICCA Frederic-Emmanuel 21 Apr '24

21 Apr '24

Hello, I have this nest ∷ [(a → r) → r] → ([a] → r) → r nest xs = runCont (Prelude.mapM cont xs) but now I need this nest2 ∷ [(a → b → r) → r] → ([a] → [b] → r) → r nest2 xs = ... and this nest3 :: ... Do you think that there is a generic way to write all these nestX methodes. thanks for your help Frédéric

4 3

ghc should be able to deduce correct use of partial functions and not give a warning in such cases
by George Colpitts 21 Apr '24

21 Apr '24

ghc should be able to deduce correct use of partial functions and not give a warning in such cases, e.g. in 9.8.2 if null ys then [] else [(xs,tail ys)]) gets a warning warning: [GHC-63394] [-Wx-partial] but it is clear that this use of tail will never be a problem so IMHO that line of code should not get a warning. Does anybody know if there is a plan or enhancement request to eliminate such warnings? Cheers George

8 17

Student Research Competition (SRC) at ICFP 2024
by Favonia 21 Apr '24

21 Apr '24

ICFP 2024 Student Research Competition Call for Submissions ICFP 2024 invites students to participate in the Student Research Competition in order to present their research and get feedback from prominent members of the programming language research community. The SRC consists of three rounds: * Submission of an extended abstract * Poster session at ICFP 2024 * Finalists' presentations at ICFP 2024 During the first round students submit an extended abstract detailing their research to be reviewed by the program committee. Those students whose abstracts get accepted advance to the poster session round which will take place during ICFP 2024. Winners of the poster session advance to the next round, where they will give a 5-minute presentation about their work on the ICFP main stage in front of a live audience. ### IMPORTANT DATES AND TIMES * Submission Deadline: 23 May 2024 (Thursday) * Author Notification: 14 June 2024 (Friday) 12:00 PM CST * ICFP 2024 Conference in Milan, Italy: 2 September 2024 (Monday) - 7 September 2024 (Saturday) ### SUBMISSION OF EXTENDED ABSTRACTS * Submission Website: https://icfp24src.hotcrp.com 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://icfp24.sigplan.org/track/icfp-2024-student-research-competition

1 0

Re: [Haskell-cafe] ghc should be able to deduce correct use of partial functions and not give a warning in such cases
by Anthony Clayden 20 Apr '24

20 Apr '24

> > So your code is essentially pattern matching on a list to decide ..., then pattern matching on the Bool to split between two cases, then pattern matching on the list again. If you had kept the result of the first pattern match there would be no need for the latter two. > > Essentially the problem is "boolean blindness" ... > > This style of coding is generally more readable, maintainable, and less error-prone. ... > +1 to Ben's wise advice. +1 to "more readable". Haskell is a 'functional language' does not mean everything everywhere has to be expressed only through functions. Perhaps we should promote 'Algebraic data types' (yay mathy!) and 'pattern matching' right up front on the 'Features' section of Haskell.org? AntC

1 0

cabal install: Failed to download aeson-2.2.1.0
by Johannes Waldmann 19 Apr '24

19 Apr '24

Dear Cafe. "cabal install" sometimes cannot download aeson. This happens repeatedly (in recent days) but it's not fully reproducible. Example where it happens in CI (image haskell-slim) https://git.imn.htwk-leipzig.de/waldmann/pure-matchbox/-/jobs/41533 What might be the reason? - J.

1 0