- Haskell-Cafe - Haskell.org

Datakind and instance
by PICCA Frederic-Emmanuel 14 Jun '24

14 Jun '24

Hello, I have a class class HasIniConfig where getConfig ... a kind using DataKind data ProjectionType = TypeA | TypeB ... I would like to create instance for each 'TypeX But when I try to write an instance I get this error src/Hkl/Binoculars/Projections/QCustom.hs:195:23: error: • Expected a type, but ‘'QCustomProjection’ has kind ‘ProjectionType’ • In the first argument of ‘HasIniConfig’, namely ‘'QCustomProjection’ In the instance declaration for ‘HasIniConfig 'QCustomProjection’ | 195 | instance HasIniConfig 'QCustomProjection where | ^^^^^^^^^^^^^^^^^^ I should add class HasIniConfig (a :: ProjectionType) where But in that cas I can not create instance for other type, and I need to :) I would be glade if someone could explain how to all this. Thanks Frederic

2 2

POPL 2025: Call for Workshops and Co-located Events
by Ningning Xie 13 Jun '24

13 Jun '24

CALL FOR WORKSHOPS AND CO-LOCATED EVENTS POPL 2025 52nd ACM SIGPLAN-SIGACT Symposium on Principles of Programming Languages Sun 19 - Sat 25, January 2025 Denver, Colorado, United States https://popl25.sigplan.org The 52nd ACM SIGPLAN-SIGACT Symposium on Principles of Programming Languages (POPL 2025) will be held in Denver, Colorado, United States. POPL provides a forum for the discussion of fundamental principles and important innovations in the design, definition, analysis, transformation, implementation and verification of programming languages, programming systems, and programming abstractions. Events focusing on experimental and theoretical topics are welcome. Proposals are invited for workshops and other events to be co-located with POPL 2025. All co-located events are sponsored by SIGPLAN ( http://acm.org/sigplan/) Workshops should be more informal and focused than POPL itself, and include sessions that enable interaction among the workshop attendees. The preference is for one-day workshops, but other schedules can also be considered. --------------------------------------------------------------------- Submission details Deadline for submission: 26 July 2024 Notification of acceptance: 2 August 2024 A workshop proposal should provide the following information: * Name of the workshop. * Duration of the workshop. * Whether the workshop will be Conference-approved or SIGPLAN-approved (see below). * Organizers: names, affiliation, contact information, brief (100 words) biography. * A short description (150-200 words) of the topic. * Event format: workshop; type of submissions if any; review process; results dissemination. * Expected attendance and target audience. * Potential PC members - please do not contact them before the workshop is approved. * History of the workshop. * Plans for remote participation Proposals must be submitted in PDF form by email with the subject POPL 2025 Workshop Proposal: [workshop name], to the workshop co-chairs: Christoph Matheja (chmat(a)dtu.dk) and Robert Rand (rand(a)uchicago.edu) --------------------------------------------------------------------- SIGPLAN Sponsorship POPL co-located events are sponsored by SIGPLAN (http://sigplan.org/) There are two kinds of co-located events: Conference-approved (no proceedings) and SIGPLAN-approved (proceedings in the ACM Digital Library). See http://www.sigplan.org/Resources/Guidelines/Workshops/ for more information, including a full listing of prescriptions for Conference-approved and SIGPLAN-approved workshops. SIGPLAN-approved workshops must respect the SIGPLAN Diversity Policy. Proposals for SIGPLAN-approved workshops must additionally include the gender, country of affiliation, and professional status of potential PC members. See https://www.sigplan.org/Resources/Policies/Diversity/ for more details. --------------------------------------------------------------------- Selection committee All submissions will be evaluated by a committee comprising the workshops co-chairs, the general chair, and the program chair. --------------------------------------------------------------------- Further information Any questions regarding POPL 2025 co-located event proposals should be addressed to the workshops chairs Christoph Matheja (chmat(a)dtu.dk) and Robert Rand (rand(a)uchicago.edu)

1 0

Call for Papers: SPLASH 2024 Student Research Competition
by Umar Farooq 07 Jun '24

07 Jun '24

======================================================================== SPLASH 2024 Student Research Competition Call for Papers Student Research Competition will be held as part of The ACM Conference on Systems, Programming, Languages, and Applications: Software for Humanity (SPLASH'24) October 20-25, 2024, Pasadena, California, United States https://2024.splashcon.org/track/splash-2024-SRC ======================================================================== ### Important dates Submission Deadline: Mon Jul 8, 2024 Author Notification: Mon Aug 19, 2024 Camera Ready: Sun Sep 1, 2024 The ACM Student Research Competition (SRC) offers a unique opportunity for undergraduate and graduate students to present their research to a panel of judges and conference attendees at SPLASH. The SRC provides visibility and exposes up-and-coming researchers to computer science research and the research community. This competition also gives students an opportunity to discuss their research with experts in their field, get feedback, and sharpen their communication and networking skills. ### Eligibility criteria Participants must have current student status, either graduate or undergraduate, at the time of the competition. Participants in the SRC must also be current ACM (student) members. ### Prizes Winners of the three top places in each category receive prizes of $500 for the first place winner, $300 for the second place winner and $200 for the third place winner, respectively. The top three undergraduate and graduate winners receive an award medal and a one-year complimentary ACM student membership with a subscription to ACM's Digital Library. ### ACM SRC Grand Finals First place winners in each category will be invited to participate in the ACM SRC Grand Finals, an online round of competition between first-place SRC winners from different ACM conferences held in 2024. Grand Finals will be judged by an ACM-appointed panel of judges. Winners of the three top Grand Finals places in each category will receive additional prizes of $500 for the first place winner, $300 for the second place winner and $200 for the third place winner, respectively. Winners of the SRC Grand Finals are recognized at the Annual ACM Awards Banquet along with prestigious ACM award winners, including the winner of the Turing Award. ##### Review Committee Review Committee Chairs: Anders Miltner, Simon Fraser University Jiasi Shen, The Hong Kong University of Science and Technology

1 0

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

Exhaustive pattern match warning and GADTs
by William Yager 01 Jun '24

01 Jun '24

Hello cafe, I'm writing a bit of code with state machines that are only allowed to make certain types of transitions between certain classes of states (e.g. "ready" and "unready"). The state types have some type parameters describing which class of state it's currently in. The step functions look vaguely like `step :: state a -> input b -> state c`, with various constraints on `a`, `b`, and `c`. When `state` and `input` are GADTs, you can enforce interesting invariants about the output state, given the input state and event. This all seems to work fine, and seems to be getting me in the direction I want to go. However, I'm running into a roadblock (possibly a bug?). Take the following minimal example: {-# LANGUAGE DataKinds, GADTs #-} module Lib () where data State2 s a where State2T :: s True -> State2 s True State2F :: s False -> State2 s False data OnlyTrue s where TrueState :: OnlyTrue True example :: State2 OnlyTrue s -> () example (State2T TrueState) = () -- Comment this and get non-exhaustive pattern warning -- Uncomment this and get "Inaccessible code" warning -- example (State2F TrueState) = () There is only one possible pattern on the LHS of the equation. If I don't put the (impossible) pattern, GHC gives me a warning about missing a pattern. If I do put the impossible pattern, GHC warns me that the pattern is impossible. Indeed! So why is GHC complaining about it in the first place? I'm using GHC 9.6.5. Around 7-8 years ago, I wrote some similar code, using typeclasses to constraint GADTs, and I remember being very impressed that the completeness checker was smart enough to figure out not to complain about impossible patterns (cf the paper "GADTs meet their match"). This seems like a simpler use case than what I recall doing in the past, but the completeness checker is giving me bad warnings here. Any ideas what might be going wrong? Thanks, Will

2 2

Re: [Haskell-cafe] Issue building with ghc-9.8.2 and packages unix, directory, filepath and os-string
by Daniel Trstenjak 01 Jun '24

01 Jun '24

> The problem is that `--allow-newer` tells cabal to ignore dependencies' upper bounds > completely. If those bounds turn out to be necessary in some cases, the solver will produce a > bad build plan. Looking at the compile error of the unix package, it looks like it gets the wrong combination of filepath and os-string packages, resulting in the missing symbols. This depends on the os-string flag, either the unix package gets the older filepath package containing these symbols or the newer one without them and additionally the os-string package now containing the symbols. This handling with the os-string flag feels wrong to me and therefore cabal can‘t resolve the right dependencies. The unix 2.8.5.0 package has an upper bound for filepath of <1.5, the one with the symbols, but unix 2.8.5.1 has the lower bound filepath >1.4.100, therefore supporting the filepath packages with and without the symbols. It seems if unix 2.8.5.1 would only support the filepath package without the symbols, by having the lower bound filepath >=1.5, then cabal could work out the right dependencies. Is there a reason why the unix 2.8.5.1 does it that way?

3 2

Issue building with ghc-9.8.2 and packages unix, directory, filepath and os-string
by Daniel Trstenjak 31 May '24

31 May '24

Hi, I'm trying to get my program to compile with ghc-9.8.2. Raising the upper bounds of my dependencies I'm running into a compile error for the unix-2.8.5.1 package: [15 of 53] Compiling System.Posix.Env.PosixString ( /home/dan/sources/unix-2.8.5.1/dist-newstyle/build/x86_64-linux/ghc-9.8.2/unix-2.8.5.1/build/System/Posix/Env/PosixString.hs, /home/dan/sources/unix-2.8.5.1/dist-newstyle/build/x86_64-linux/ghc-9.8.2/unix-2.8.5.1/build/System/Posix/Env/PosixString.o, /home/dan/sources/unix-2.8.5.1/dist-newstyle/build/x86_64-linux/ghc-9.8.2/unix-2.8.5.1/build/System/Posix/Env/PosixString.dyn_o ) System/Posix/Env/PosixString.hsc:45:1: error: [GHC-87110] Could not load module ‘System.OsString.Internal.Types’. It is a member of the hidden package ‘os-string-2.0.3’. Perhaps you need to add ‘os-string’ to the build-depends in your .cabal file. It is a member of the hidden package ‘filepath-1.4.200.1’. Perhaps you need to add ‘filepath’ to the build-depends in your .cabal file. Use -v to see a list of the files searched for. | 45 | import System.OsString.Internal.Types | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ System/Posix/Env/PosixString.hsc:47:1: error: [GHC-61948] Could not find module ‘System.OsString.Data.ByteString.Short’. Perhaps you meant System.OsString.Data.ByteString.Short (needs flag -package-id os-string-2.0.3) System.OsPath.Data.ByteString.Short (needs flag -package-id filepath-1.4.200.1) System.OsString.Data.ByteString.Short.Word16 (needs flag -package-id os-string-2.0.3) | 47 | import qualified "os-string" System.OsString.Data.ByteString.Short as B | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ System/Posix/PosixPath/FilePath.hsc:50:1: error: [GHC-61948] Could not find module ‘System.OsString.Data.ByteString.Short’. Perhaps you meant System.OsString.Data.ByteString.Short (needs flag -package-id os-string-2.0.3) System.OsPath.Data.ByteString.Short (needs flag -package-id filepath-1.4.200.1) System.OsString.Data.ByteString.Short.Word16 (needs flag -package-id os-string-2.0.3) | 50 | import "os-string" System.OsString.Data.ByteString.Short as BSS | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ System/Posix/PosixPath/FilePath.hsc:55:1: error: [GHC-87110] Could not load module ‘System.OsString.Internal.Types’. It is a member of the hidden package ‘os-string-2.0.3’. Perhaps you need to add ‘os-string’ to the build-depends in your .cabal file. It is a member of the hidden package ‘filepath-1.4.200.1’. Perhaps you need to add ‘filepath’ to the build-depends in your .cabal file. Use -v to see a list of the files searched for. | 55 | import System.OsString.Internal.Types (PosixString(..), pattern PS) | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ I can get rid of this compile error and a similar one for the directory package by setting the flag os-string in my cabal.project file: constraints: unix +os-string, directory +os-string Now I'm wondering what is the right way to handle this case? Thanks for any hints! Greetings, Daniel

4 7

[ANN] Darcs 2.18.3 release
by Ben Franksen 30 May '24

30 May '24

Hello Everyone On behalf of the Darcs team, I would like to (somewhat belatedly) announce the release of Darcs 2.18.3 [1]. This is a minor bug fix release. The main issue was that Darcs failed to work on Windows when built with ghc >= 9.6. The reason was a bug in some recent versions of the directory package's 'copyFile' procedure and we adapted the dependency bounds so to avoid those versions. See [2] for the full release notes. Cheers Ben [1] https://hackage.haskell.org/package/darcs-2.18.3 [2] https://hackage.haskell.org/package/darcs-2.18.3/changelog

1 0

Re: [Haskell-cafe] [ANNOUNCE] Ajla: a new purely functional programming language
by Mikulas Patocka 29 May '24

29 May '24

On Mon, 27 May 2024, Pierpaolo Bernardi wrote: > Hello, > > the language is interesting. > > Why don't you start a mailing list to keep interested people informed about it? > > Cheers That's a great idea. I created the mailing list at https://www.freelists.org/list/ajla Mikulas

1 0

FINAL CFP: Haskell Symposium 2024
by J. Garrett Morris 29 May '24

29 May '24

Friends, The Haskell Symposium submission deadline is less than a week away, the PC is eagerly standing by, the HotCRP instance is open (thanks Mati!),... the only thing missing is you! Hope to see you in Milan. /g ---- The ACM SIGPLAN Haskell Symposium 2024 will be co-located with the 2024 International Conference on Functional Programming (ICFP). 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. *New this year*, talk proposals need not be full-length, and should report work in progress relevant to Haskell language design, theory, tools, or applications. Talk proposals will be evaluated by the PC for novelty and relevance to the Haskell community, but are not expected to include finished results. Talk proposals will not be distributed to attendees, but authors of talk proposals may provide links to materials to be included on the program. 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. Like an experience report and a functional pearl, tutorials should make 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 (Talk Proposal, 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. Talk proposals, functional pearls, experience reports, tutorials and demo proposals should be labelled clearly as such. Lightweight Double-blind Reviewing Haskell Symposium 2024 will use a lightweight double-blind reviewing process. To facilitate this, submitted papers must adhere to two rules: - Author names and institutions must be omitted, and - 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 - *Talk proposals:* 6 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 good talk proposal might be two pages, and 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 - *Paper submission:* 3 June 2024 (Mon) - *Notification:* 5 July 2024 (Fri) - *Camera-ready Deadline:* 18 July 2024 (Thu) Deadlines are end of day Anywhere on Earth (UTC-12) <https://www.timeanddate.com/time/zones/aoe>. 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://haskell24.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.

1 0

Re: [Haskell-cafe] GHC release series adoption rates
by amindfv＠mailbox.org 29 May '24

29 May '24

On Tue, May 28, 2024 at 09:30:46PM +0100, Simon Peyton Jones wrote: > [...] In particular, it'd be great to have some telemetry. Telemetry is a complex > issue -- but we now have some very well-informed colleagues: the team at > Scarf. So maybe we'll get some basic data before long, which would be a > big step forward. (We'd expect to be transparent about that too of course!) Respectfully, "we'd expect to be transparent about that" already feels like a violated promise. I did not know until this email that Haskell.org had engaged a telemetry gateway using "zero-cookie tracking pixels" for "meticulous tracking of visitor patterns" to engage with their "previously anonymous audience"! (Quotes from https://about.scarf.sh/post/haskell-org-bridging-the-gap-between-language-i… and from the homepage and FAQ.) I'd expect the primary purpose of a language homepage, language asset distribution, etc. is to provide software to those who would use it. To use tarball distribution to "understand where in the funnel your open source users are," "transforming anonymous downloads, web traffic, and usage into company profiles and journeys," etc. feels like a deep scammy repurposing of our central resource (Haskell.org) for surveillance and marketing purposes. They explicitly focus on, for example, using IP addresses for "Identifying which companies are using a particular package." And as far as I can tell, this data is going to Scarf the (multimillion dollar, VC-funded) company too. This is bad. I want to reiterate my deep respect for the project, but jeez - this is not a good path to go down. Thanks, Tom

1 0

[ANNOUNCE] Ajla: a new purely functional programming language
by Mikulas Patocka 27 May '24

27 May '24

Hi I'd like to announce the release of Ajla - a new purely functional programming language that looks like traditional procedural languages. If you are interested, see https://www.ajla-lang.cz/ Mikulas

3 3

PLMW@ICFP'24: Call for Participation (travel funding application by June 21)
by Ningning Xie 24 May '24

24 May '24

ACM SIGPLAN Programming Languages Mentoring Workshop (PLMW) at ICFP 24, Milan, Italy Workshop: Monday, September 2, 2024 Website: https://icfp24.sigplan.org/home/PLMW-ICFP-2024 PLMW is a workshop co-located with ICFP 2024 (the International Conference on Functional Programming) in Milan, Italy, from September 2-7. The purpose of this mentoring workshop is to encourage graduate students and senior undergraduate students to pursue careers in programming language research. This workshop will bring together world leaders in programming languages research and teaching from academia and industry to help students imagine how they might contribute to our research community. Topics will range from the abstract (e.g., what is PL research and how does one become involved in it) to the concrete (e.g., how to navigate an academic conference, how to pick a research area) as well as technical talks on cutting-edge topics. We especially encourage women and underrepresented minority students, and people with disabilities to attend PLMW. This workshop is part of the activities surrounding ICFP, and takes place the day before the main conference. One goal of the workshop is to make the ICFP conference more accessible to newcomers. We hope that participants will stay through the entire conference. Note that ICFP and PLMW are planned to be largely in-person events. While we recognize that travel to conferences is not easy for everyone, we do hope you will be able to join us in person to get the most out of the conference and its community-building aspects. A number of sponsors have generously donated scholarship funds for qualified students to attend PLMW. These scholarships can cover expenses (airfare, hotel, and registration fees) for attendance at both the workshop and the ICFP conference. Students attending this year will get one year free student membership of SIGPLAN, unless they prefer to opt out during their application. The workshop registration is open to all. Students with alternative sources of funding are welcome as well. —-------------------------------------------------------------- APPLICATION FOR PLMW TRAVEL FUNDING For full consideration for scholarship funding, please apply at the link below by June 21, AoE. We will notify accepted attendees in a rolling fashion until all funding is committed. The application can be accessed at the following URL (Apply by June 21, 2024 AOE for full consideration!): https://forms.gle/vC6udnMWRvvAczPR6

1 0

CGO'25 - Call for Papers
by Luisa Cicolini 22 May '24

22 May '24

IEEE/ACM International Symposium on Code Generation and Optimization (CGO<https://2025.cgo.org/>) Co-located with PPoPP<https://conf.researchr.org/series/PPoPP>, HPCA<https://hpca-conf.org/2025/> and CC<https://conf.researchr.org/series/CC> Las Vegas, USA The International Symposium on Code Generation and Optimization (CGO’25) will be held in Las Vegas, USA. CGO is the premier venue to bring together researchers and practitioners working at the interface of hardware and software on a wide range of optimization and code generation techniques and related issues. The conference spans the spectrum from purely static to fully dynamic approaches, and from pure software-based methods to specific architectural features and support for code generation and optimization. ________________________________ CGO now uses two submissions per year. This follows the model established by other conferences in our field in recent years, such as ASPLOS and OOPSLA. Papers submitted to the first round can either be directly accepted, rejected, or invited to submit a revised version of the paper to the second round. For papers invited to submit a revised version, authors will be given a list of revisions that should be acted on to improve the paper. We will make every effort to ensure that the revised paper is reviewed by the same referees, who will assess whether the revisions are satisfactory. If so, the paper will be accepted. If a paper is rejected, the authors may still submit a revised version in a subsequent round, which will be treated as a new submission. ________________________________ First Submission Deadline * Paper Submission: May 30, 2024 * Author Rebuttal Period: July 9-11, 2024 * Paper Notification: July 22, 2024 Second Submission Deadline * Paper Submission: September 12, 2024 * Author Rebuttal Period: October 22 - 24, 2024 * Paper Notification: November 4, 2024 Contacts: * Hugh Leather - Meta – hleather(a)meta.com<mailto:hleather@meta.com> * P. (Saday) Sadayappan – University of Utah – saday(a)cs.utah.edu<mailto:saday@cs.utah.edu> ________________________________ Topics Original contributions are solicited on, but not limited to, the following topics: * Code Generation, Translation, Transformation, and Optimization for performance, energy, virtualization, portability, security, or reliability concerns, and architectural support * Efficient execution of dynamically typed and higher-level languages * Optimization and code generation for emerging programming models, platforms, domain-specific languages * Dynamic/static, profile-guided, feedback-directed, and machine learning-based optimization * Static, Dynamic, and Hybrid Analysis for performance, energy, memory locality, throughput or latency, security, reliability, or functional debugging * Program characterization methods * Profiling and instrumentation techniques; architectural support * Novel and efficient tools * Compiler design, practice and experience * Compiler abstraction and intermediate representations * Vertical integration of language features, representations, optimizations, and runtime support for parallelism * Solutions that involve cross-layer (HW/OS/VM/SW) design and integration * Deployed dynamic/static compiler and runtime systems for general purpose, embedded system and Cloud/HPC platforms * Parallelism, heterogeneity, and reconfigurable architectures * Optimizations for heterogeneous or specialized targets, GPUs, SoCs, CGRA and Quantum Computers * Compiler support for vectorization, thread extraction, task scheduling, speculation, transaction, memory management, data distribution and synchronization Standard research papers must be written in the ACM format<https://www.acm.org/publications/proceedings-template>, and may have up to 11 pages, references excluded. Please ensure that you and your co-authors obtain an ORCID ID, so you can complete the publishing process for your accepted paper. ACM has been involved in ORCID from the start and we have recently made a commitment to collect ORCID IDs from all of our published authors<https://authors.acm.org/author-resources/orcid-faqs>. We are committed to improve author discoverability, ensure proper attribution and contribute to ongoing community efforts around name normalization; your ORCID ID will help in these efforts. By submitting your article to an ACM Publication, you are hereby acknowledging that you and your co-authors are subject to all ACM Publications Policies<https://www.acm.org/publications/policies>, including ACM's new Publications Policy on Research Involving Human Participants and Subjects<https://www.acm.org/publications/policies/research-involving-human-particip…>. Alleged violations of this policy or any ACM Publications Policy will be investigated by ACM and may result in a full retraction of your paper, in addition to other potential penalties, as per ACM Publications Policy. ________________________________ Call for Tool and Practical Experience Papers CGO has a second category of papers called “Tools and Practical Experience”. Papers in this category must either give a clear account of a tool’s functionality or summarize a practical experience with realistic case studies. The successful evaluation of an artifact is mandatory for a Tool Paper. Therefore, authors of work conditionally accepted as Tool Papers must submit an artifact to the Artifact Evaluation Committee. The successful evaluation of the artifact is a requirement for final acceptance. Practical experience papers are encouraged, but not required, to submit an artifact to the Artifact Evaluation process. The selection criteria for papers in this category are: * Originality: Papers should present CGO-related technologies applied to real-world problems with scope or characteristics that set them apart from previous solutions. * Usability: The presented Tools or compilers should have broad usage or applicability. They are expected to assist in CGO-related research, or could be extended to investigate or demonstrate new technologies. If significant components are not yet implemented, the paper will not be considered. * Documentation: The tool or compiler should be presented on a web-site giving documentation and further information about the tool. * Benchmark Repository: A suite of benchmarks for testing should be provided. * Availability: The tool or compiler should be available for public use. * Foundations: Papers should incorporate the principles underpinning Code Generation and Optimization (CGO). However, a thorough discussion of theoretical foundations is not required; a summary of such should suffice. * Artifact Evaluation: The submitted artifact must be functional and support the claims made in the paper. Submission of an artifact is mandatory for papers presenting a tool. Tool and Practical Experience papers abide by the same limit of 11 pages in the ACM format<https://www.acm.org/publications/proceedings-template>, references excluded, and are not distinguished in the final proceedings. We encourage shorter submissions that give account of how scientific ideas have been incorporated and used in practice. ________________________________ Geographic Diversity and Inclusion Authors of papers accepted for CGO 2025 are encouraged to present their work in person. However, to foster the participation of students and professionals from everywhere, CGO 2025 will allow the remote presentation of papers, if their authors are unable to travel to the conference venue for reasons beyond their control (e.g. visa issues). Additionally, the conference organization will try to make attendance of CGO 2025 affordable for as many people as possible, with a specific focus on students from universities located in under-represented countries who are paper authors. ________________________________ Artifact Evaluation The Artifact Evaluation process is run by a separate committee whose task is to assess how the artifacts support the work described in the papers. This process contributes to improved reproducibility in research that should be a great concern to all of us. There is also some evidence that papers with a supporting artifact receive higher citations than papers without artifact evaluation. Authors of accepted papers at CGO have the option of submitting their artifacts for evaluation within two weeks of paper acceptance. To ease the organization of the AE committee, we kindly ask authors to indicate at the time they submit the paper, whether they are interested in submitting an artifact. Papers that go through the Artifact Evaluation process successfully will receive a seal of approval printed on the papers themselves. Additional information is available on the CGO AE web page. Authors of accepted papers are encouraged, but not required, to make these materials publicly available upon publication of the proceedings. ________________________________ Authors should carefully consider the difference in focus between the co-located conferences when deciding where to submit a paper. CGO will make the proceedings freely available via the IEEE Xplore platform during the period from two weeks before to two weeks after the conference. This option will facilitate easy access to the proceedings by conference attendees, and it will also enable the community at large to experience the excitement of learning about the latest developments being presented in the period surrounding the event itself. ________________________________ Distinguished Paper Awards Up to 10% of papers accepted at CGO 2025 will be designated as Distinguished Papers, following the ACM policy. This award is open to both regular and tool papers.

1 0

PLMW@PLDI 2024: Call for Lightning Talks on Research Group Openings
by Yao Li 21 May '24

21 May '24

Hi All. If you are attending PLDI this year, this might be of interest to you. We are experimenting with new ways of networking at PLMW@PLDI’24 through "Lightning talks on research group openings". If you have (or anticipate) an open position, either in academia or industry, full-time or part-time—you can now leverage PLMW to advertise that position. The definition of the opening is to be interpreted broadly. Towards this end, we would like to invite lightning talks describing the opportunities in your groups. At this point, we expect the talk to be anywhere between 5 to 10mins. Depending on the space, we may tighten the time to just 5mins closer to the program. Please fill this form <https://forms.gle/uHBQwzAmBR2GXLv29> by *June 5th* if you are interested. Note that the talks are in-person. The event is on *June 24, 2024*. You can check out https://pldi24.sigplan.org/track/PLMW-PLDI-2024 for more details on the PLMW program. Anitha Gollamudi Univ. of Massachusetts Lowell. https://sites.uml.edu/anitha-gollamudi/

1 0

Priorities for upcoming GHC releases
by Zubin Duggal 21 May '24

21 May '24

Hi all, We detail our plans for upcoming GHC releases in a new blog post: https://www.haskell.org/ghc/blog/20240521-ghc-release-priorities.html The summary is that we will prioritise work on the 9.10, 9.6 and master branches over work on the 9.8 branch for the coming few months due to time and resource constraints. This does not mean that we are dropping support for GHC 9.8, but that releases in this series might be made at a slower pace than usual. Cheers, Zubin.

1 0

POPL 2025: First Call for Papers (deadline: July 11 AOE)
by Ningning Xie 20 May '24

20 May '24

Dear all, Please find below the Call for Papers for the POPL 2025 conference. We would be grateful if you could help distribute this call among your networks. Many thanks! Ningning Xie POPL 2025 Publicity Chair PACMPL Issue POPL 2025 seeks contributions on all aspects of programming languages and programming systems, both theoretical and practical. Authors of papers published in PACMPL Issue POPL 2025 will be invited to present their work in the POPL conference in January 2025, which is sponsored by ACM SIGPLAN, in cooperation with ACM SIGACT and ACM SIGLOG. POPL 2025 Website: https://conf.researchr.org/home/POPL-2025 Call for Papers: https://conf.researchr.org/track/POPL-2025/POPL-2025-popl-research-papers#P… Double-Blind Review FAQ: https://conf.researchr.org/track/POPL-2025/POPL-2025-popl-research-papers#F… ### Organization Conference Location: Denver, Colorado, United States Conference Dates: January 19-25, 2025 General Chair: Steve Zdancewic, University of Pennsylvania Program Chair: Armando Solar-Lezama, MIT Program Committee: https://conf.researchr.org/committee/POPL-2025/POPL-2025-popl-research-pape… ### Important Dates All the times/deadlines below are Anywhere on Earth (AoE) in 2024. Submission deadline: July 11 ### Scope Principles of Programming Languages (POPL) is a forum for the discussion of all aspects of programming languages and programming systems. Both theoretical and experimental papers are welcome, on topics ranging from formal frameworks to experience reports. We seek submissions that make principled, enduring contributions to the theory, design, understanding, implementation, or application of programming languages. ### Evaluation Criteria The Review Committee will evaluate the technical contribution of each submission as well as its accessibility to both experts and the general POPL audience. All papers will be judged on significance, originality, relevance, correctness, and clarity. Each paper must explain its scientific contribution in both general and technical terms, identifying what has been accomplished, explaining why it is significant, and comparing it with previous work. Advice on writing technical papers can be found on the SIGPLAN author information page: https://www.sigplan.org/Resources/Author/. Deadlines and formatting requirements, detailed below, will be strictly enforced. ### Double-Blind Reviewing Process POPL 2025 will use a full double-blind reviewing process (similar to the one used for POPL 2023 and 2024 but different from the lightweight double-blind process used in previous years). This means that identities of authors will not be made visible to reviewers until after conditional-acceptance decisions have been made, and then only for the conditionally-accepted papers. The use of full double-blind reviewing has several consequences for authors. * **Submissions**: Authors must omit their names and institutions from their paper submissions. In addition, references to authors’ own prior work should be in the third person (e.g., not “We build on our previous work …” but rather “We build on the work of …”). * **Supplementary material**: Authors are permitted to provide supplementary material (e.g., detailed proofs, proof scripts, system implementations, or experimental data) along with their submission, which reviewers may (but are not required to) examine. This material may take the form of a single file, such as a PDF or a tarball. Authors must fully anonymize any supplementary material. * **Author response**: In responding to reviews, authors should not say anything that reveals their identity, since author identities will not be revealed to reviewers at that stage of the reviewing process. * **Dissemination of work under submission**: Authors are welcome to disseminate their ideas and post draft versions of their paper(s) on their personal website, institutional repository, or arXiv (reviewers will be asked to turn off arXiv notifications during the review period). But authors should not take steps that would almost certainly reveal their identities to members of the Program Committee, e.g., directly contacting PC members or publicizing the work on widely-visible social media or major mailing lists used by the community. The purpose of the above restrictions is to help the Program Committee and external reviewers come to a judgment about the paper without bias, not to make it impossible for them to discover the authors’ identities if they were to try. In particular, nothing should be done in the name of anonymity that weakens the quality of the submission. However, there are occasionally cases where adhering to the above restrictions is truly difficult or impossible for one reason or another. In such cases, the authors should contact the Program Chair to discuss the situation and how to handle it. The FAQ on Double-Blind Reviewing addresses many common scenarios and answers many common questions about this topic. But there remain many grey areas and trade-offs. If you have any doubts about how to interpret the double-blind rules or you encounter a complex case that is not clearly covered by the FAQ, please contact the Program Chair for guidance. ### Evaluation Process Like last year, POPL 2025 will use a double-blind reviewing process (instead of the lightweight double-blind process used in recent years). This means that identities of authors will not be visible to reviewers until after conditional-acceptance decisions have been made. For authors, the main change is that there is no option to upload non-anonymized supplementary material; only anonymized supplementary material may be submitted. POPL 2025 will have five Associate Chairs who will help the PC Chair monitor reviews, solicit external expert reviews for submissions when there is not enough expertise on the committee, and facilitate reviewer discussions. As in previous years, authors will have a multi-day period to respond to reviews, as indicated in the Important Dates table. Responses are optional. A response must be concise, addressing specific points raised in the reviews; in particular, it must not introduce new technical results. Reviewers will write a short reaction to these author responses. The Review Committee (RC) will discuss papers electronically, and will use synchronous virtual meetings to discuss any papers for which there is disagreement among reviewers, in some cases soliciting additional input from other experts in the committee. There is no formal External Review Committee, though experts outside the committee may be consulted for some papers. Reviews will be accompanied by a short summary of the reasons behind the committee’s decision with the goal of clarifying the reasons behind the decision. To conform with ACM requirements for journal publication, all POPL papers will be conditionally accepted; authors will be required to submit a short description of the changes made to the final version of the paper, including how the changes address any requirements imposed by the Review Committee. That the changes are sufficient will be confirmed by the original reviewers prior to acceptance to POPL. Authors of conditionally accepted papers must submit a satisfactory revision to the Review Committee by the requested deadline or risk rejection. For additional information about the reviewing process, see: [Principles of POPL](https://www.sigplan.org/Conferences/POPL/Principles/), a presentation of the underlying organizational and reviewing policies for POPL. For POPL 2025, policies specified in this Call for Papers supersede those in the Principles of POPL document. ### Submission Site Information The submission site is https://popl25.hotcrp.com. Authors can submit multiple times prior to the deadline. Only the last submission will be reviewed. There is no abstract deadline. The submission site requires entering author names and affiliations, relevant topics, and potential conflicts. Addition or removal of authors after the submission deadline will need to be approved by the Program Chair (as this kind of change potentially undermines the goal of eliminating conflicts during paper assignment). The submission deadline is 11:59PM July 11, 2024 anywhere on earth: https://en.wikipedia.org/wiki/Anywhere_on_Earth ### Conflicts of Interest For each submission, the authors must make sure that they properly declare all potential conflicts of interest for all of the authors of that submission. This includes marking PC conflicts as well as “Other Conflicts (external)”. A conflict caught late in the reviewing process leads to a voided review which may be infeasible to replace. Conflicts should be declared between an adviser and an advisee (e.g., Ph.D., post-doc; forever), between an author and a co-author (papers and proposals; for two years), between people at the same institution (branches of large companies or different locations of research institutes are considered to be the same institution; for two years after leaving an institution), between people with financial conflicts of interest, and between friends or relatives. Please do not declare spurious conflicts: such incorrect conflicts are especially harmful if the aim is to exclude potential reviewers, so spurious conflicts can be grounds for rejection. If you are unsure about a conflict, please consult the Program Chair. ### Submission Guidelines Prior to the paper submission deadline, authors should upload their full anonymized paper. Here are some key requirements concerning paper submissions: * Each paper should have no more than **25 pages of text, excluding bibliography**, using the PACMPL format (specifically, the `acmart` LaTeX class with `acmsmall` option). It is a single-column page layout with a 10 pt font, 12 pt line spacing, and wider margins than recent POPL page layouts. In this format, the main text block is 5.478 in (13.91 cm) wide and 7.884 in (20.03 cm) tall. Use of a different format (e.g., smaller fonts or a larger text block) is grounds for summary rejection. The PACMPL template for LaTeX can be found at the [SIGPLAN author information page]( https://www.sigplan.org/Resources/Author/) and further information about PACMPL submissions can be found on the [PACMPL author guidelines page]( https://dl.acm.org/journal/pacmpl/author-guidelines) PACMPL does not support submissions in Microsoft Word. * We strongly encourage use of the `review` and `screen` options in order to make submissions easier to review. * (**NEW this year**) Authors may choose which citation format they wish to use, which can be either author-year (the mandate for final versions in previous years) or numeric. * Submissions should be in PDF and printable on both US Letter and A4 paper. Papers may be resubmitted to the submission site multiple times up until the deadline, but the last version submitted before the deadline will be the version reviewed. * Submitted papers must adhere to the [SIGPLAN Republication Policy]( https://www.sigplan.org/Resources/Policies/Republication/) and the [ACM Policy on Plagiarism]( https://www.acm.org/publications/policies/plagiarism-overview) Concurrent paper submissions to other conferences, workshops, journals, or similar forums of publication are not allowed. * Authors are free to submit supplementary material along with their submissions, but it must be fully anonymized. * Authors must list all their conflicts of interest (both PC conflicts and external conflicts) in the HotCRP submission form. * Authors may include additional information in a field of the HotCRP submission form labeled "Confidential Comments for the Program Chair". This information need not be anonymized. It can be used to inform the Program Chair, for example, about sensitive issues concerning a conflict with a PC member or about supplementary material that cannot be anonymized. It is left to the discretion of the Program Chair what to do with this information. * If for some reason an author feels uncomfortable discussing a sensitive issue with the Program Chair (or communicating via the "Confidential Comments" field in HotCRP), they should feel free to get in touch instead with any of the Associate Chairs, with whom they can discuss the issue in confidence. * Submissions from PC members (except the Program Chair) are permitted and will not be handled any differently than other submissions. This is in accordance with a recent change in policy approved by the SIGPLAN Executive Committee: SIGPLAN conferences that use full double-blind review and whose PCs have at least 50 members need not hold PC submissions to a higher standard. ### Artifact Evaluation for Accepted Papers Authors of conditionally accepted papers will be invited to formally submit supporting materials to the Artifact Evaluation process. Artifact Evaluation is run by a separate committee whose task is to assess how the artifacts support the work described in the papers. Artifact submission is strongly encouraged but voluntary and will not influence the final decision regarding the papers. Papers that go through the Artifact Evaluation process successfully will receive a seal of approval printed on the papers themselves. Authors of accepted papers are encouraged to make these materials publicly available upon publication of the proceedings, by including them as “source materials” in the ACM Digital Library. ### Copyright, Publication, and Presentation As a Gold Open Access journal, PACMPL is committed to making peer-reviewed scientific research free of restrictions on both access and (re-)use. Authors are strongly encouraged to support libre open access by licensing their work with the [Creative Commons Attribution 4.0 International (CC BY) license](https://creativecommons.org/licenses/by/4.0/), which grants readers liberal (re-)use rights. Authors of accepted papers will be required to choose one of the following publication rights: * Author licenses the work with a [Creative Commons license]( https://creativecommons.org/) retains copyright, and (implicitly) grants ACM non-exclusive permission to publish (suggested choice). * Author retains copyright of the work and grants ACM a non-exclusive permission to publish license. * Author retains copyright of the work and grants ACM an exclusive permission to publish license. * Author transfers copyright of the work to ACM. These choices follow from ACM Copyright Policy and ACM Author Rights, corresponding to ACM's "author pays" option. While PACMPL may ask authors who have funding for open-access fees to voluntarily cover the article processing charge (currently, US$400), payment is not required for publication. PACMPL and SIGPLAN continue to explore the best models for funding open access, focusing on approaches that are sustainable in the long-term while reducing short-term risk. All papers will be archived by the ACM Digital Library. Authors will have the option of including supplementary material with their paper. The official publication date 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. Authors of accepted papers are required to give a short talk (roughly 25 minutes long) at the conference, according to the conference schedule. However, authors who cannot attend in person will be provided with some option for remote presentation, as well as some mechanism for remote interaction with conference participants. ### Distinguished Paper Awards At most 10% of the accepted papers of POPL 2025 will be designated as Distinguished Papers. This award highlights papers that the Review Committee thinks should be read by a broad audience due to their relevance, originality, significance, and clarity. The selection of the distinguished papers will be made based on the final version of the paper and through an additional review process.

1 0

tls transition from 1.9 to 2.0
by Ben Franksen 19 May '24

19 May '24

Hi everyone from 1.9.x to 2.0.x the tls package made a change to require EMS (extended main secret) by default. I must admit that I have no idea what this is about and I don't really care much. However, it turns out that for compatibility reasons I need to change it to the old behavior (which allowed but did not require it). So I wonder how to do that. The problem is that I am not using tls directly but only via http-conduit (we only need the http client side functionality and mostly for simple download of files). Any hints would be greatly appreciated. Cheers Ben -- I would rather have questions that cannot be answered, than answers that cannot be questioned. -- Richard Feynman

1 1

problems with trace
by George Colpitts 18 May '24

18 May '24

After I load the following into ghci and call main I expect to see "norm" in the output 3 times as I have called it 3 times but it only shows once. Why? traceBug.hs --------------- {-# OPTIONS_GHC -Wall #-} import Debug.Trace (trace) norm :: [Int] -> [Int] norm = trace ("norm") id main :: IO () main = do print $ norm [2] print $ norm [2] print $ norm [3] --------------------- ghci session % ghci traceBug.hs Loaded package environment from /Users/gcolpitts/.ghc/x86_64-darwin-9.8.2/environments/default GHCi, version 9.8.2: https://www.haskell.org/ghc/ :? for help [1 of 2] Compiling Main ( traceBug.hs, interpreted ) Ok, one module loaded. ghci> main norm [2] [2] [3] ghci>

4 5

cradle: a simpler process library
by Julian Arni 15 May '24

15 May '24

Hi all, We just released cradle, a library aimed at a being simpler and more intuitive subprocess library. More details in: - The announcement: https://garnix.io/blog/announcing-cradle - The hackage page: https://hackage.haskell.org/package/cradle-0.0.0.0/docs/Cradle.html Feedback welcome! Cheers, Julian

2 2

[ANN] Copilot 3.19.1
by Frank Dedden 14 May '24

14 May '24

Hi everyone! We are very excited to announce Copilot 3.19.1 [1,2]. Copilot is a stream-based EDSL in Haskell for writing and monitoring embedded C programs, with an emphasis on correctness and hard realtime requirements. Copilot is typically used as a high-level runtime verification framework, and supports temporal logic (LTL, PTLTL and MTL), clocks and voting algorithms. Copilot marked as NASA Class D open-source software, and is being used at NASA in drone test flights. Through the NASA tool Ogma [3] (also written in Haskell), Copilot also serves as a runtime monitoring backend for NASA's Core Flight System, Robot Operating System (ROS2), and FPrime (the software framework used in the Mars Helicopter). This release does not contain any API breaking changes, but consists of some improvements to the copilot-theorem package. Thanks to Ryan Scott (Galois Inc.) a problem related to the interface with the Kind 2 model checker is fixed. Additionally, improvements have been made to the documentation. As always, we're releasing exactly 2 months since the last release. Our next release is scheduled for July 7th, 2024. Current emphasis is on improving the codebase in terms of stability and test coverage, removing unnecessary dependencies, hiding internal definitions, and formatting the code to meet our new coding standards. Additionally, as an ongoing process, work is being done on making Copilot more accessible to people less familiar with Haskell. Users are encouraged to participate by opening issues and asking questions via our github repo [4]. Happy Haskelling! Frank Dedden [1] https://github.com/Copilot-Language/copilot/releases/tag/v3.19.1 [2] https://hackage.haskell.org/package/copilot [3] https://github.com/nasa/ogma [4] https://github.com/Copilot-Language/copilot

1 0

Preferred syntax for append
by Mark McConnell 14 May '24

14 May '24

We know that lists have map. Sometimes we want to take the higher perspective of Functor, replacing map with fmap, then replacing fmap with <$> . This post asks the corresponding question about append. The notation for append within List itself is ++ . Often we think of lists as Monads. Applicative generalizes Monad, and Alternative specializes Applicative. Alternative has <|> which behaves as ++ on List. I have been using <|> for this purpose. Recently, I have begun to read and enjoy "Effective Haskell". In Chapter 1, this book uses <> for append. Clearly they are thinking of List as a Semigroup. I'm curious about your thoughts on ++ versus <|> versus <> .

2 2

Re: [Haskell-cafe] Preferred syntax for append
by Olaf Klinke 13 May '24

13 May '24

> Concatenation with (<>) is more meaningful and holds better semantics > than (<|>), described as just "An associative binary operation". (<>) is also "just an associative binary operation", no more guarantees than (<|>). That said, for append (<>) should be preferred over (<|>) because one can then switch to more efficient append implementations just by changing the type signature, e.g. when switching from String to Text: The former is an Alternative, the latter ist not. (<|>) for list models non-deterministic choice, which can be useful in combinatorial problems. Olaf

1 0

GHC 9.10.1 is now available
by Ben Gamari 11 May '24

11 May '24

The GHC developers are very pleased to announce the release of GHC 9.10.1. Binary distributions, source distributions, and documentation are available at [downloads.haskell.org] and shortly via [GHCup]. GHC 9.10 brings a number of new features and improvements, including: * The introduction of the `GHC2024` language edition, building upon `GHC2021` with the addition of a number of widely-used extensions. * Partial implementation of the [GHC Proposal #281], allowing visible quantification to be used in the types of terms. * [Extension] of LinearTypes to allow linear `let` and `where` bindings * The implementation of the [exception backtrace proposal], allowing the annotation of exceptions with backtraces, as well as other user-defined context * Further improvements in the info table provenance mechanism, reducing code size to allow IPE information to be enabled more widely * Javascript FFI support in the WebAssembly backend * Improvements in the fragmentation characteristics of the low-latency non-moving garbage collector. * ... and many more A full accounting of changes can be found in the [release notes]. As always, GHC's release status, including planned future releases, can be found on the [GHC Wiki]. We would like to thank GitHub, IOG, the Zw3rk stake pool, Well-Typed, Tweag I/O, Serokell, Equinix, SimSpace, the Haskell Foundation, and other anonymous contributors whose on-going financial and in-kind support has facilitated GHC maintenance and release management over the years. Finally, this release would not have been possible without the hundreds of open-source contributors whose work comprise this release. As always, do give this release a try and open a [ticket] if you see anything amiss. [release notes]: https://downloads.haskell.org/ghc/9.10.1/docs/users_guide/9.10.1-notes.html [GHC Wiki]: https://gitlab.haskell.org/ghc/ghc/-/wikis/GHC-status [exception backtrace]: https://github.com/ghc-proposals/ghc-proposals/pull/330 [GHC Proposal #281]: https://github.com/ghc-proposals/ghc-proposals/pull/281 [linear let]: https://github.com/ghc-proposals/ghc-proposals/pull/624 [downloads.haskell.org] https://downloads.haskell.org/ghc/9.10.1 [ticket]: https://gitlab.haskell.org/ghc/ghc/-/issues/new [GHCup]: https://www.haskell.org/ghcup/

1 0

System.IO but not with Data.String?
by Hilco Wijbenga 11 May '24

11 May '24

Hi all, We have Text and ByteString as alternatives to String but as soon as you want to do anything IO related (read a file, get a directory's content, et cetera) it seems your only option is to use String. For an occasional IO action, this is obviously irrelevant but for a compiler, a build system, or anything else that does a lot of IO this seems like it would be(come) an issue. So I was wondering what would be involved in adding (portable) support for System.IO with an alternative to String (this alternative does not necessarily need to be Text or ByteString). I did a little bit of research into how GHC handles this and there appear to be several other String types in the GHC tree, including ByteString(?). How feasible is an alternative System.IO API? How tied to GHC would such an alternative need to be? To be clear, I am not looking to _replace_ System.IO but to _add_ an alternative API (and not a wrapper that maps to/from String). Please do not assume I necessarily know what I am talking about! Especially, when it comes to the "portable" part. :-) Cheers, Hilco

5 8

[ANN] Jacinda 3.0.1.0, a functional AWK standin
by Vanessa McHale 10 May '24

10 May '24

Hello all, I recently rewrote the backend to Jacinda, a functional riff on AWK: https://hackage.haskell.org/package/jacinda See the github https://github.com/vmchale/jacinda/?tab=readme-ov-file#installation and also the guide https://vmchale.github.io/jacinda/ Cheers, Vanessa McHale

1 0

[ANN] Cabal 3.12 released
by Francesco Ariis 08 May '24

08 May '24

Dear cafe, Cabal team is happy to announce the release of `Cabal` the library version `3.12.0.0` and the companion pre-release of `cabal-install` (the commandline tool; scroll down for more information). ## What is new? There are a number of new features in this release (`Cabal`) and pre-release (`cabal-install`), such as: - Add support for `asm`, `cmm`, and `js` sources in executable components. - Add `--haddock-output-dir` flag to `cabal haddock`. - Add `--semaphore` option to `./Setup build` interface. - Add `--promised-dependency` flag to `./Setup configure` interface. - Add the ability to `--ignore` specific checks to `cabal check`. - Add support for `GHC2024` language edition. - Add support for loading multiple components into one repl session (especially important for HLS users). - Add `cabal path` command. - Add support for authentication tokens for uploading to Hackage. - Allow more flags in the init section of config file. - Add `--semaphore` flag to enable interaction with GHC Job Server protocol. - Adds functionality for the `--offline` flag with the `build` command. - Improve solver rejections in brevity and accuracy. There is much more: for a detailed list of enhancements, changes, and bugfixes, please check the Cabal-3.12.0.0 changelog [1] (and the cabal-install 3.12.0.0-prerelease changelog [2]. [1] https://github.com/haskell/cabal/blob/master/release-notes/Cabal-3.12.0.0.md [2] https://github.com/haskell/cabal/blob/master/release-notes/WIP-cabal-instal… ## Authors and contributors Cabal is a collaborative effort; these people contributed with code to this release: aleeusgr Adam Gundry Andrea Bedini Andreas Abel Andreas Klebinger Arjun Kathuria Artem Pelenitsyn BasLaa Bas Laarakker Ben Gamari Bodigrim Brandon Chinn Brandon S. Allbery Bryan Richter Colton Clemmer Csaba Hruska cydparser Daniel Trstenjak David Binder David Christiansen Edwin Marshall Elodie Lander Erik de Castro Lopo Felix Yan Fendor Finley Francesco Ariis Francesco Gazzetta Fraser Tweedale Gershom Bazerman Hamish Mackenzie Hécate Moonlight Ikko Eltociear Ashimine Jana Chadt Javier Sagredo Jean-Paul Calderone Jens Petersen Jessica Hamilton John Paul Adrian Glaubitz Josh Meredith Julia Longtin Julian Ospald Kazuki Okamoto Kleidukos Kristen Kozak Krzysztof Gogolewski liamzee Liisi Kerik Lin Runze malteneuss Malte Neuss Marcin Szamotulski Matthew Pickering Mel Zuser Michael Peyton Jones Mike Pilgrem Mikolaj Konarski mixphix Oleg Grenrus Ondřej Šebek Patrick Augusto Patrick Dougherty Phil de Joux Pierre Le Marre Rebecca Turner Rodrigo Mesquita Ryan Scott Samuel Thibault Sander Sebastian Tee Sergey Vinokurov Shae Erisson sheaf Simon Hengel Siyuan Chen Sören Tempel Suganya Raju Sylvain Henry Taylor Fausak Teo Camarasu Tom Ellis Tom Smeding Torsten Schmits Tristan Cacqueray Troels Henriksen Wismill Yvan Sraka The release could not be done without the help of the manual QA team and devops people, we thank them both. Thanks also to the many users who provided bug reports and suggestions for improvements. A special mention to Hécate, who recently stepped down from Cabal release coordination and left the process in a better, more organised shape than what was before. ## How to get the `cabal-install` pre-release This release is a Cabal-the-library release, but if you want to test the new features of `cabal-install`, you can download the pre-release of the commandline tool via GHCup. Use one of the following commands, depending on your OS: ghcup --no-cache install cabal -u 'https://gitlab.haskell.org/haskell/cabal/-/jobs/1848320/artifacts/raw/out/c…' 3.12.0.0-prerelease ghcup --no-cache install cabal -u 'https://gitlab.haskell.org/haskell/cabal/-/jobs/1848326/artifacts/raw/out/c…' 3.12.0.0-prerelease ghcup --no-cache install cabal -u 'https://gitlab.haskell.org/haskell/cabal/-/jobs/1848327/artifacts/raw/out/c…' 3.12.0.0-prerelease or an analogous command for any other of the artifacts produced by the [pre-release pipeline](https://gitlab.haskell.org/haskell/cabal/-/pipelines/93759). ## How to help? Cabal is a complex piece of software running on many different machine. Two easy ways to help the development team producing quality releases are: - Join the manual QA team - Test nightly binary `cabal-install` snapshots and pre-releases (such as the 3.12.0.0 pre-release mentioned above) and report any problem you find. [3] https://discourse.haskell.org/t/manual-qa-for-cabal-install/6225

1 0

[Haskell] [ANNOUNCE] Haskell Language Server 2.8.0.0 released
by Zubin Duggal 08 May '24

08 May '24

The HLS team is pleased to announce the release of Haskell Language Server [2.8.0.0](https://github.com/haskell/haskell-language-server/releases/tag/2.…. Binaries for this release are available at [Index of /~hls/haskell-language-server-2.8.0.0/](https://downloads.haskell.org/~hls/haskell-language-server-2.8.0.0/). All of these tarballs have associated GPG signatures. The signature should be from `Zubin Duggal <zubin(a)well-typed.com>` (key ID [588764FBE22D19C4](https://keys.openpgp.org/search?q=588764FBE22D19C4)) The prebuilt binaries in this release support the following GHC versions: - 9.2.8 - 9.4.8 - 9.6.5 - 9.8.2 # Changelog - Bindists for GHC 9.6.5 - New hls-notes plugin (#4126, @jvanbruegge) - Floskell, hlint and stylish-haskell plugins enabled for GHC 9.8 - Improvements for hls-graph increasing robustness (#4087, @soulomoon) - Improvements to multi-component support (#4096, #4109, #4179, @wz1000, @fendor) Happy editing! - Zubin

1 0

Help with GHC.Generics -- How to get field selector name into value level?
by Compl Yue 07 May '24

07 May '24

Greetings! I’m stuck: ```hs -- | a named (with a selector) field instance (KnownSymbol sel, DbaStorable' f, f ~ K1 R c, DbaField c ft, Typeable c) => DbaStorable' (M1 S ('MetaSel ('Just sel) su ss ds) f) where -- _loadDbaField store bsp fno cno vin = M1 <$> _loadDbaField store fsp fno cno vin where fieldName = symbolVal (Proxy @sel) fieldPath = fieldName ++ "::" ++ dbaBasePath @c fsp = case bsp of "" -> fieldPath -- a field of a top level record _ -> bsp ++ "/" ++ fieldPath -- a field of a nested record _storeDbaField store bsp fno cno m@(M1 xr) = _storeDbaField store fsp fno cno xr where fieldName = selName m fieldPath = fieldName ++ "::" ++ dbaBasePath @c fsp = case bsp of "" -> fieldPath -- a field of a top level record _ -> bsp ++ "/" ++ fieldPath -- a field of a nested record ``` With the `selName` approach as in the `_storeDbaField ` above, it’s rejected as: ```log • Could not deduce (GHC.Generics.SingI su) arising from a use of ‘selName’ from the context: (KnownSymbol sel, DbaStorable' f, f ~ K1 R c, DbaField c ft, Typeable c) bound by the instance declaration at src/Frp/DbaStore/Internal.hs:(646,3)-(647,55) • In the expression: selName m In an equation for ‘fieldName’: fieldName = selName m In an equation for ‘_storeDbaField’: ``` But can I really evident `SingI` instance from my side? Which is unexpected from GHC.Generics... Otherwise with the `symbolVal` approach as in the `_loadDbaField ` above, there’s the complain against the ultimate use site: ```log • No instance for (GHC.TypeLits.KnownSymbol sel0) arising from a use of ‘storeDba’ • In a stmt of a 'do' block: storeDba rootDir series'data In the expression: do forM_ series'data print storeDba rootDir series'data sd <- loadDba @(Envelope2D Double) rootDir forM_ sd print ``` But I failed to prove `KnownSymbol sel` with all methods I can think of. Help please! With best regards, Compl

1 0

Contact to the maintainer of "finitary" package
by 宮里洸司 06 May '24

06 May '24

Hello everyone, I'd like to contact to the maintainer of "finitary" package [1] hosted at notabug.org [2]. The package is failing to build at Hackage, but a simple metadata fix [3] would solve the problem. As I couldn't find a way to contact the maintainer, (Sam Derbyshire, "sheaf" (sorry for missing titles)) I'm shouting public here. [1] https://hackage.haskell.org/package/finitary-2.1.1.1 [2] https://notabug.org/sheaf/finitary [3] https://notabug.org/viercc/finitary/commit/d6de614d0556b984e5bae97af01d94ae… -- /* Koji Miyazato <viercc(a)gmail.com> */

1 0

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

30 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

ANN: hledger 1.33
by Simon Michael 19 Apr '24

19 Apr '24

Hi all, I'm pleased to announce hledger 1.33! This release comes a bit later than usual, with help from contributors Jonathan Dowland, Ilja Kocken, Colin Dean, Dmitry Astapov, Vekhir, ShrykeWindgrace, Martijn van der Ven, Michael Rees, aragaer, and hamzashezad. Highlights: `close` enhancements, hledger-ui 'dark' theme, GHC 9.8 support, Apple ARM binaries, and the usual improvements and fixes. - https://github.com/simonmichael/hledger/releases/1.33 - https://hledger.org/relnotes.html#2024-04-18-hledger-133 <https://hledger.org/rel.html#2024-04-18-hledger-133> - https://hledger.org/install Wishing you peace and prosperity, -Simon What is hledger ? Fast, reliable, free, multicurrency, double-entry, plain text accounting software for unix, mac, windows, and the web; built around human-readable, version-controllable plain text files; inspired by and largely compatible with Ledger CLI; convertible to and from Beancount; written in Haskell for reliability and longevity. For help getting started or more info, see https://hledger.org and join our Matrix/IRC chat or mail list: https://hledger.org/support . Newcomers, experts, contributors, sponsors, feedback are welcome! For more about plain text accounting, see https://plaintextaccounting.org .

2 2

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

18 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 The problem is that both partiality checks and checks for incomplete pattern matches are undecidable in general, that is, without assistance the compiler can not infer partiality without risking infinite loops. Checks for incomplete pattern matches could be decidable, if it was not for view patterns, where you can hide arbitrary function applications (think unsafePerformIO) in. Currently GHC plays the safe card, see this thread: https://mail.haskell.org/pipermail/haskell-cafe/2024-January/136545.html With the help of special annotation such as Liquid Haskell you might be able to teach the compiler that your use of partial functions is fine. https://ucsd-progsys.github.io/liquidhaskell/ However, I second Henning in that a -Wx-partial warning hints at the necessity of a code re-factoring. Olaf

1 0

how to integrate a build in automake
by PICCA Frederic-Emmanuel 17 Apr '24

17 Apr '24

Hello, I am trying to build a program with the autotools. At the end I need to link this program with a few libraries with libtool. I wrote something like this but ghc (on Debian stable) does not deal with the default LDFLAGS of the distribution. So I need to generate only the .o files and do the final link by myself. Do you have examples of Makefile.am for an haskell program. Here the current autotool file which I need to modify in order to do the final link... https://repo.or.cz/hkl.git/blob/c2359440baeb38f5acbee91507d1aacf36f1b5bb:/b… thanks for your help. Frederic

1 0

Teach me to cooperate with IOException
by Folsk Pratima 16 Apr '24

16 Apr '24

Consider following C code. ``` int syscall_that_fails (int *errno_here) { *errno_here = 2; return -1; } ``` Now I write the haskell wrapper, first without any error checking. ``` module Complex where import Foreign import Foreign.C import Foreign.C.Types import Foreign.Storable foreign import ccall unsafe "complex.c syscall_that_fails" c_syscall_that_fails :: Ptr CInt -> IO CInt sysCall :: Int -> IO () sysCall i = allocaBytes (sizeOf (0 :: CInt)) $ \ptr -> c_syscall_that_fails ptr >> return () ``` Now I want to introduce some actual error checking, so at first I simply do ``` module Complex where import Control.Exception import Foreign import Foreign.C import Foreign.C.Types import Foreign.Storable foreign import ccall unsafe "complex.c syscall_that_fails" c_syscall_that_fails :: Ptr CInt -> IO CInt sysCall :: Int -> IO () sysCall i = allocaBytes (sizeOf (0 :: CInt)) $ \ptr -> do st <- c_syscall_that_fails ptr errno <- peekElemOff ptr 0 case st of (-1) -> throwIO $ userError $ "syscall: " ++ show errno _ -> return () ``` Now, I do not think it is a "user error", it is a real system call error that might or might not be already covered by System.IO.Error. In my case errno is 2, it is "No such file or directory", so it is covered by System.IO.Error and I may just use the library. But my C code may call whatever! What if System.IO does not cover that range of `errno`s? What if I want to distinguish between *my* errors and system errors? In such case I have to introduce my own way to do it. How do I do it? My first wild guess is to introduce my own exception, like this. ``` module Complex where import Control.Exception import Foreign import Foreign.C import Foreign.C.Types import Foreign.Storable data CException = LocalCallFailed { cexeption_errno :: Int , cexception_caller :: String } instance Show CException where show (LocalCallFailed errno caller) = caller ++ ": " ++ show errno instance Exception CException foreign import ccall unsafe "complex.c syscall_that_fails" c_syscall_that_fails :: Ptr CInt -> IO CInt sysCall :: Int -> IO () sysCall i = allocaBytes (sizeOf (0 :: CInt)) $ \ptr -> do st <- c_syscall_that_fails ptr errno <- peekElemOff ptr 0 case st of (-1) -> throwIO . LocalCallFailed (fromIntegral errno) $ "syscall" _ -> return () ``` And now I ask myself, what if allocaBytes fails? I looked on its code and it does ioError, thus, it will throwIO. If then I need to invoke sysCall, I can not use `try` anymore, because it is not determined what I will catch, LocalCallFailed or IOException. Next, what if I extend the `case of` clause to include some other errors, that are not related to system calls, but are my own? I try to recover, but can not come up with anything better than this... ``` module Complex where import Control.Exception import Foreign import Foreign.C import Foreign.C.Types import Foreign.Storable data CException = LocalCallFailed { cexeption_errno :: Int , cexception_caller :: String } | GenericIOException { genericioexception :: IOException } instance Show CException where show (LocalCallFailed errno caller) = caller ++ ": " ++ show errno show (GenericIOException e) = displayException e instance Exception CException ioExceptionToMe :: IO (Either IOException a) -> IO a ioExceptionToMe action = do e0 <- action case e0 of Left e -> throwIO . GenericIOException $ e Right a -> return a tryIO :: IO a -> IO a tryIO action = ioExceptionToMe $ try action foreign import ccall unsafe "complex.c syscall_that_fails" c_syscall_that_fails :: Ptr CInt -> IO CInt sysCall :: Int -> IO () sysCall i = tryIO $ allocaBytes (sizeOf (0 :: CInt)) $ \ptr -> do st <- c_syscall_that_fails ptr errno <- tryIO $ peekElemOff ptr 0 case st of (-1) -> throwIO . LocalCallFailed (fromIntegral errno) $ "syscall" _ -> return () ``` Now, this seems to be easily extendable. I can change LocalCallFailed to LocalSyscallFailed and then add something like LocalOwnFailed, which would account for some C error that is not attributed to system calls, and so on. But still, it seems very dumb, because of how I use tryIO. I have to use it on literally every haskell provided IO and... It just does not seem right.

2 1

[ANNOUNCE] GHC 9.6.5 is now available
by Zubin Duggal 16 Apr '24

16 Apr '24

The GHC developers are happy to announce the availability of GHC 9.6.5. Binary distributions, source distributions, and documentation are available on the [release page](https://www.haskell.org/ghc/download_ghc_9_6_5.html). GHC Blog Post: https://www.haskell.org/ghc/blog/20240416-ghc-9.6.5-released.html This release is primarily a bugfix release addressing some issues found in the 9.6 series. These include: * Bumping the bundled `process` library to 1.6.19.0 to avoid a potential [command injection vulnerability] on Windows for clients of this library. This isn't known to affect GHC itself, but allows users who depend on the installed version of the `process` to avoid the issue. * Fixing a bug resulting in the distributed ``hsc2hs`` wrapper using flags from the compiler build environment (#24050). * Disabling the `-fasm-shortcutting` optimisation with `-O2` as it is known to result in unsoundess and incorrect runtime results in some cases (#24507). * Ensuring we take ``LDFLAGS`` into account when configuring a linker (#24565). * Fixing a bug arising from incorrect parsing of paths containing spaces in the settings file (#24265). * And many more fixes A full accounting of changes can be found in the [release notes]. As some of the fixed issues do affect correctness users are encouraged to upgrade promptly. We would like to thank Microsoft Azure, GitHub, IOG, the Zw3rk stake pool, Well-Typed, Tweag I/O, Serokell, Equinix, SimSpace, Haskell Foundation, and other anonymous contributors whose on-going financial and in-kind support has facilitated GHC maintenance and release management over the years. Finally, this release would not have been possible without the hundreds of open-source contributors whose work comprise this release. As always, do give this release a try and open a [ticket][] if you see anything amiss. Enjoy! -Zubin [ticket]: https://gitlab.haskell.org/ghc/ghc/-/issues/new [release notes]: https://downloads.haskell.org/~ghc/9.6.5/docs/users_guide/9.6.5-notes.html [command injection vulnerability]: https://github.com/haskell/security-advisories/blob/main/advisories/hackage…

1 0

[ANNOUNCE] GHC 9.10.1-alpha3 is now available
by Ben Gamari 15 Apr '24

15 Apr '24

The GHC developers are very pleased to announce the availability of the third alpha release of GHC 9.10.1. Binary distributions, source distributions, and documentation are available at https://downloads.haskell.org/ghc/9.10.1-alpha3 We hope to have this release available via ghcup shortly. GHC 9.10 will bring a number of new features and improvements, including: * The introduction of the `GHC2024` language edition, building upon `GHC2021` with the addition of a number of widely-used extensions. * Partial implementation of the [GHC Proposal #281], allowing visible quantification to be used in the types of terms. * [Extension] of LinearTypes to allow linear `let` and `where` bindings ([linear let]) * The implementation of the [exception backtrace proposal], allowing the annotation of exceptions with backtraces, as well as other user-defined context * Further improvements in the info table provenance mechanism, reducing code size to allow IPE information to be enabled more widely * Javascript FFI support in the WebAssembly backend * Improvements in the fragmentation characteristics of the low-latency non-moving garbage collector. * ... and many more A full accounting of changes can be found in the [release notes]. As always, GHC's release status, including planned future releases, can be found on the GHC Wiki [status]. This alpha is the penultimate prerelease leading to 9.10.1. In two weeks we plan to publish a release candidate, followed, if all things go well, by the final release a week later. We would like to thank GitHub, IOG, the Zw3rk stake pool, Well-Typed, Tweag I/O, Serokell, Equinix, SimSpace, the Haskell Foundation, and other anonymous contributors whose on-going financial and in-kind support has facilitated GHC maintenance and release management over the years. Finally, this release would not have been possible without the hundreds of open-source contributors whose work comprise this release. As always, do give this release a try and open a [ticket] if you see anything amiss. Cheers, ~ Ben [release notes]: https://downloads.haskell.org/ghc/9.10.1-alpha3/docs/users_guide/9.10.1-not… [status]: https://gitlab.haskell.org/ghc/ghc/-/wikis/GHC-status [exception backtrace]: https://github.com/ghc-proposals/ghc-proposals/pull/330 [GHC Proposal #281]: https://github.com/ghc-proposals/ghc-proposals/pull/281 [linear let]: https://github.com/ghc-proposals/ghc-proposals/pull/624 [ticket]: https://gitlab.haskell.org/ghc/ghc/-/issues/new

1 0

runST $ unsafeIOToST $ ioWhatever
by Folsk Pratima 14 Apr '24

14 Apr '24

How wrong is it exactly? Did not get a reply on beginners(a)haskell.org import Control.Exception import Control.Monad.ST import Control.Monad.ST.Unsafe import Data.Word import Foreign.C.String import Foreign.C.String import Foreign.C.Types import Foreign.Marshal import Foreign.Ptr import Foreign.Storable foreign import ccall unsafe "strerror_r_portalbe.c strerror_r_portable" c_strerror_r :: CInt -> Ptr CChar -> CSize -> IO CInt memSet :: Ptr a -> Word8 -> Word32 -> IO (Ptr a) memSet ptr _ 0 = return ptr memSet ptr byte size = do let voidptr = castPtr ptr :: Ptr Word8 acts = map (\i -> pokeByteOff voidptr i byte) [0 .. fromIntegral (size - 1)] mapM_ id acts return ptr strError :: Int -> String strError errnum = runST $ unsafeIOToST ioString where baseSize :: CSize baseSize = 50 ioString = run baseSize run :: CSize -> IO String run size | size > 100000 = throwIO $ userError $ "!!! INTERNAL strError memory leak detected, " ++ "you can not recover !!!" | otherwise = do may <- tryIOString size case may of Just str -> return str Nothing -> run (size + baseSize) tryIOString :: CSize -> IO (Maybe String) tryIOString size = allocaBytes (fromIntegral size) $ \ptr -> do zeroptr <- memSet ptr 0 (fromIntegral size) st <- c_strerror_r (fromIntegral errnum) ptr size -- heuristic case st of 22 -> return . return $ "Unknown error " ++ show errnum 34 -> return Nothing _ -> peekCAString ptr >>= return . return main = mapM_ (putStrLn) $ map strError [1 .. 1000] The C file is #define _POSIX_C_SOURCE 200112L #include <string.h> int strerror_r (int, char *, size_t); int strerror_r_portable (int e, char *c, size_t s) { return strerror_r (e, c, s); } By default GHC picks up GNU version of strerror_r(), I want to pick up the default portable version. I do not know how to make GHC understand my desires.

2 3

Ambiguous occurence error, despite use of DuplicateRecordFields (worked with ghc 8.10.7, not with 9.6.4)
by Han Joosten 10 Apr '24

10 Apr '24

Hi all, I am currently migrating a Haskell project that uses ghc 8.10.7 to ghc 9.6.4. Using the new version, I get errors like ~~~.haskell Ambiguous occurrence ‘pos’ It could refer to either the field ‘pos’ of record ‘PClassify’, defined at /workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:1265:5 or the field ‘pos’ of record ‘PPurpose’, defined at /workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:1186:5 or the field ‘pos’ of record ‘P_ViewSegment’, defined at /workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:1129:5 or the field ‘pos’ of record ‘P_ViewD’, defined at /workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:1080:5 or the field ‘pos’ of record ‘P_IdentDf’, defined at /workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:1024:5 or the field ‘pos’ of record ‘P_BoxItem’, defined at /workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:981:9 or the field ‘pos’ of record ‘TemplateKeyValue’, defined at /workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:959:5 or the field ‘pos’ of record ‘BoxHeader’, defined at /workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:947:5 or the field ‘pos’ of record ‘P_SubIfc’, defined at /workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:934:9 or the field ‘pos’ of record ‘P_Interface’, defined at /workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:899:5 or the field ‘pos’ of record ‘P_Population’, defined at /workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:870:9 or the field ‘pos’ of record ‘P_Rule’, defined at /workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:806:5 or the field ‘pos’ of record ‘PairViewSegment’, defined at /workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:740:9 or the field ‘pos’ of record ‘P_NamedRel’, defined at /workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:591:5 or the field ‘pos’ of record ‘PAtomPair’, defined at /workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:467:5 or the field ‘pos’ of record ‘Pragma’, defined at /workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:415:5 or the field ‘pos’ of record ‘P_Relation’, defined at /workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:408:5 or the field ‘pos’ of record ‘Representation’, defined at /workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:339:5 or the field ‘pos’ of record ‘PConceptDef’, defined at /workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:268:5 or the field ‘pos’ of record ‘P_Pattern’, defined at /workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:209:5 or the field ‘pos’ of record ‘Role’, defined at /workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:185:5 or the field ‘pos’ of record ‘P_RoleRule’, defined at /workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:172:5 or the field ‘pos’ of record ‘P_Enforce’, defined at /workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:152:5 or the field ‘pos’ of record ‘MetaData’, defined at /workspaces/AmpersandNamespace/src/Ampersand/Core/ParseTree.hs:136:5 Previously, it was totally fine to have different data types each have a field with the same name, as long as you used `DuplicateRecordFields` I have searched the migration documentation but I couldn't find any clue on why this has been changed or how to deal with it. I probably missed it. Any help is mostly appreciated! Thanks for reading Cheers, Han Joosten

2 6

IFL 2024: First call for papers
by Mart Lubbers 09 Apr '24

09 Apr '24

======================================================================= IFL 2024 36rd Symposium on Implementation and Application of Functional Languages venue: Radboud University Nijmegen, The Netherlands August 26 - 28 2024 https://ifl24.cs.ru.nl ======================================================================= ### 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 2024 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 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 - virtual/abstract machine architectures - validation, verification of functional programs - tools and programming techniques ### Peer-review process Following IFL tradition, IFL 2024 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, a formal review process will take place, conducted by the program committee. Reviewing is single blind. There will be at least 3 reviews per paper. The reviewers have 6 weeks to write their reviews. For the camera-ready version the authors can make minor revisions which are accepted without further reviewing. ### Important dates Submission deadline of draft papers August 4th, 2024 Notification of acceptance for presentation August 6th, 2024 Early registration deadline August 11th, 2024 Late registration deadline August 21th, 2024 IFL symposium August 26-28, 2024 Submission of papers for proceedings December 1st, 2024 Notification of acceptance February 2nd, 2025 Camera-ready version March 2nd, 2025 ### 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 ### 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 PC Chairs: Mart Lubbers Radboud University, The Netherlands Local Chairs: Peter Achten Radboud University, The Netherlands Sven-Bodo Scholz, Radboud University, The Netherlands ### Program committee: t.b.d. ### Venue IFL 2024 will be held physically in Nijmegen, the Netherlands. See the website for more information. https://ifl24.cs.ru.nl (under construction) ### Acknowledgments This call-for-papers is an adaptation and evolution of content from previous instances of IFL. We are grateful to prior organisers for their work, which is reused here.

1 0

Agda Implementors' Meeting XXXVIII: Call for talks and participation
by mukesh tiwari 08 Apr '24

08 Apr '24

Dear all, The thirty-eighth Agda Implementors' Meeting will take place in Swansea, Wales, UK from Monday 13 to Saturday 18 May 2024. Wiki link for more details: https://wiki.portal.chalmers.se/ <https://wiki.portal.chalmers.se/agda/Main/AIMXXXVIII>agda <https://wiki.portal.chalmers.se/agda/Main/AIMXXXVIII>/Main/AIMXXXVIII <https://wiki.portal.chalmers.se/agda/Main/AIMXXXVIII> The meeting aims to bring together people not only developing but also using Agda or even those who are simply interested in it. We will have talks on the implementation details of Agda in the morning and code sprints in the afternoon. You can still submit your proposal for a talk or discussion! There's a (soft) deadline for registration on 14 April 2024 Registration instructions: https://wiki.portal.chalmers.se/ <https://wiki.portal.chalmers.se/agda/Main/AIMXXXVIII#Registration>agda <https://wiki.portal.chalmers.se/agda/Main/AIMXXXVIII#Registration> /Main/AIMXXXVIII#Registration <https://wiki.portal.chalmers.se/agda/Main/AIMXXXVIII#Registration> Best wishes, Anton Setzer ----------------------------------------------------------------------------- Dr Anton Setzer Darllenydd / Reader Ystafell / Room 403 Adran Gyfrifiadureg / Dept. of Computer Science Y Ffowndri Gyfrifiadurol / Computational Foundry Coleg Gwyddoniaeth / College of Science Prifysgol Abertawe/ Swansea University Campws y Bae/ Bay Campus Abertawe / Swansea SA1 8EN DU / UK Rhowch wybod i ni os hoffech dderbyn eich gohebiaeth yn Gymraeg. / Let us know if you would like to receive correspondence in Welsh. Rydym yn croesawu gohebiaeth yn Gymraeg neu yn Saesneg. / We welcome correspondence in Welsh or English. Ni fydd gohebu yn Gymraeg yn arwain at oedi./ Corresponding in Welsh will not lead to a delay.

1 0

ICFP Programming Contest 2024
by ICFP Contest 2024 07 Apr '24

07 Apr '24

Dear Haskell community, The ICFP programming contest 2024 is is held from Friday 28 June 2024 at 12:00 UTC to Monday 1 July 2024 at 12:00 UTC. There will be a lightning division, ending on Saturday 29 June 2024 at 12:00 UTC. This is the 27th instance of the annual programming contest series sponsored by the ACM SIGPLAN International Conference on Functional Programming. This is an open online programming contest. Anybody may participate except for the contest organisers. No advance registration or entry fee is required. Contestants are free to organize themselves into teams of any size. Any programming language(s) on any platform(s) may be used. As a member of this community, you are all invited to participate. For more information and contact details, see https://icfpcontest2024.github.io/ We hope to see many of you on the scoreboard the end of June! Functional greetings, The ICFP Contest 2024 organising committee

1 0

PL/Haskell?
by Matti Nykänen 04 Apr '24

04 Apr '24

It seems to be possible to invoke Haskell within PostgreSQL queries, see: <https://www.postgresql.org/about/news/plhaskell-v20-2597/> (1) Is it popular in the Haskell community? Or is it a proof-of-concept project to show that it can be done? (2) Does it have some easy-to-install packaging? All my initial attempts to follow the online installation instructions have resulted in aggravated lower back pain... -- Matti Nykänen

1 0