- Haskell-Cafe - Haskell.org

Re: [Haskell-cafe] CFP for PEPM 2023 (Deadline extended)
by Edwin Brady 14 Oct '22

14 Oct '22

Apologies, it's Tuesday 18th AoE (next week), not Tuesday 13th. Thanks to those who pointed out the error and sorry for the extra noise. From: Edwin Brady <ecb10(a)st-andrews.ac.uk> Dear all, (With apologies for any duplicate copies). Please see the CFP for PEPM 203 below. We have received some requests for extensions, and extended the deadline to next Tuesday. Note that short papers, including tool demos, works in progress and extended abstracts, are welcome too! Edwin and Jens -- CALL FOR PAPERS -- ACM SIGPLAN Workshop on PARTIAL EVALUATION AND PROGRAM MANIPULATION (PEPM) 2023 =============================================================================== * Website : https://popl23.sigplan.org/home/pepm-2023 * Time : 16th--17th January 2023 * Place : Boston, Massachusetts, United States (co-located with POPL 2023) The ACM SIGPLAN Workshop on Partial Evaluation and Program Manipulation (PEPM) has a history going back to 1991 and has been co-located with POPL every year since 2006. It originated with the discoveries of useful automated techniques for evaluating programs with only partial input. Over the years, the scope of PEPM has expanded to include a variety of research areas centred around the theme of semantics-based program manipulation — the systematic exploitation of treating programs not only as subjects to black-box execution but also as data structures that can be generated, analysed, and transformed while establishing or maintaining important semantic properties. Scope ----- In addition to the traditional PEPM topics (see below), PEPM 2023 welcomes submissions in new domains, in particular: * Semantics based and machine-learning based program synthesis and program optimisation. * Modelling, analysis, and transformation techniques for distributed and concurrent protocols and programs, such as session types, linear types, and contract specifications. More generally, topics of interest for PEPM 2023 include, but are not limited to: * Program and model manipulation techniques such as: supercompilation, partial evaluation, fusion, on-the-fly program adaptation, active libraries, program inversion, slicing, symbolic execution, refactoring, decompilation, and obfuscation. * Techniques that treat programs/models as data objects including metaprogramming, generative programming, embedded domain-specific languages, program synthesis by sketching and inductive programming, staged computation, and model-driven program generation and transformation. * Program analysis techniques that are used to drive program/model manipulation such as: abstract interpretation, termination checking, binding-time analysis, constraint solving, type systems, automated testing and test case generation. * Application of the above techniques including case studies of program manipulation in real-world (industrial, open-source) projects and software development processes, descriptions of robust tools capable of effectively handling realistic applications, benchmarking. Examples of application domains include legacy program understanding and transformation, DSL implementations, visual languages and end-user programming, scientific computing, middleware frameworks and infrastructure needed for distributed and web-based applications, embedded and resource-limited computation, and security. This list of categories is not exhaustive, and we encourage submissions describing new theories and applications related to semantics-based program manipulation in general. If you have a question as to whether a potential submission is within the scope of the workshop, please contact the programme co-chairs, Edwin Brady (ecb10(a)st-andrews.ac.uk<mailto:ecb10@st-andrews.ac.uk>) and Jens Palsberg (palsberg(a)ucla.edu<mailto:palsberg@ucla.edu>). Submission categories and guidelines ------------------------------------ Two kinds of submissions will be accepted: * Regular Research Papers should describe new results, and will be judged on originality, correctness, significance, and clarity. Regular research papers must not exceed 12 pages. * Short Papers may include tool demonstrations and presentations of exciting if not fully polished research, and of interesting academic, industrial, and open-source applications that are new or unfamiliar. Short papers must not exceed 6 pages. References and appendices are not included in page limits. Appendices may not be read by reviewers. Both kinds of submissions should be typeset using the two-column ‘sigplan’ sub-format of the new ‘acmart’ format available at: http://sigplan.org/Resources/Author/ and submitted electronically via HotCRP: https://pepm23.hotcrp.com/ Reviewing will be single-blind. Submissions are welcome from PC members (except the two co-chairs). Accepted regular research papers will appear in formal proceedings published by ACM, and be included in the ACM Digital Library. Accepted short papers do not constitute formal publications and will not appear in the proceedings. At least one author of each accepted contribution must attend the workshop (physically or virtually) and present the work. In the case of tool demonstration papers, a live demonstration of the described tool is expected. Important dates --------------- * Paper submission deadline (EXTENDED): **Tuesday 13th October 2022 (AoE)** * Author notification (EXTENDED) : **Tuesday 15th November 2022 (AoE)** * Workshop : **Monday 16th January 2023 to Tuesday 17th January 2023** Best paper award ---------------- PEPM 2023 continues the tradition of a Best Paper award. The winner will be announced at the workshop. Programme committee ------------------- * Chairs: Edwin Brady (University of St Andrews, UK) Jens Palsberg (University of California Los Angeles, USA) * Nada Amin Harvard (USA) * Adam Barwell (Imperial College London, UK) * Nicolas Biri (Input Output Global) * David Castro-Perez (University of Kent at Canterbury, UK) * Cristina David (University of Bristol, UK) * Atsushi Igarashi (Kyoto University, Japan) * Yukiyoshi Kameyama (University of Tsukuba, Japan) * Geoffrey Mainland (Drexel University, USA) * Hila Peleg (Technion Israel Institute of Technology, Israel) * Casper Bach Poulsen (Delft University of Technology, Netherlands) * Sukyoung Ryu (KAIST, Korea) * Sven-Bodo Scholz (Radboud University Nijmegen, Netherlands) * Ilya Sergey (National University of Singapore, Singapore) * Satnam Singh (Groq Inc, USA) * Elena Zucca (University of Genova, Italy)

1 0

CFP for PEPM 2023 (Deadline extended)
by Edwin Brady 14 Oct '22

14 Oct '22

Dear all, (With apologies for any duplicate copies). Please see the CFP for PEPM 203 below. We have received some requests for extensions, and extended the deadline to next Tuesday. Note that short papers, including tool demos, works in progress and extended abstracts, are welcome too! Edwin and Jens -- CALL FOR PAPERS -- ACM SIGPLAN Workshop on PARTIAL EVALUATION AND PROGRAM MANIPULATION (PEPM) 2023 =============================================================================== * Website : https://popl23.sigplan.org/home/pepm-2023 * Time : 16th--17th January 2023 * Place : Boston, Massachusetts, United States (co-located with POPL 2023) The ACM SIGPLAN Workshop on Partial Evaluation and Program Manipulation (PEPM) has a history going back to 1991 and has been co-located with POPL every year since 2006. It originated with the discoveries of useful automated techniques for evaluating programs with only partial input. Over the years, the scope of PEPM has expanded to include a variety of research areas centred around the theme of semantics-based program manipulation — the systematic exploitation of treating programs not only as subjects to black-box execution but also as data structures that can be generated, analysed, and transformed while establishing or maintaining important semantic properties. Scope ----- In addition to the traditional PEPM topics (see below), PEPM 2023 welcomes submissions in new domains, in particular: * Semantics based and machine-learning based program synthesis and program optimisation. * Modelling, analysis, and transformation techniques for distributed and concurrent protocols and programs, such as session types, linear types, and contract specifications. More generally, topics of interest for PEPM 2023 include, but are not limited to: * Program and model manipulation techniques such as: supercompilation, partial evaluation, fusion, on-the-fly program adaptation, active libraries, program inversion, slicing, symbolic execution, refactoring, decompilation, and obfuscation. * Techniques that treat programs/models as data objects including metaprogramming, generative programming, embedded domain-specific languages, program synthesis by sketching and inductive programming, staged computation, and model-driven program generation and transformation. * Program analysis techniques that are used to drive program/model manipulation such as: abstract interpretation, termination checking, binding-time analysis, constraint solving, type systems, automated testing and test case generation. * Application of the above techniques including case studies of program manipulation in real-world (industrial, open-source) projects and software development processes, descriptions of robust tools capable of effectively handling realistic applications, benchmarking. Examples of application domains include legacy program understanding and transformation, DSL implementations, visual languages and end-user programming, scientific computing, middleware frameworks and infrastructure needed for distributed and web-based applications, embedded and resource-limited computation, and security. This list of categories is not exhaustive, and we encourage submissions describing new theories and applications related to semantics-based program manipulation in general. If you have a question as to whether a potential submission is within the scope of the workshop, please contact the programme co-chairs, Edwin Brady (ecb10(a)st-andrews.ac.uk) and Jens Palsberg (palsberg(a)ucla.edu) Submission categories and guidelines ------------------------------------ Two kinds of submissions will be accepted: * Regular Research Papers should describe new results, and will be judged on originality, correctness, significance, and clarity. Regular research papers must not exceed 12 pages. * Short Papers may include tool demonstrations and presentations of exciting if not fully polished research, and of interesting academic, industrial, and open-source applications that are new or unfamiliar. Short papers must not exceed 6 pages. References and appendices are not included in page limits. Appendices may not be read by reviewers. Both kinds of submissions should be typeset using the two-column ‘sigplan’ sub-format of the new ‘acmart’ format available at: http://sigplan.org/Resources/Author/ and submitted electronically via HotCRP: https://pepm23.hotcrp.com/ Reviewing will be single-blind. Submissions are welcome from PC members (except the two co-chairs). Accepted regular research papers will appear in formal proceedings published by ACM, and be included in the ACM Digital Library. Accepted short papers do not constitute formal publications and will not appear in the proceedings. At least one author of each accepted contribution must attend the workshop (physically or virtually) and present the work. In the case of tool demonstration papers, a live demonstration of the described tool is expected. Important dates --------------- * Paper submission deadline (EXTENDED): **Tuesday 13th October 2022 (AoE)** * Author notification (EXTENDED) : **Tuesday 15th November 2022 (AoE)** * Workshop : **Monday 16th January 2023 to Tuesday 17th January 2023** Best paper award ---------------- PEPM 2023 continues the tradition of a Best Paper award. The winner will be announced at the workshop. Programme committee ------------------- * Chairs: Edwin Brady (University of St Andrews, UK) Jens Palsberg (University of California Los Angeles, USA) * Nada Amin Harvard (USA) * Adam Barwell (Imperial College London, UK) * Nicolas Biri (Input Output Global) * David Castro-Perez (University of Kent at Canterbury, UK) * Cristina David (University of Bristol, UK) * Atsushi Igarashi (Kyoto University, Japan) * Yukiyoshi Kameyama (University of Tsukuba, Japan) * Geoffrey Mainland (Drexel University, USA) * Hila Peleg (Technion Israel Institute of Technology, Israel) * Casper Bach Poulsen (Delft University of Technology, Netherlands) * Sukyoung Ryu (KAIST, Korea) * Sven-Bodo Scholz (Radboud University Nijmegen, Netherlands) * Ilya Sergey (National University of Singapore, Singapore) * Satnam Singh (Groq Inc, USA) * Elena Zucca (University of Genova, Italy)

1 0

SRC@POPL 2023 Call for Submissions
by Jeehoon Kang 14 Oct '22

14 Oct '22

(Apologies if you receive multiple copies of this message) -------------------------------------------------------------------------- SRC@POPL 2023 Call for Submissions ACM Student Research Competition https://popl23.sigplan.org/track/POPL-2023-student-research-competition Location: Boston, Massachusetts, USA SRC Posters: Jan 18, 2023 (tentative) SRC Presentation: Jan 20, 2023 (tentative) -------------------------------------------------------------------------- Important Dates Abstract Submission: Fri 11 Nov 2022 Notification of (Conditional) Acceptance: Fri 2 Dec 2022 Re-Submission for Conditionally Accepted Abstracts: Wed 7 Dec 2022 Notification of Final Acceptance: Fri 9 Dec 2022 -------------------------------------------------------------------------- Overview POPL 2023 will host an ACM Student Research Competition, where undergraduate and graduate students can present their original research before a panel of judges and conference attendees. This year’s competition will consist of three rounds: • Round 1, Extended abstract: All students are encouraged to submit an extended abstract outlining their research. The submission should be up to three pages using “\documentclass[acmsmall,nonacm]{acmart}”. • Round 2, Poster at POPL: Based on the abstracts, a panel of judges will select the most promising entrants to participate in a poster session at POPL. In the poster session, students will be able to interact with POPL attendees and judges. After the poster session, three finalists in each category (graduate/undergraduate) will be selected to advance to the next round. • Round 3, Oral presentation at POPL: The last round will consist of a short oral live presentation at POPL to compete for the final awards in each category. This round will also select an overall winner who will advance to the ACM SRC Grand Finals. -------------------------------------------------------------------------- Call for Submission POPL invites students to participate in the Student Research Competition in order to present their research and get feedback from prominent members of the programming language research community. Please submit your extended abstracts through HotCRP: https://popl23src.hotcrp.com Submissions must be original research that is not already published at POPL 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. The extended abstract should be up to three pages using ‘\documentclass[acmsmall,nonacm]{acmart}’. Reference lists do not count towards the three-page limit. You may write appendices after the three-page limit, but please be noted that the committee is not required to read them. This year, we will have two review cycles. For each submission, one of the following decisions will be made: • Accept: abstracts that proceed to the next round unconditionally. • Conditional Accept: abstracts that receive revision suggestions from the PC members. Authors will have 5 days to revise the abstract accordingly and then resubmit. The revised abstracts will then be re-evaluated, and either accepted or rejected. • Reject: abstracts that will not proceed to the next round. -------------------------------------------------------------------------- Program Committee Jeehoon Kang, KAIST Danfeng Zhang, Pennsylvania State University Youyou Cong, Tokyo Institute of Technology Zeyu Ding, Binghamton University, USA Andrew K. Hirsch, MPI-SWS Yoonseung Kim, Yale University Abhinav Verma, Pennsylvania State University Yuepeng Wang, Simon Fraser University

1 0

Ph.D. positions at Portland State University
by Yao Li 12 Oct '22

12 Oct '22

Dear All, I am looking for Ph.D students (starting Fall 2023) who are interested in programming languages, formal verification, and/or interactive theorem proving to join my new group at Portland State University. I am a new assistant professor at Portland State University. My research aims to (1) advance the state of the art of verification on real-world software and (2) make verification easier to use from a programming languages perspective. You can find more information about me on my webpage: https://lastland.github.io/ Please feel free to drop me an email if you are interested or if you have any questions about my research, my group, or Portland State University. I'd appreciate it if you can help spread the word to whoever might be interested. Cheers, Yao Li, Ph.D., (He/Him) Assistant Professor, Computer Science Department, Portland State University

1 0

LAST CALL: Agda Implementors' Meeting XXXI - Edinburgh, 10-16 November 2022
by Orestis Melkonian 10 Oct '22

10 Oct '22

--------------------------------------------------------------- Agda Implementors' Meeting XXXI *Last call* for participation http://wiki.portal.chalmers.se/agda/pmwiki.php?n=Main.AIMXXXI --------------------------------------------------------------- The 31st Agda Implementors' Meeting will take place in Edinburgh, Scotland from Thursday 10 November 2022 to Wednesday 16 November 2022. Note that AIMXXXI was initially planned for 2019 but got postponed due to COVID-19, whilst we had several online meetings XXXII-XXXV. The meeting will consist of: * Presentations concerning theory, implementation, and use cases of Agda and other Agda-like languages. * Discussions around issues related to the Agda language. * Plenty of time to work in, on, under or around Agda, in collaboration with other participants. Unfortunately, the EuroProofNet day we initially planned has been cancelled. *Registration deadline (extended): October 21st* To register for AIM XXXI, please fill out the form below and send it to Orestis Melkonian by email <orestis.melkonian(a)ed.ac.uk>, or simply edit the AIMXXI wiki page yourself. > --------------------------------------------------------------- > Registration form for Agda Implementors' Meeting XXXI > > Name: > > Title and optionally abstract (if you want to give a talk or lead a discussion): > > Suggestions for code sprints (optional): > > Dietary restrictions: > > Additional comments: > > --------------------------------------------------------------- More information is available at http://wiki.portal.chalmers.se/agda/pmwiki.php?n=Main.AIMXXXI Please spread the word about this meeting. Best regards, Orestis

1 0

Request for Nominations to the GHC Steering Committee
by Joachim Breitner 06 Oct '22

06 Oct '22

Dear Haskell community, the GHC Steering committee is seeking nominations for one or more new members. The committee scrutinizes, nitpicks, improves, weighs and eventually accepts or rejects proposals that extend or change the language supported by GHC and other (public-facing) aspects of GHC. Our processes are described at https://github.com/ghc-proposals/ghc-proposals which is also the GitHub repository where proposals are proposed. In particular, please have a look at the bylaws at https://github.com/ghc-proposals/ghc-proposals/blob/master/committee.rst We are looking for a member who has the ability * to understand such language extension proposals, * to find holes and missing corner cases in the specifications, * foresee the interaction with other language features and specifications, * comment constructively and improve the proposals, * judge the cost/benefit ratio and * finally come to a justifiable conclusion. We look for committee members who have some of these properties: * have substantial experience in writing Haskell applications or libraries, which they can use to inform judgements about the utility or otherwise of proposed features, * have made active contributions to the Haskell community, for some time, * have expertise in language design and implementation, in either Haskell or related languages, which they can share with us. There is no shortage of people who are eager to get fancy new features into the language, both in the committee and the wider community. But each new feature imposes a cost, to implement, to maintain in perpetuity in GHC's code base, to learn, and to deal with its unexpected interaction with other features. We need to strike a balance, one that encourages innovation (as GHC always has) while still making Haskell attractive for real-world production use and for teaching. We therefore seek a balance of background, expertise, and views on the committee. Membership of the committee gives you the chance to influence the future direction of Haskell, and to serve the Haskell community. The committee’s work requires a small, but non-trivial amount of time, especially when you are assigned a proposal for shepherding. We estimate the workload to be around 2 hours per week, and our process works best if members usually respond to technical emails within 1-2 weeks (within days is even better). Please keep that in mind if your email inbox is already overflowing. To nominate yourself, please send an email to me (as the committee secretary) at mail(a)joachim-breitner.de until February 11th. I will distribute the nominations among the committee, and we will keep the nominations and our deliberations private. On behalf of the committee, Joachim Breitner -- Joachim Breitner mail(a)joachim-breitner.de http://www.joachim-breitner.de/

1 1

Help test XDG support in cabal-install
by Troels Henriksen 06 Oct '22

06 Oct '22

Cabal, or more precisely cabal-install which is mostly known to Haskellers as the cabal command line program, recently merged a pull request that makes cabal support the XDG Basedir Specification. Previously, cabal would put all of its files in the ~/.cabal directory. Now the files are spread over multiple directories: * $XDG_CONFIG_HOME/cabal for the main configuration file. On Unix, this defaults to ~/.config/cabal. * $XDG_CACHE_HOME/cabal for downloaded packages and script executables. Defaults to ~/.cache/cabal on Unix. * $XDG_STATE_HOME/cabal for compiled libraries and other stateful artifacts. Defaults to ~/.local/state/cabal on Unix. * ~/.local/bin for executables installed with 'cabal install'. The advantage is mostly that cabal now behaves slightly more like other modern Unix tools. For example, it is easier to put all configuration files under version control if they’re all in the same subdirectory, and it is easier to delete all program caches when you’re low on disk space. This is obviously a rather invasive change. Does it mean that the next version of cabal will break your workflow? Maybe! But if so, it is not intentional. This change comes with what I hope is rather thorough backwards compatibility behaviour. Basically, if ~/.cabal exists, or $CABAL_DIR is set, the old behaviour of using a single unified directory will be maintained. And of course, most paths can still be configured manually in the configuration file. Still, because of the delicacy of a change like this, we’d like some external confirmation that cabal is still usable. This requires human trials. Therefore, if you are a human who uses cabal, please try installing the latest development version and see if it still works for you. If you want to try out the new XDG future, you can delete your ~/.cabal directory (possibly copying ~/.cabal/config to ~/.config/cabal/config first). I’ve been dogfooding this support for a over month, but I have no illusions about my usage covering the full feature space. Beyond whether cabal remains at all functional, I am personally curious whether the XDG simulacrum that is implemented on Windows is at all useful for Windows users, or whether it would be better for cabal to retain a single unified directory on that platform. Finally, on a meta note, this is my first contribution to Cabal. I previously heard horror stories about its code complexity, but I don’t think think they are warranted, at least not in the corner that I was touching. You certainly find relics of a long development process, including code necessary to support obsolete features (v1-build and sandboxes), but for a project its age and scope, I found the code both well structured and reasonably well documented. XDG support was added entirely by modifying cabal client code, without touching the Cabal library at all. -- \ Troels /\ Henriksen

2 4

Tlon is hiring a Haskell developer as a Senior Platform Engineer
by Edward Amsden 04 Oct '22

04 Oct '22

Urbit (urbit.org) is a social OS for everyone, and Tlon (tlon.io) is the primary company building it. Currently, most people run their Urbit OS on their own machine, but this won’t work for the masses. People need an easy way to get onto the network, and Tlon Hosting is building the product and platform to provide that. We are committed to becoming the primary infrastructure company for Urbit, hopefully managing millions of Urbit instances (aka “ships”) in the future. You will be joining a small team that is laying the foundation to build an ambitious and profitable business, which means you can have a big impact, and not only at Tlon, but on Urbit at large. We are looking for an infrastructure and platform engineer that is capable of leading the development of the next iteration of the hosting system. Running many Urbit instances at scale is not easy, because each instance needs to be carefully monitored and most Urbit life-cycle tasks need to be fully automated. To that effect, we implemented our own Kubernetes operator and additional tooling, all of which are written in Haskell. The role we are hiring for will have a central place in the further buildout of the system. You will develop the basic primitives and APIs that other engineers use to create a full featured hosting product. Additionally, you will need to be able to think strategically about how to iterate on the hosting platform so that other people can build on top of Urbit without having to worry where and how most of the Urbit instances run. In other words, hosting will have to become the most reliable and fool-proof way of using Urbit. Urbit is written in its own programming language, Hoon, and the runtime is written in C. But the hosting platform code is all written in Haskell, and that is what we are hiring for. The position and team is 100% remote. Most of us work in Europe time zones, and we prefer UTC +- 3 hours, but we are flexible. We do multiple offsites every year where we get to spend time IRL as a team and with everyone else at Tlon. Compensation range is $140-190k base salary, plus benefits, plus sizable bonus. There is a slight difference in the comp package structure depending on whether you are in the US or not, but in dollar value it should come out the same. Job Posting: https://tlon.io/careers/senior-platform-engineer To apply, write us here: apply(a)tlon.io

1 0

CFP for PEPM 2023 (Partial Evaluation and Program Manipulation)
by Edwin Brady 04 Oct '22

04 Oct '22

(Apologies for any duplicate copies) -- CALL FOR PAPERS -- ACM SIGPLAN Workshop on PARTIAL EVALUATION AND PROGRAM MANIPULATION (PEPM) 2022 =============================================================================== * Website : https://popl23.sigplan.org/home/pepm-2023 * Time : 16th--17th January 2023 * Place : Boston, Massachusetts, United States (co-located with POPL 2023) The ACM SIGPLAN Workshop on Partial Evaluation and Program Manipulation (PEPM) has a history going back to 1991 and has been co-located with POPL every year since 2006. It originated with the discoveries of useful automated techniques for evaluating programs with only partial input. Over the years, the scope of PEPM has expanded to include a variety of research areas centred around the theme of semantics-based program manipulation — the systematic exploitation of treating programs not only as subjects to black-box execution but also as data structures that can be generated, analysed, and transformed while establishing or maintaining important semantic properties. Scope ----- In addition to the traditional PEPM topics (see below), PEPM 2023 welcomes submissions in new domains, in particular: * Semantics based and machine-learning based program synthesis and program optimisation. * Modelling, analysis, and transformation techniques for distributed and concurrent protocols and programs, such as session types, linear types, and contract specifications. More generally, topics of interest for PEPM 2023 include, but are not limited to: * Program and model manipulation techniques such as: supercompilation, partial evaluation, fusion, on-the-fly program adaptation, active libraries, program inversion, slicing, symbolic execution, refactoring, decompilation, and obfuscation. * Techniques that treat programs/models as data objects including metaprogramming, generative programming, embedded domain-specific languages, program synthesis by sketching and inductive programming, staged computation, and model-driven program generation and transformation. * Program analysis techniques that are used to drive program/model manipulation such as: abstract interpretation, termination checking, binding-time analysis, constraint solving, type systems, automated testing and test case generation. * Application of the above techniques including case studies of program manipulation in real-world (industrial, open-source) projects and software development processes, descriptions of robust tools capable of effectively handling realistic applications, benchmarking. Examples of application domains include legacy program understanding and transformation, DSL implementations, visual languages and end-user programming, scientific computing, middleware frameworks and infrastructure needed for distributed and web-based applications, embedded and resource-limited computation, and security. This list of categories is not exhaustive, and we encourage submissions describing new theories and applications related to semantics-based program manipulation in general. If you have a question as to whether a potential submission is within the scope of the workshop, please contact the programme co-chairs, Edwin Brady (ecb10(a)st-andrews.ac.uk) and Jens Palsberg (palsberg(a)ucla.edu) Submission categories and guidelines ------------------------------------ Two kinds of submissions will be accepted: * Regular Research Papers should describe new results, and will be judged on originality, correctness, significance, and clarity. Regular research papers must not exceed 12 pages. * Short Papers may include tool demonstrations and presentations of exciting if not fully polished research, and of interesting academic, industrial, and open-source applications that are new or unfamiliar. Short papers must not exceed 6 pages. References and appendices are not included in page limits. Appendices may not be read by reviewers. Both kinds of submissions should be typeset using the two-column ‘sigplan’ sub-format of the new ‘acmart’ format available at: http://sigplan.org/Resources/Author/ and submitted electronically via HotCRP: https://pepm23.hotcrp.com/ Reviewing will be single-blind. Submissions are welcome from PC members (except the two co-chairs). Accepted regular research papers will appear in formal proceedings published by ACM, and be included in the ACM Digital Library. Accepted short papers do not constitute formal publications and will not appear in the proceedings. At least one author of each accepted contribution must attend the workshop (physically or virtually) and present the work. In the case of tool demonstration papers, a live demonstration of the described tool is expected. Important dates --------------- * Paper submission deadline : **Thursday 13th October 2022 (AoE)** * Author notification : **Thursday 10th November 2022 (AoE)** * Workshop : **Monday 16th January 2023 to Tuesday 17th January 2023** Best paper award ---------------- PEPM 2023 continues the tradition of a Best Paper award. The winner will be announced at the workshop. Programme committee ------------------- * Chairs: Edwin Brady (University of St Andrews, UK) Jens Palsberg (University of California Los Angeles, USA) * Nada Amin Harvard (USA) * Adam Barwell (Imperial College London, UK) * Nicolas Biri (Input Output Global) * David Castro-Perez (University of Kent at Canterbury, UK) * Cristina David (University of Bristol, UK) * Atsushi Igarashi (Kyoto University, Japan) * Yukiyoshi Kameyama (University of Tsukuba, Japan) * Geoffrey Mainland (Drexel University, USA) * Hila Peleg (Technion Israel Institute of Technology, Israel) * Casper Bach Poulsen (Delft University of Technology, Netherlands) * Sukyoung Ryu (KAIST, Korea) * Sven-Bodo Scholz (Radboud University Nijmegen, Netherlands) * Ilya Sergey (National University of Singapore, Singapore) * Satnam Singh (Groq Inc, USA) * Elena Zucca (University of Genova, Italy)

1 0

Obtain cost-centers stacks from eventlog file
by Ruben Astudillo 27 Sep '22

27 Sep '22

Hello -cafe! I got some experience profiling memory leaks using -prof and the +RTS -hc -L350 --RTS option. This gives me a .hp file with samples done at regular intervals. I can feed this file to `hp2pretty`, get some nice graphs and when I identify a suspicious band, I can grep the .hp file to get the complete "cost-center stack" responsible for that band. Here is an example of one: (18514)unsafeCreate/take/hexString/withText/parseOptionalFieldWith<...> I have been trying to replicate this setup using the eventlog logging. I use +RTS -l-aug -hc --RTS to get the eventlog with user and GC events. I use `eventlog2html` to get better view of memory allocation per cost-center. The normalized view presents me with cost-centers at the right side where I can filter on them[1]. But those labels are just the "top" of the cost-center stack. In fact I don't think the whole cost-center stack is represented anywhere on the eventlog file. I can sort of get the structure of the cost-center stack from the .hp file. The labels identifying the cost-center are different between the two files. Is there a way to recover the complete cost-center stack purely from the eventlog file? Thanks in advance [1]: https://imgur.com/a/nXyCEpG -- Rubén. (pgp: 1E88 3AC4 89EB FA22)

1 0

Munich Haskell Meeting, 2022-09-29 @ 19:30
by Leah Neukirchen 26 Sep '22

26 Sep '22

Dear all, This week, our monthly Munich Haskell Meeting will take place again on Thursday, September 29 at Cafe Puck(!) at 19h30. For details see here: http://muenchen.haskell.bayern/dates.html If you plan to join, please add yourself to this nuudel so we can reserve enough seats! It is OK to add yourself to the nuddel anonymously or pseudonymously. https://nuudel.digitalcourage.de/AtDC1Gfm99791KZ8 Everybody is welcome! cu, -- Leah Neukirchen <leah(a)vuxu.org> https://leahneukirchen.org/

1 0

Haskell courses @ 47 Degrees Academy
by Alejandro Serrano Mena 26 Sep '22

26 Sep '22

Dear all, I’m happy to announce that we’ve released four video courses about different topics in Haskell, at https://academy.47deg.com/collections/haskell - Introduction to optics (beginner) - Discovering functors, monads, and applicative (beginner) - Type level programming (intermediate) - Generic programming (advanced) As far as I know, this is some of the first content in video about the more advanced techniques in the language, like data type promotion or constraint kinds. I hope you all enjoy it! We're happy to hear any feedback from you :)

1 0

ProLaLa 2023 -- Programming Languages and the Law (Jan 15th 2023, Boston) : Deadline Oct 27th 2022
by Jonathan Protzenko 26 Sep '22

26 Sep '22

----------------------------------------------------------------------------------------- ProLaLa 2023 -- 2nd Workshop on Programming Languages and the Law Sunday Jan 15th, 2022 Boston, MA co-located with POPL 2023 ------------------------------------------------------------------------------------------ (please forward to anyone who might be interested!) We are pleased to announce ProLaLa'23, the second edition of the workshop concerned with the intersection of PL (Programming Languages) techniques and the law. We are particularly concerned with the following topics: - language design for legal matters; - static analysis of legal texts; - program synthesis and repair for legal software components; - formal modeling of legal semantics; - non-standard logics in support of legal reasoning; - program verification for legal expert systems. If you have explored any of these areas, we encourage you to submit a short abstract. We are hoping to solidify around this workshop what we believe is a nascent but growing community; last year we had 25 submissions and 60 participants. As such, the workshop will be informal, and we strongly encourage you to submit ongoing or already-published work in the form of a brief 5-page submission for a long talk, or a 2-page submission for a short talk. Full details: https://popl23.sigplan.org/home/prolala-2023#Call-for-Papers <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpopl23.si…> Venue ProLaLa will be colocated with POPL'23. We plan to coordinate with the POPL conference on remote participation. We would like to have remote participation even if the workshop happens in person. Our plan is to create an inclusive environment that does not demand traveling for COVID-19 (or other) reasons. Submission details We accept two kinds of submissions. - Long talks: 5 pages excluding references - Short talks: 2 page excluding references We require using SIGPLAN's one-column LaTeX format (acmsmall). Submission site: https://prolala23.hotcrp.com <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fprolala23…> Important dates - Thu 27 Oct 2022: Submission deadline - Thu 10 Nov 2022: Notification of acceptance - Sun 15 Jan 2023: Workshop Program committee - Shrutarshi Basu (co-chair), Middlebury College, USA - Denis Merigoux (co-chair), Inria, France - Jonathan Protzenko (co-chair), Microsoft Research, USA - Timos Antonopoulos, Yale, USA - Joaquín Arias, Universidad Rey Juan Carlos, Spain - James Grimmelman, Cornell, USA - Ekaterina Komandantskaya, Herriot-Watts University, UK - Emma Tosch, University of Michigan, USA - Saeid Tizpaz-Niari, University of Texas at El Paso, USA - Giovanni Sileno, University of Amsterdam, Netherlands - Chris Bailey, University of Illinois, USA - Laurence Diver, Vrije Universiteit Brussel, Belgium - Sarah Lawsky, Northwestern Pritzker School of Law, USA

1 0

PLMW@POPL 2023: Call For Scholarship Applications (DEADLINE: 10/14 AoE)
by Favonia 23 Sep '22

23 Sep '22

CALL FOR SCHOLARSHIP APPLICATIONS *DEADLINE: 14 October 2022, 23:59 AoE* (Anywhere on Earth) ACM SIGPLAN Programming Languages Mentoring Workshop Location: Boston, Massachusetts, USA Date: Tuesday, January 17, 2023 Web page: https://popl23.sigplan.org/home/PLMW-POPL-2023 Following the success of the first eleven Programming Languages Mentoring Workshops at POPL 2012-2022, we are pleased to announce the 12th SIGPLAN Programming Languages Mentoring Workshop (PLMW), co-located with POPL 2023 and organized by Hannah Gommerstadt, Michael Greenberg, Kuen-Bang Hou (Favonia), and Robbert Krebbers. The workshop will take place *in person* in Boston. PLMW aims to encourage graduate students and senior undergraduate students to pursue careers in programming language (PL) research. This workshop will bring together world leaders in PL research and teaching from both academia and industry to provide (a) technical sessions on cutting-edge PL research and (b) mentoring sessions on how to prepare for a research career. The workshop will help students imagine how they might contribute to our vibrant and thriving research community. We especially encourage women, members of underrepresented minorities, and people with disabilities to attend PLMW. This workshop is part of the activities surrounding POPL, the Symposium on Principles of Programming Languages, and takes place the day before the main conference. One goal of the workshop is to make the POPL conference more accessible to newcomers. We hope that participants will stay for the whole conference. A number of sponsors (listed below) 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 POPL conference itself. The workshop registration is open to all (with or without scholarships). Students with alternative sources of funding are welcome as well. APPLICATION FOR PLMW SCHOLARSHIP The application form can be accessed at the following URL: https://forms.gle/Ct19QcsKjSLoE38B9 The deadline for full consideration of funding is *14 October 2022, 23:59 AoE.* Confirmed sponsors so far: - NSF - ACM SIGPLAN - Jane Street - Galois

1 0

Can this be made to fuse?
by David Feuer 22 Sep '22

22 Sep '22

The template-haskell package has functions `tupE` and `tupP` for building tuple expressions and patterns, respectively, but nothing really similar for building tuple types. I came up with the version below the other day: -- | Given a list of types, produce the type of a tuple of -- those types. This is analogous to 'tupE' and 'tupP'. -- -- @ -- tupT [[t|Int|], [t|Char|], [t|Bool]] = [t| (Int, Char, Bool) |] -- @ tupT :: [Q Type] -> Q Type tupT ts = n `seq` res where -- We build the expression with a thunk inside that will be filled in with -- the length of the list once that's been determined. This works -- efficiently (in one pass) because TH.Type is rather lazy. (res, n) = foldl' (\(acc, !k) ty -> ([t| $acc $ty |], k + 1)) (tupleT n, 0) ts I strongly suspect this is quite fast enough in practice, but it's a bit annoying that it won't participate in list fusion; tupT (map f xs) will (lazily) generate an intermediate list. I wasn't able to convince GHC to fuse it, short of a custom rewrite rule or two (tupT (build f) = ..., tupT (augment f r = ...). Does anyone know if it's possible?

2 4

Re: [Haskell-cafe] monoid homomorphism
by Olaf Klinke 22 Sep '22

22 Sep '22

> Hello every one, > I'm reading "Programming with Categories Brendan Fong Bartosz Milewski David I. Spivak" > and here there's an example of monoid in Haskell: > > Consider the monoids Z× � (Z, 1, ×) and BAND � (B, true, AND). Let > is_odd : Z → B be the function that sends odd numbers to true and even numbers to > false. This is a monoid homomorphism. It preserves identities because 1 is odd, and > it preserves composition because the product of any two odd numbers is odd, but the > product of anything with an even number is even. > > > I'd like representing it graphically I mean the object Zx and arrows about is_odd function, > but I do not know how can do it. > > This is a valid example of monoid homomorphism and I'd like to know > the Haskell implementation and the corresponding categorically view. > > Thanks > Co Extending Li-yao's excellent answer, you could draw a single diagram using the free monoid monad. Disregarding non-termination and infinite lists, the free monoid is the list monad [*]. Every monoid has a structure map, namely mconcat :: Monoid m => [m] -> m satisfying equations (2) and (3) below. A function h :: z -> b between monoids is a monoid homomorphism iff it commutes with the structure map: h . mconcat = mconcat . fmap f (1) mconcat [Z] ---------> Z | | | fmap h | h | | v v [B] ---------> B mconcat This commutative square subsumes Li-yao's two squares. Instantiate the equation (1) with empty and two-element lists to recover Li-yao's squares, where mconcat [] = mempty, mconcat [x,y] = x `mappend` y. In "Programming with Categories" terminology: Monoid homomorphisms are []-Algebra homomorphisms (Definition 4.9). What is not contained in "Programming with Categories" are the Eilenberg-Moore algebra laws. Namely, mconcat . pure = id (2) mconcat . concat = mconcat . fmap mconcat (3) See also chapters in 6 and 7 in [1]. There, the example is linear functions between vector spaces, which are algebra homomorphisms of the monad of formal linear combinations. Olaf [*] Mathematically, the free monoid over a set A is the set of finite words in the alphabet A, with the empty word as 'mempty' and concatenation of words as 'mappend'. E.g. the free monoid over Char is Text. [1] https://hub.darcs.net/olf/haskell_for_mathematicians

1 0

How to diagnose a loop in a large Haskell program?
by Han Joosten 22 Sep '22

22 Sep '22

Hi, I am struggling to debug a loop (some nontermination behaviour) of a huge program. Normally, I use `stack build` to generate it. I have tried to use `trace` at lots of places in the code, recompile and see what happens. However, it isn't always clear in what order the trace statements are fired, because of the lazy evaluation of Haskell. So I tried another approach. I have a function fatal :: HasCallStack => Text -> a fatal msg = exitWith . Fatal . T.lines $ ( msg <> "\n" <> (utf8BuilderToText . displayCallStackFull $ callStack) ) displayCallStackFull :: CallStack -> Utf8Builder displayCallStackFull cs = case reverse $ getCallStack cs of [] -> "<no call stack found>" xs -> mconcat $ fmap showCall xs where showCall :: (String, SrcLoc) -> Utf8Builder showCall (desc, loc) = let file = srcLocFile loc in "\n" <> fromString file <> ":" <> displayShow (srcLocStartLine loc) <> ":" <> displayShow (srcLocStartCol loc) <> " " <> fromString desc (The function to show the stack was inspired from https://hackage.haskell.org/package/rio-0.1.22.0/docs/RIO.html#v:displayCal… ). I would expect that at any place where I force a call to `fatal`, I would get the full stacktrace. Unfortunately, I only get the place where the call to fatal is in the code. I have been looking at the documentation of both stack and ghc, but I don't understand how to compile my code in a way that the full stacktrace is shown. Until now the best guess I have is stack install --profile --no-strip && ampersand -- check testing/Sentinel/Tests/ShouldSucceed/OnlyValidation/Issue280.adl The ultimate goal is to get rid of this ugly bug regarding the loop. Any help/suggestions is really appreciated! Thanks for reading. Han Joosten

2 3

monoid homomorphism
by coplot coplot 22 Sep '22

22 Sep '22

2 1

Props to cpphs; why so little used?
by Anthony Clayden 20 Sep '22

20 Sep '22

Thank you to the author and maintainers of cpphs https://hackage.haskell.org/package/cpphs It has tightly-focussed functionality for what I wanted to do: a more haskell-friendly counterpart to cpp. How to get it to behave as I wanted wasn't always obvious. I made some notes https://stackoverflow.com/a/73768057/2840542 Haskell libraries generally use cpp -- and then users complain how awkward it can be. I don't see that cpp does anything better/different vs cpphs -- that is, cpphs understands all the #if compiler_version logic. Then why isn't every library preferring cpphs? AntC

4 4

Re: [Haskell-cafe] Cabal: other-modules necessary?
by Tom Ellis 20 Sep '22

20 Sep '22

Ah, that's interesting Oleg, thanks. I like the idea of Cabal being able to specify the exact mapping between modules and source files. Tom On Fri, Sep 16, 2022 at 04:05:53PM +0300, Oleg Grenrus wrote: > That is error generated by GHC. > > The culprit is `ghc --make` mode which discovers modules/files on its own. > > If there were a way to say (for Cabal to GHC) that use these files to > compile the component, and fail otherwise, then -Wmissing-home-modules > would turn into error. > > In fact, it would be great if it where possible to say that *this* > module is in *that* file, something like `MyFoo:src/MyFoo.hs`. > > That would also solve a problem of having same hs-source-dirs for > different components, as Cabal would be able to tell GHC that "don't > look for this modules locally, use dependencies". As currently GHC will > eagerly look for modules locally first. Always. > > - Oleg > > On 16.9.2022 12.23, Tom Ellis wrote: > > On Fri, Sep 16, 2022 at 10:47:47AM +0200, Volker Wysk wrote: > >> The cabal user guide says (in section 6.2.12): "Every module in the package > >> must be listed in one of other-modules, library:exposed-modules or > >> executable:main-is fields." > >> > >> However, I only get a warning message, when I comment out the other-modules > >> field in my .cabal file. The program compiles. This is the message: > >> > >> <no location info>: warning: [-Wmissing-home-modules] > >> These modules are needed for compilation but not listed in your .cabal > >> file's other-modules: > >> Hsskripte Sicherung SicherungAktionen Text Wahl Zeit > >> > >> Is it really necessary to specify all the imported modules? If so, why does > >> the program compile? Can that warning message be turned off? > > In response to all the sibling replies at once, is there a good reason > > for this behaviour? Succeeding but then failing later with obscure > > errors (once the original warning message is nowhere to be seen) seems > > like the worst of all worlds. Suppose cabal errored here and failed > > to proceed. What would be the downside of that (besides backward > > incompatibility)?

2 1

[TFP 2023 Call for Papers] 24th International Symposium on Trends in Functional Programming
by Peter Achten 19 Sep '22

19 Sep '22

# TFP 2023 -- Call for Papers (trendsfp.github.io) ## Important Dates Submission deadline: pre-symposium, full papers, Wednesday 23rd November, 2022 Submission deadline: pre-symposium, draft papers, Friday 16th December, 2022 Notification: pre-symposium submissions, Friday 23rd December, 2022 Registration: Friday 6th January, 2023 TFPIE Workshop: Thursday 12th January, 2023 TFP Symposium: Friday 13th - Sunday 15th January, 2023 Submission deadline: post-symposium review, Friday 17th February, 2023 Notification: post-symposium submissions, Friday 31st March, 2023 The Symposium on Trends in Functional Programming (TFP) is an international forum for researchers with interests in all aspects of functional programming, taking a broad view of current and future trends in the area. It aspires to be a lively environment for presenting the latest research results, and other contributions. This year, TFP will take place in-person at UMass Boston, Massachusetts in the United States. It is co-located with the Trends in Functional Programming in Education (TFPIE) workshop, which will take on the day before the main symposium. Please be aware that TFP has several submission deadlines. The first, November 23, is for authors that wish to have their full paper reviewed prior to the symposium. Papers that are accepted in this way must also be presented at the symposium. The second, December 16, is for authors that wish to present their work or work-in progress at the symposium first without submitting to the full review process for publication. These authors can then take into account feedback received at the symposium and submit a full article for review by the third deadline, February 17. ## Scope The symposium recognizes that new trends may arise through various routes. As part of the Symposium's focus on trends we therefore identify the following five article categories. High-quality articles are solicited in any of these categories: * Research Articles: Leading-edge, previously unpublished research work * Position Articles: On what new trends should or should not be * Project Articles: Descriptions of recently started new projects * Evaluation Articles: What lessons can be drawn from a finished project * Overview Articles: Summarizing work with respect to a trendy subject Articles must be original and not simultaneously submitted for publication to any other forum. They may consider any aspect of functional programming: theoretical, implementation-oriented, or experience-oriented. Applications of functional programming techniques to other languages are also within the scope of the symposium. Topics suitable for the symposium include, but are not limited to: * Functional programming and multicore/manycore computing * Functional programming in the cloud * High performance functional computing * Extra-functional (behavioural) properties of functional programs * Dependently typed functional programming * Validation and verification of functional programs * Debugging and profiling for functional languages * Functional programming in different application areas: security, mobility, telecommunications applications, embedded systems, global computing, grids, etc. * Interoperability with imperative programming languages * Novel memory management techniques * Program analysis and transformation techniques * Empirical performance studies * Abstract/virtual machines and compilers for functional languages * (Embedded) domain specific languages * New implementation strategies * Any new emerging trend in the functional programming area If you are in doubt on whether your article is within the scope of TFP, please contact the TFP 2023 program chair, Stephen Chang. ## Best Paper Awards TFP awards two prizes for the best papers each year. First, to reward excellent contributions, TFP awards a prize for the best overall paper accepted for the post-conference formal proceedings. Second, a prize for the best student paper is awarded each year. TFP traditionally pays special attention to research students, acknowledging that students are almost by definition part of new subject trends. A student paper is one for which the authors state that the paper is mainly the work of students, the students are listed as first authors, and a student would present the paper. In both cases, it is the PC of TFP that awards the prize. In case the best paper happens to be a student paper, then that paper will receive both prizes. ## Instructions to Authors Papers must be submitted at: <https://easychair.org/conferences/?conf=tfp23> Authors of papers have the choice of having their contributions formally reviewed either before or after the Symposium. Further, pre-symposium submissions may either be full (earlier deadline) or draft papers (later deadline). ## Pre-symposium formal review Papers to be formally reviewed before the symposium should be submitted before the early deadline and will receive their reviews and notification of acceptance for both presentation and publication before the symposium. A paper that has been rejected for publication but accepted for presentation may be resubmitted for the post-symposium formal review. ## Post-symposium formal review Draft papers will receive minimal reviews and notification of acceptance for presentation at the symposium. Authors of draft papers will be invited to submit revised papers based on the feedback receive at the symposium. A post-symposium refereeing process will then select a subset of these articles for formal publication. ## Paper categories Draft papers and papers submitted for formal review are submitted as extended abstracts (4 to 10 pages in length) or full papers (20 pages). The submission must clearly indicate which category it belongs to: research, position, project, evaluation, or overview paper. It should also indicate which authors are research students, and whether the main author(s) are students. A draft paper for which all authors are students will receive additional feedback by one of the PC members shortly after the symposium has taken place. ## Format Papers must be written in English, and written using the LNCS style. For more information about formatting please consult the Springer LNCS web site. ## Program Committee Peter Achten, Radboud University Nijmegen, Netherlands Nada Amin, Harvard University, USA Ambrose Bonnaire-Sergeant, Untypable LLC, USA Laura M. Castro, University of A Coruña, Spain Stephen Chang (Chair), University of Massachusetts Boston, US John Clements, Cal Poly, USA Youyou Cong, Tokyo Institute of Technology, Japan Paul Downen, University of Massachusetts Lowell, USA Kathy Gray, Meta Platforms, Inc., UK Ben Greenman, University of Utah, USA Jason Hemann, Seton Hall University, USA Patricia Johann, Appalachian State University, USA Alexis King, Tweag, USA Julia Lawall, Inria-Paris, France Barak Pearlmutter, Maynooth University, Ireland Norman Ramsey, Tufts University, USA Ilya Sergey, National University of Singapore, Singapore Melinda Tóth, Eötvös Loránd University, Hungary Ningning Xie, University of Toronto, Canada

1 0

Cabal: other-modules necessary?
by Volker Wysk 16 Sep '22

16 Sep '22

Hi The cabal user guide says (in section 6.2.12): "Every module in the package must be listed in one of other-modules, library:exposed-modules or executable:main-is fields." However, I only get a warning message, when I comment out the other-modules field in my .cabal file. The program compiles. This is the message: <no location info>: warning: [-Wmissing-home-modules] These modules are needed for compilation but not listed in your .cabal file's other-modules: Hsskripte Sicherung SicherungAktionen Text Wahl Zeit Is it really necessary to specify all the imported modules? If so, why does the program compile? Can that warning message be turned off? Apart from that, I'm happy with cabal. :-) Cheers, Volker

7 12

Cabal problem, broken packages?
by Volker Wysk 16 Sep '22

16 Sep '22

Hi! I've lately set up the Haskell environment on my Linux box, with no problems. Then I have installed some packages with "cabal install", again without problems. But now I'm trying to install another package and I get a dependency conflict. It doesn't seem to matter which package I try to install: desktop ~ $ cabal install rfc5051 Resolving dependencies... cabal: Could not resolve dependencies: [__0] next goal: directory (user goal) [__0] rejecting: directory-1.3.8.0 (constraint from user target requires ==1.3.7.1) [__0] trying: directory-1.3.7.1 [__1] next goal: ghc (user goal) [__1] rejecting: ghc-9.4.2, ghc-9.4.1, ghc-9.2.4, ghc-9.2.3, ghc-9.2.2, ghc-9.2.1, ghc-9.0.2, ghc-8.10.7, ghc-8.10.2, ghc-8.10.1 (constraint from user target requires ==8.8.4) [__1] rejecting: ghc-8.8.4/installed-8.8... (conflict: directory==1.3.7.1, ghc => directory==1.3.6.0/installed-1.3...) [__1] rejecting: ghc-8.8.3, ghc-8.8.1, ghc-8.6.5, ghc-8.6.4, ghc-8.6.1, ghc-8.4.4, ghc-8.4.3, ghc-8.4.1, ghc-8.2.2, ghc-8.2.1, ghc-9.2.3.20220620 (constraint from user target requires ==8.8.4) [__1] fail (backjumping, conflict set: directory, ghc) After searching the rest of the dependency tree exhaustively, these were the goals I've had most trouble fulfilling: directory, ghc This doesn't make much sense to me. How can I repair it? Are the packages broken? Can a solution somehow be specified? Cheers, Volker

4 16

What became of James Cook? (Need package update)
by Olaf Klinke 14 Sep '22

14 Sep '22

Dear Café, does anyone happen to know what became of James Cook? (The programmer [1,2] a.k.a. mokus, not the explorer.) On github his last commit was in May. I've been trying to contact him at mokus(a)deepbondi.net three timessince March, but no luck. I'm using his package [3] which does not have a public repo. It needs minor adjustments to comply with the MonadFail change. Currently I have no intentions to properly take over the package, since James does seem to be an active developer generally, but James hasn't answered my request to become a hackage co-maintainer of [3] either. Does anyone know alternative channels to reach James? Or could such a minor adjustment [4] be made by the hackage trustees? Thanks Olaf [1] https://hackage.haskell.org/user/JamesCook [2] https://github.com/mokus0 [3] https://hackage.haskell.org/package/dbf [4] dbf-0.0.0.2 is broken by the removal of "fail" from the Monad class, as src/Database/XBase/Dbf/Structures.hs uses fail in line 61 and binary does not implement MonadFail for its PutM Monad. A quick workaround is to replace the call to fail by error. (Which should be semantically equivalent for the old Control.Monad.fail)

1 0

Build haddock documentation of a cabal project
by coot＠coot.me 12 Sep '22

12 Sep '22

Hello Haskell Cafe Next release of `cabal` and `haddock` will gain the capability of building documentation of a cabal project. A few weeks ago when the PR (https://github.com/haskell/cabal/pull/8162) was still in review I wrote a blog post about it: https://coot.me/posts/cabal-haddock-project.html Cheers, Marcin

2 1

OOPSLA 2023: Round 1 Call for Papers
by Andreea Costea 12 Sep '22

12 Sep '22

======================================================================== PACMPL Issue OOPSLA 2023 Call for Papers OOPSLA 2023 will be held as part of The ACM Conference on Systems, Programming, Languages, and Applications: Software for Humanity (SPLASH'23) October 23-27, 2023, Lisbon, Portugal https://2023.splashcon.org/track/splash-2023-oopsla ======================================================================== ### Important dates ROUND 1: Submission Deadline: Fri Oct 28, 2022 Author Response: Wed Dec 07 - Fri Dec 9 Author Notification: Thu Dec 22 Submission of Revisions: Mon Feb 13 - Fri Feb 24 ROUND 2: Submission Deadline: Fri Apr 14, 2023 Author Response: Wed Jun 14 - Fri Jun 16 Author Notification: Fri Jun 30 Submission of Revisions: Mon Aug 14 - Fri Aug 18 Camera ready: Thu Aug 31 Papers accepted at either of the rounds will be published in the 2023 volume of PACMPL(OOPSLA) and invited to be presented at the SPLASH conference in October 2023. ### Scope The OOPSLA issue of the Proceedings of the ACM on Programming Languages (PACMPL) welcomes papers focusing on all practical and theoretical investigations of programming languages, systems and environments. Papers may target any stage of software development, including requirements, modeling, prototyping, design, implementation, generation, analysis, verification, testing, evaluation, maintenance, and reuse of software systems. Contributions may include the development of new tools, techniques, principles, and evaluations. ### Review Process PACMPL(OOPSLA) has two _rounds_ of reviewing. The final outcome of each round can be one of Accept, Revise or Reject. *Accept*: Accepted papers will appear at the next PACMPL(OOPSLA). *Revise*: Papers in this category are invited to submit a revision to the _next round_ of submissions with a specific set of expectations to be met. When authors resubmit, they should clearly explain how the revisions address the comments of the reviewers. The revised paper will be re-evaluated, and either accepted or rejected. Resubmitted papers will retain the same reviewers throughout the process. *Reject*: Rejected papers will not be included in the 2023 volume of PACMPL(OOPSLA). Papers in this category are not guaranteed a review if resubmitted less than one year from the date of original submission. A paper will be judged to be a resubmission if it is substantially similar to the original submission. The judgment that a paper is a resubmission of the same work and whether, in this case, it will be reviewed or not is at the discretion of the Chair. Obviously, this same policy applies to papers that were rejected for inclusion in the 2022 volume of PACMPL(OOPSLA). Each _round_ of reviewing consists of two _phases_. The first phase evaluates the papers and results in an early notification of Reject, Revise, or Conditional Accept. During the first phase, authors will be able to read their reviews and respond to them. The second phase is restricted to conditionally accepted papers. Authors must make a set of mandatory revisions. The second phase assesses whether the required revisions have been addressed. The outcome can be Accept, Revise or Reject. ### Submissions Submitted papers must be at most **23 pages** in 10 point font. There is no page limit on references. No appendices are allowed on the main paper, instead authors can upload supplementary material with no page or content restrictions, but reviewers may choose to ignore it. Submissions must adhere to the "ACM Small" template available from [the ACM](http://www.acm.org/publications/authors/submissions). Papers are expected to use author-year citations. Author-year citations may be used as either a noun phrase, such as "The lambda calculus was originally conceived by Church (1932)", or a parenthetic phase, such as "The lambda calculus (Church 1932) was intended as a foundation for mathematics". PACMPL uses double-blind reviewing. Authors' identities are only revealed if a paper is accepted. Papers must 1. omit author names and institutions, 2. use the third person when referencing your work, 3. anonymise supplementary material. Nothing should be done in the name of anonymity that weakens the submission; see the DBR FAQ. When in doubt, contact the Review Committee Chairs. Papers must describe unpublished work that is not currently submitted for publication elsewhere as described by [SIGPLAN's Republication Policy](http://www.sigplan.org/Resources/Policies/Republication). Submitters should also be aware of [ACM's Policy and Procedures on Plagiarism](http://www.acm.org/publications/policies/plagiarism_policy). Submissions are expected to comply with the [ACM Policies for Authorship](https://www.acm.org/publications/authors/information-for-author…. ### Artifacts Authors should indicate with their initial submission if an artifact exists, describe its nature and limitations, and indicate if it will be submitted for evaluation. Accepted papers that fail to provide an artifact will be requested to explain the reason they cannot support replication. It is understood that some papers have no artifacts. ### Publication PACMPL is a Gold Open Access journal, all papers will be freely available to the public. Authors can voluntarily cover the article processing charge ($400), but payment is not required. The official publication date is the date the journal are made available in the ACM Digital Library. The journal issue and associated papers may be published up to two weeks prior to the first day of the conference. ### Additional Information Consult FAQ in Call for Papers at: https://2023.splashcon.org/track/splash-2023-oopsla ### Review Committee PC Chair: Mira Mezini (TU Darmstadt) Derek Dreyer (MPI-SWS, DE)- Associate Chair Sophia Drosopolou (Facebook; Imperial College, UK)- Associate Chair Patrick Eugster (USI, Switzerland; Purdue U.)- Associate Chair Shriram Krishnamurthi (Brown University, USA)- Associate Chair Jonathan Aldrich (CMU, USA) Karim Ali (U. Alberta, Canada) Peter Alvaro (UC Santa Cruz, USA) Stefanie Balzer (CMU, USA) Osbert Bastani (U. Penn, USA) Annette Bieniusa (U. Kaiserslautern, Germany) Sebastian Burkhardt (MSR, Switzerland) Satish Chandra (Facebook, USA) James Cheney (University of Edinburgh; Alan Turing Institute, UK) Albert Cohen (Google, France) Wolfgang De Meuter (VUB, BE) Dominique Devriese (KU Leuven, Belgium) Dana Drachsler Cohen (Technion, Israel) Jana Dunfield (Queen’s University in Kingston, Ontario, CA) Sebastian Erdweg (U. Mainz, Germany) Matthew Flatt (U. Utah, USA) Jeremy Gibbons (U. Oxford, UK) Anitha Gollamudi (UMass, USA) Elisa Gonzalez Boix (VUB, Belgien) Andrew Gordon (MS Research, Edinburgh, UK) Dan Grossman (U. Washington, USA) Arjun Guha (Northeastern U., USA) Philipp Haller (KTH, Sweden) Görel Hedin (Lund University, Sweden) Steven Holtzen (Northeastern U., USA) Justin Hsu (Cornell University, USA) Atsushi Igarashi (Kyoto U., Japan) Ranjit Jhala (UC San Diego, USA) Gowtham Kaki (U. Colorado, USA) Neel Krishnaswami (Cambridge, UK) Burcu Kulahcioglu Ozkan (Delft University of Technology, The Netherlands) Sorin Lerner (UCSD, USA) Hongjin Liang (Nanjing University, CN) Crista Lopes (UC Irvine, USA) Kenji Maillard (Inria Nantes & University of Chile) Hidehiko Masuhara (Tokyo Institute of Technology, Japan) Ana Milanova (Rensselaer Polytechnic Institute) Heather Miller (CMU, USA) Ragnar Mogk (TU Darmstadt, DE) Anders Møller (Aarhus U,, Danemark) Fabrizio Montesi (Univ. of Southern Denmark, Denmark) Sarah Nadi (U. Alberta, Canada) James Noble (U. Wellington, New Zealand) Bruno C. d. S. Oliveira (U. Hong Kong, Hong Kong) Klaus Ostermann (U. Tübingen, Germany) Mangpo Phothilimthana (Google Brain, USA) Benjamin Pierce (UPenn, USA) Nadia Polikarpova (UC San Diego, USA) Michael Pradel (U. Stuttgart, Germany) Shaz Qadeer (Facebook, USA) Marianna Rapoport (Amazon Web Services, Canada) Cindy Rubio-González (UC Davis, USA) Sukyoung Ryu (KAIST, Korea) Guido Salvaneschi (U. St. Gallen, Switzerland) Mark Santolucito (Columbia, USA) Ilya Sergey (National University of Singapore, Singapore) Armando Solar-Lezama (MIT, USA) Manu Sridharan (University of California, USA) Charles Sutton (Google, UK) Joseph Tassarotti (New York University, USA) Ross Tate (Cornell U., USA) Peter Thiemann (U. Freiburg, Germany) Bernardo Toninho (Universidade Nova de Lisboa, Portugal) Viktor Vafeiadis (MPI, Germany) Tijs van der Storm (CWI; University of Groningen, Netherlands) Vasco Vasconcelos (U. Lisbon, Portugal) Jan Vitek (Northeastern U./Czech Technical University) Dimitrios Vytiniotis (DeepMind, UK) David Walker (Princeton, USA) Conrad Watt (U. Cambridge, UK) Pascal Weisenburger (U. St. Gallen, Switzerland) Qirun Zhang (Gatech, USA)

1 0

Combine pattern synonyms and record wild cards
by rowan goemans 12 Sep '22

12 Sep '22

Hello all, I'm playing with pattern synonyms to create a more intuitive API. Essentially what I would like is to allow a record wild card through a pattern synonym. Allow me to illustrate with an example. I have a data type. `data Foo a = Foo { unFoo :: a }` and a type `FooMaybe a = Maybe (Foo a)`. Now I have a pattern synonym `pattern FooJust x = Just (Foo x)`. This works and I can match on it no problem. But by doing this I lose the ability to use RecordWildCards. I can do this `myFun (Just Foo{..}) but not this `myFun FooJust{..}`. Is there some way to use pattern synonym while preserving the ability of using record wild cards? Best regards, Rowan Goemans

1 0

Re: [Haskell-cafe] Generic "annotations" on type definitions
by Olaf Klinke 11 Sep '22

11 Sep '22

> Hello all, > > I was recently thinking about a generic programming application > (auto-generating UI code from data definitions) that would benefit from the > ability to "annotate" data definitions. For example, let's say you have a > type > > data Foo = Foo {barred :: Boolean} > > You are (auto-)generating a UI to display and manipulate `Foo`s. Perhaps > the generic UI code defaults to making a check-box for Boolean values, but > you would rather have it be a radio button. It would be advantageous to be > able to write something like e.g. > > data Foo = Foo {barred :: Boolean # RenderMode RadioButton} > > In many languages, you have the ability to annotate data fields in a way > which has no bearing whatsoever on the first-order behavior or > representation of the type, and is only reflected via the language's > generic programming API. For example, in Java, you have > > class Foo { > @RenderMode(RadioButton) > bool barred; > } > > And in Rust, you have > struct Foo { > #[render_mode(radio_button)] > barred : bool > } > > In Haskell, I do not believe we have any such system in place for > interfacing with Generics. > > The closest I am familiar with is from the optparse-generic package, where > you write code of the form > > data Foo w = Foo {barred :: w ::: Boolean <?> RenderMode RadioButton} > > See > https://hackage.haskell.org/package/optparse-generic-1.4.8/docs/Options-Gen…:: > :: > > This is basically a clever way to sort of re-create what we have available > in Rust or Java, using type families, but with the annoying downside that > it makes interacting with your type in normal code much more cumbersome, > and is also relatively confusing to read and write. > > Compare Rust's Clap package, which is very similar to optparse-generic, but > more convenient to work with because the annotations don't impact normal > usage of the type. > > See https://docs.rs/clap/latest/clap/#example > > Would it be technically feasible to add such a thing to GHC's Generics > support? I could imagine something like updating the GHC.Generics Meta > type's MetaCons constructor to > > MetaCons Symbol FixityI Bool *[Annotation]* > > Best, > Will Why not use special syntax in comments, like we do for Haddock, doctests etc. data Foo = Foo { barred :: Boolean -- ^ #GUI[RenderMode RadioButton] } There is a functional language capable of auto-generating input forms: Clean https://clean.cs.ru.nl/Clean with the iTask library on top. It can also generate forms for recursive types. The Dutch coast guard uses it to interactively design queries to a database of marine vessel movements. It'd be cool if Haskell's Generics also could do that. Olaf

3 3

Generic "annotations" on type definitions
by William Yager 10 Sep '22

10 Sep '22

Hello all, I was recently thinking about a generic programming application (auto-generating UI code from data definitions) that would benefit from the ability to "annotate" data definitions. For example, let's say you have a type data Foo = Foo {barred :: Boolean} You are (auto-)generating a UI to display and manipulate `Foo`s. Perhaps the generic UI code defaults to making a check-box for Boolean values, but you would rather have it be a radio button. It would be advantageous to be able to write something like e.g. data Foo = Foo {barred :: Boolean # RenderMode RadioButton} In many languages, you have the ability to annotate data fields in a way which has no bearing whatsoever on the first-order behavior or representation of the type, and is only reflected via the language's generic programming API. For example, in Java, you have class Foo { @RenderMode(RadioButton) bool barred; } And in Rust, you have struct Foo { #[render_mode(radio_button)] barred : bool } In Haskell, I do not believe we have any such system in place for interfacing with Generics. The closest I am familiar with is from the optparse-generic package, where you write code of the form data Foo w = Foo {barred :: w ::: Boolean <?> RenderMode RadioButton} See https://hackage.haskell.org/package/optparse-generic-1.4.8/docs/Options-Gen…:: :: This is basically a clever way to sort of re-create what we have available in Rust or Java, using type families, but with the annoying downside that it makes interacting with your type in normal code much more cumbersome, and is also relatively confusing to read and write. Compare Rust's Clap package, which is very similar to optparse-generic, but more convenient to work with because the annotations don't impact normal usage of the type. See https://docs.rs/clap/latest/clap/#example Would it be technically feasible to add such a thing to GHC's Generics support? I could imagine something like updating the GHC.Generics Meta type's MetaCons constructor to MetaCons Symbol FixityI Bool *[Annotation]* Best, Will

3 2

[ANN] Copilot 3.11 -- hard realtime C runtime verification
by Ivan Perez 08 Sep '22

08 Sep '22

Dear all, We are very happy to announce the release of Copilot 3.11. Copilot is a runtime verification system implemented as a Haskell DSL that generates hard-realtime C99. Among others, Copilot is being used by the Safety Critical Avionics Systems Branch of NASA Langley Research Center for monitoring test flights of drones. You can learn more about it at [1]. Copilot 3.11 introduces a new library, copilot-interpreter, that isolates all functions related to simulation of Copilot specifications. The release also contains a number of bug fixes, provides a simplified API, deprecates outdated elements, removes unused code, and introduces support for GHC 9.2. A full list of changes merged is available at [2]. A substantial effort is being made to achieve NASA's Class D software classification, most notably in terms of development process (which you can partly witness in how issues and PRs are being handled on our github repo), test coverage (mostly with quickcheck), and proofs of correctness of the generated code (with what4). Copilot is being used by the Safety-Critical Avionics Systems Branch (D320) of NASA Langley Research Center to conduct experiments related to flight safety of aerial vehicles. We have also built Ogma [3], a tool that allows us to generate full monitoring applications (e.g., NASA's Core Flight System [4] and Robot Operating System [5] applications) from requirements in structured natural language. We invite you all to explore Copilot, to try it, and to extend it. If you like it, please help us draw attention to this work with a star on github or a mention online. Happy Haskelling, The Copilot Team [1] https://github.com/Copilot-Language/copilot [2] https://github.com/Copilot-Language/copilot/milestone/15?closed=1 [3] https://github.com/nasa/ogma [4] https://cfs.gsfc.nasa.gov/ [5] https://www.ros.org/

1 0

any advice for tracking down a failure to compile (it just hangs) with ghc 9.2.4?
by Doug Burke 06 Sep '22

06 Sep '22

I have noticed I can't run one of my tests when building with ghc 9.2.4 (tried via stack and nix) that doesn't happen with ghc 9.2.3 (or older versions). Is there a way to diagnose the problem (so I can look at the ghc bug tracker or try and make the code smaller for testing)? I can see this behavior with the following reproducer (it's a bit heavyweight at the moment!): % git clone https://gitlab.com/dburke/swish temp % cd temp Added to get the timings, but it's not strictly necessary: % sed -i -e "s/-Wall /-Wall -ddump-timings /" swish.cabal Now try to build and run the test. The following build and run the test quickly if using an older GHC (e.g. "--resolver lts" for the stack case or "--argstr compiler ghc923" for the nix case). First with stack % sed -i -e "s/-Wall /-Wall -ddump-timings /" swish.cabal % stack test --resolver nightly-2022-09-05 :test-rdfproof Stack has not been tested with GHC versions above 9.0, and using 9.2.4, this may fail Stack has not been tested with Cabal versions above 3.4, but version 3.6.3.0 was found, this may fail swish> configure (lib + test) Configuring swish-0.10.2.0... swish> build (lib + test) Preprocessing library for swish-0.10.2.0.. Building library for swish-0.10.2.0.. Preprocessing test suite 'test-rdfproof' for swish-0.10.2.0.. Building test suite 'test-rdfproof' for swish-0.10.2.0.. *** initializing unit database: initializing unit database: alloc=7350056 time=8.753 *** initializing unit database: initializing unit database: alloc=3999144 time=16.194 *** Chasing dependencies: *** systool:cpp: systool:cpp: alloc=271104 time=1.991 Chasing dependencies: alloc=10233768 time=8.400 [2 of 2] Compiling Main *** Parser [Main]: Parser [Main]: alloc=24346344 time=33.067 *** Renamer/typechecker [Main]: Renamer/typechecker [Main]: alloc=101896128 time=134.992 *** Desugar [Main]: Desugar [Main]: alloc=24628816 time=24.813 *** Simplifier [Main]: Simplifier [Main]: alloc=667236400 time=775.137 *** Specialise [Main]: Specialise [Main]: alloc=45057312 time=40.543 *** Float out(FOS {Lam = Just 0, Consts = True, OverSatApps = False}) [Main]: Float out(FOS {Lam = Just 0, Consts = True, OverSatApps = False}) [Main]: alloc=208806472 time=330.396 *** Simplifier [Main]: Simplifier [Main]: alloc=603245992 time=747.067 *** Simplifier [Main]: Simplifier [Main]: alloc=564322584 time=709.583 *** Simplifier [Main]: Simplifier [Main]: alloc=728039528 time=835.525 *** Float inwards [Main]: *** Called arity analysis [Main]: *** Simplifier [Main]: Float inwards [Main]: alloc=23720 time=0.017 Called arity analysis [Main]: alloc=25848 time=0.016 Progress 0/2 Now with nix % nix-shell --argstr compiler ghc924 ... wait an indeterminate amount of time % ghc --version The Glorious Glasgow Haskell Compilation System, version 9.2.4 % cabal test test-rdfproof Warning: The package list for 'hackage.haskell.org' is 19 days old. Run 'cabal update' to get the latest list of available packages. Resolving dependencies... Build profile: -w ghc-9.2.4 -O1 In order, the following will be built (use -v for more details): - swish-0.10.2.0 (lib) (first run) - swish-0.10.2.0 (test:test-rdfproof) (first run) Configuring library for swish-0.10.2.0.. Preprocessing library for swish-0.10.2.0.. Building library for swish-0.10.2.0.. [ 1 of 55] Compiling Data.Interned.URI [ 2 of 55] Compiling Data.Ord.Partial [ 3 of 55] Compiling Data.String.ShowLines [ 4 of 55] Compiling Network.URI.Ord [ 5 of 55] Compiling Swish.GraphClass ... ... a lot more, including some annoying non-exhaustive patterns I don't know how to fix ... but that's for a different post ... [55 of 55] Compiling Swish Configuring test suite 'test-rdfproof' for swish-0.10.2.0.. Preprocessing test suite 'test-rdfproof' for swish-0.10.2.0.. Building test suite 'test-rdfproof' for swish-0.10.2.0.. *** initializing unit database: initializing unit database: alloc=7389248 time=4.436 *** initializing unit database: initializing unit database: alloc=4001312 time=11.992 *** Chasing dependencies: *** systool:cpp: systool:cpp: alloc=319464 time=0.520 Chasing dependencies: alloc=12863280 time=6.581 [1 of 2] Compiling TestHelpers ( tests/TestHelpers.hs, /home/dburke/rdf/temp/dist-newstyle/build/x86_64-linux/ghc-9.2.4/swish-0.10.2.0/t/test-rdfproof/build/test-rdfproof/test-rdfproof-tmp/TestHelpers.o ) *** Parser [TestHelpers]: Parser [TestHelpers]: alloc=5469952 time=2.325 *** Renamer/typechecker [TestHelpers]: Renamer/typechecker [TestHelpers]: alloc=94049744 time=106.001 *** Desugar [TestHelpers]: Desugar [TestHelpers]: alloc=5551840 time=2.974 *** Simplifier [TestHelpers]: Simplifier [TestHelpers]: alloc=45720248 time=28.537 *** Specialise [TestHelpers]: Specialise [TestHelpers]: alloc=2198344 time=0.717 *** Float out(FOS {Lam = Just 0, Consts = True, OverSatApps = False}) [TestHelpers]: Float out(FOS {Lam = Just 0, Consts = True, OverSatApps = False}) [TestHelpers]: alloc=6183280 time=3.109 *** Simplifier [TestHelpers]: Simplifier [TestHelpers]: alloc=27272104 time=16.042 *** Simplifier [TestHelpers]: Simplifier [TestHelpers]: alloc=20805544 time=12.332 *** Simplifier [TestHelpers]: Simplifier [TestHelpers]: alloc=6175584 time=2.825 *** Float inwards [TestHelpers]: Float inwards [TestHelpers]: alloc=26272 time=0.012 *** Called arity analysis [TestHelpers]: Called arity analysis [TestHelpers]: alloc=28392 time=0.012 *** Simplifier [TestHelpers]: Simplifier [TestHelpers]: alloc=14755744 time=7.017 *** Demand analysis [TestHelpers]: Demand analysis [TestHelpers]: alloc=2061096 time=1.296 *** Constructed Product Result analysis [TestHelpers]: Constructed Product Result analysis [TestHelpers]: alloc=466968 time=0.197 *** Worker Wrapper binds [TestHelpers]: Worker Wrapper binds [TestHelpers]: alloc=436552 time=0.201 *** Simplifier [TestHelpers]: Simplifier [TestHelpers]: alloc=31897488 time=18.652 *** Exitification transformation [TestHelpers]: Exitification transformation [TestHelpers]: alloc=29808 time=0.013 *** Float out(FOS {Lam = Just 0, Consts = True, OverSatApps = True}) [TestHelpers]: Float out(FOS {Lam = Just 0, Consts = True, OverSatApps = True}) [TestHelpers]: alloc=5508568 time=4.009 *** Common sub-expression [TestHelpers]: Common sub-expression [TestHelpers]: alloc=27896 time=0.013 *** Float inwards [TestHelpers]: Float inwards [TestHelpers]: alloc=26272 time=0.021 *** Simplifier [TestHelpers]: Simplifier [TestHelpers]: alloc=24835440 time=15.291 *** Demand analysis [TestHelpers]: Demand analysis [TestHelpers]: alloc=2214560 time=1.044 *** CoreTidy [TestHelpers]: CoreTidy [TestHelpers]: alloc=2814672 time=1.457 *** CorePrep [TestHelpers]: CorePrep [TestHelpers]: alloc=1965920 time=2.636 *** CoreToStg [TestHelpers]: CoreToStg [TestHelpers]: alloc=3134560 time=1.484 *** CodeGen [TestHelpers]: CodeGen [TestHelpers]: alloc=80232584 time=46.410 *** WriteIface [/home/dburke/rdf/temp/dist-newstyle/build/x86_64-linux/ghc-9.2.4/swish-0.10.2.0/t/test-rdfproof/build/test-rdfproof/test-rdfproof-tmp/TestHelpers.hi]: WriteIface [/home/dburke/rdf/temp/dist-newstyle/build/x86_64-linux/ghc-9.2.4/swish-0.10.2.0/t/test-rdfproof/build/test-rdfproof/test-rdfproof-tmp/TestHelpers.hi]: alloc=1780688 time=0.766 *** systool:as: systool:as: alloc=137200 time=0.360 [2 of 2] Compiling Main ( tests/RDFProofTest.hs, /home/dburke/rdf/temp/dist-newstyle/build/x86_64-linux/ghc-9.2.4/swish-0.10.2.0/t/test-rdfproof/build/test-rdfproof/test-rdfproof-tmp/Main.o ) *** Parser [Main]: Parser [Main]: alloc=25235720 time=8.851 *** Renamer/typechecker [Main]: Renamer/typechecker [Main]: alloc=58415520 time=45.291 *** Desugar [Main]: Desugar [Main]: alloc=22098688 time=46.709 *** Simplifier [Main]: Simplifier [Main]: alloc=654052760 time=511.390 *** Specialise [Main]: Specialise [Main]: alloc=44439912 time=34.132 *** Float out(FOS {Lam = Just 0, Consts = True, OverSatApps = False}) [Main]: Float out(FOS {Lam = Just 0, Consts = True, OverSatApps = False}) [Main]: alloc=208317448 time=252.154 *** Simplifier [Main]: Simplifier [Main]: alloc=601002912 time=546.343 *** Simplifier [Main]: Simplifier [Main]: alloc=564371608 time=546.970 *** Simplifier [Main]: Simplifier [Main]: alloc=726902400 time=613.423 *** Float inwards [Main]: Float inwards [Main]: alloc=23720 time=0.024 *** Called arity analysis [Main]: Called arity analysis [Main]: alloc=25856 time=0.013 *** Simplifier [Main]: At this point my laptop just sits there making whooshing noises as if it's trying to become an aeroplane, but it never gets to where it's going (to mix up my metaphors). Any help would be appreciated, Doug

2 2

Getting a breakdown of time spend in compile phases
by rowan goemans 04 Sep '22

04 Sep '22

Dear Cafe, I have a Haskell Project where I have a module that quite heavily makes use of constraints and takes ages to compile per module. It also uses some type checker plugins but I'm unsure if they are causing the slowness. So what I would like to see is a breakdown of how much time GHC is spending on compilation of a module. Does something like this exist? Best regards, Rowan Goemans

5 6

[ANN] xmonad and xmonad-contrib 0.17.1 are available
by Tony Zorman 03 Sep '22

03 Sep '22

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ XMONAD AND XMONAD-CONTRIB 0.17.1 ARE AVAILABLE ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ New versions of xmonad and xmonad-contrib have been released. Check out our [download page] for instructions on where to get them. About 10 months after the big release of 0.17.0, we—as promised—picked up the pace a bit and are back with a new minor version; don't let that fool you though, this one still packs a punch! Plus, we now sport a brand-new [logo], courtesy of [Hans Heintze]. As this is a minor release, we tried to keep the breaking changes to a minimum (xmonad core does not have a single one!) However, some were unavoidable for `xmonad-contrib', so be sure to at least glance at the [release notes]! For help getting started—or more info—see [our website] and [talk to us]! If you like what we do, you can support us on [Open Collective] or via [GitHub Sponsors]. Thanks! [GitHub Sponsors] <https://github.com/sponsors/xmonad> [Hans Heintze] <https://github.com/literallyunplayable> [Open Collective] <https://opencollective.com/xmonad> [download page] <https://xmonad.org/download.html> [logo] <https://xmonad.org/images/logo.svg> [our website] <https://xmonad.org/> [release notes] See section 2 [talk to us] <https://xmonad.org/community.html> 1 xmonad 0.17.1 ═══════════════ This release includes 32 non-merge commits by 6 contributors! For a full summary of all the changes, see [xmonad's CHANGES.md] file. [xmonad's CHANGES.md] <https://github.com/xmonad/xmonad/blob/v0.17.1/CHANGES.md> 1.1 Enhancements ──────────────── • Added custom cursor shapes for resizing and moving windows. 1.2 Bug Fixes ───────────── • Change the main loop to try to avoid [GHC bug 21708] on systems running GHC 9.2 up to version 9.2.3. The issue has been fixed in [GHC 9.2.4] and all later releases. • Fixed border color of windows with alpha channel. Now all windows have the same opaque border color. [GHC bug 21708] <https://gitlab.haskell.org/ghc/ghc/-/issues/21708> [GHC 9.2.4] <https://discourse.haskell.org/t/ghc-9-2-4-released/4851> 2 xmonad-contrib 0.17.1 ═══════════════════════ This release includes 212 non-merge commits by 32 contributors! For a full summary of all the changes, see [xmonad-contrib's CHANGES.md] file. [xmonad-contrib's CHANGES.md] <https://github.com/xmonad/xmonad-contrib/blob/v0.17.1/CHANGES.md> 2.1 Breaking Changes ──────────────────── • `XMonad.Config.{Arossato,Dmwit,Droundy,Monad,Prime,Saegesser,Sjanssen}': deprecated all of these modules. The user-specific configuration modules may still be found [on the website]. • `XMonad.Util.NamedScratchpad': scratchpads are now only based on the argument given to `namedScratchpadManageHook'; all other scratchpad arguments are, while still present, ignored. Users passing all of their scratchpads to functions like `namedScratchpadAction' (as is shown in the module's documentation) should /not/ notice any difference in behaviour. • `XMonad.Util.DynamicScratchpads': deprecated the module; use the new dynamic scratchpad functionality of `XMonad.Util.NamedScratchpad' instead. • `XMonad.Hooks.UrgencyHook': deprecated `urgencyConfig'; use `def' from the new `Default' instance of `UrgencyConfig' instead. [on the website] <https://xmonad.org/configurations.html> 2.2 New Modules ─────────────── • `XMonad.Hooks.Modal': a module implementing modal keybindings for XMonad. • `XMonad.Layout.SideBorderDecoration': this module allows for having a configurable border position around windows; i.e., it can move the border to either cardinal direction. • `XMonad.Actions.PerLayoutKeys': a new module for customising keybindings on a per-layout basis. • `XMonad.Actions.RepeatAction': a module for adding a keybinding to repeat the last action, similar to Vim's `.' or Emacs's `dot-mode'. 2.3 Bug Fixes and Minor Changes ─────────────────────────────── • `XMonad.Prompt' and `XMonad.Actions.TreeSelect': added xft-based font fallback support. This may be used by appending other fonts to the given string: `xft:iosevka-11,FontAwesome-9'. Note that this requires `xmonad-contrib' to be compiled with `X11-xft' version 0.3.4 or higher. • `XMonad.Util.Run': added an EDSL—particularly geared towards programs like terminals or Emacs—to spawn processes from XMonad in a compositional way. • `XMonad.Util.Hacks': added `trayerPaddingXmobarEventHook' (plus generic variants for other trays/panels) to communicate trayer resize events to xmobar so that padding space may be reserved on xmobar for the tray. Requires `xmobar' version 0.40 or higher. • `XMonad.Prompt.OrgMode': added the ability to specify alphabetic (`#A', `#B', and `#C') [priorities] at the end of the input note. • `XMonad.Actions.Submap': added `visualSubmap' to visualise the available keys and their actions when inside a submap. • `XMonad.Util.NamedScratchpad': added support for dynamic scratchpads in the form of `dynamicNSPAction' and `toggleDynamicNSP'. • `XMonad.Hooks.WindowSwallowing': fixed windows getting lost when used in conjunction with `smartBorders' and a single window. [priorities] <https://orgmode.org/manual/Priorities.html> -- Tony Zorman | https://tony-zorman.com/

1 0

Re: [Haskell-cafe] selectively allow alternatives in a sum type
by Olaf Klinke 02 Sep '22

02 Sep '22

> Trees that grow is essentially this, but using type families. > > data Foo ksi > = LeftFoo !(XLeftFoo ksi) !A > | RightFoo !(XRightFoo ksi) !B > > type family XLeftFoo ksi :: Type > type family XRightFoo ksi :: Type > > Then you can define > > data Both > type instance XLeftFoo Both = () > type instance XRightFoo Both = () > > or > > data OnlyLeft > type instance XLeftFoo OnlyLeft = () > type instance XRightFoo OnlyLeft = Void > > --- > > Third option is to simply have parametrized data: > > data Foo b > = LeftFoo !A > | RIghtFoo !b > > type FooBoth = Foo B > type FooOnlyLeft = Foo Void > > --- > > Sometimes I prefer a higher-kinded data approach, especially if there is > very little variants needed, and they are "uniform" (e.g. second variant > doesn't have some fields). > Yet, sometimes simple parameterized data is simplest approach > (especially as you get stuff for free by deriving Traversable!). > > On the other hand, if type is big and have many uniform extension points > (even if there are few different combinations), then HKD becomes > boilerplate heavy as well. > The drawback of TTG, is that writing polymorphic code (i.e. which work > for any or some `ksi`s) is not very fun: a lot of equality constraints etc. > > - Oleg So I re-discovered Trees that Grow sans the trick of using type families to name particular combinations of parameters. Hooray Najd, and thanks Oleg for bringing this up. Olaf

5 6

ANN: hledger 1.27
by Simon Michael 02 Sep '22

02 Sep '22

I'm pleased to announce hledger 1.27 ! https://github.com/simonmichael/hledger/releases/1.27 https://hledger.org/install https://hledger.org/release-notes.html#hledger-1-27 Highlights include inferring costs from equity postings, new error checks, and improved error messages. Thank you to release contributors Stephen Morgan, Alex Hirzel, Pranesh Prakash, David D Lowe, Charlotte Van Petegem, Max Thomas, Andrew Lelechenko. What is hledger ? - Fast, reliable, free, multicurrency, double-entry, plain text accounting[1] software that runs on unix, mac, windows, and the web - Built around human-readable, version-controllable plain text files - Inspired by and largely compatible with Ledger CLI[2]; convertible to and from Beancount[3] - Written in Haskell for correctness and longevity. For help getting started, or more info, see https://hledger.org and join our chat via Matrix or IRC: https://hledger.org/support Newcomers, experts, contributors, sponsors, feedback are welcome! Aloha, -Simon [1] https://plaintextaccounting.org [2] https://ledger-cli.org [3] https://beancount.github.io

1 0

STATUS_DLL_NOT_FOUND from HLS 1.7 on Windows 10/11
by J. Garrett Morris 31 Aug '22

31 Aug '22

Dear cafe, A few of my students have encountered a problem running HLS 1.7 on Windows 10/11. Their Haskell installations mostly seem okay---everything installed by `ghcup` (1.8) , and `cabal` (3.6.2) and `ghc` (9.2.2) work as expected. However, when VS Code (via the Haskell plugin) attempts to start the language server, it exits repeatedly with error STATUS_DLL_NOT_FOUND (or its signed integer equivalent). Has anyone encountered a configuration that leads to this problem before? Most of the students are not having this problem (nor am I, on similar software configurations), so I suspect it's a consequence of something else they have installed. Thanks, /g -- Prosperum ac felix scelus virtus vocatur -- Seneca

1 0

Re: [Haskell-cafe] selectively allow alternatives in a sum type
by Olaf Klinke 31 Aug '22

31 Aug '22

> Dear Café, > > Is there prior art/existing packages for the following? Is it maybe functional programming folklore? Is it a sign of bad program design? > Sometimes I feel the need to selectively allow or disallow alternatives > in a sum type. That is, suppose we have a sum type > > data Foo = LeftFoo !A | RightFoo !B > > and at some places in the program we want the type system to enforce > that only the constructor LeftFoo can be used. My solution would be to > make the type higher rank: > > data Foo' f = LeftFoo' !A | RightFoo' !(f B) > type Foo = Foo' Identity > type LeftFoo = Foo' (Const' Void) -- can not construct a RightFoo' > > The advantage over defining LeftFoo as an entirely different type is > that Foo and LeftFoo can share functions operating entirely on the left > option. > > Olaf Henning and Will both suggested accessor type classes. I am fond of my solution because it uses plain algebraic data types, no classes, GADTs or type-level lists. David, can you elaborate how this collides with Coercible? What surprised me is that when writing a function f :: LeftFoo -> r GHC did not warn me (-Wincomplete-patterns) about missing cases when f only uses the LeftFoo' pattern match. Hence the fact that RightFoo' :: Const Void B -> LeftFoo is the empty function must somehow be known to the compiler. Nice! Olaf

1 0

Package takeover request for fgl
by Troels Henriksen 30 Aug '22

30 Aug '22

I am requesting to take over the package fgl: https://hackage.haskell.org/package/fgl It is currently broken in GHC 9.4, which is fixed by this pull request: https://github.com/haskell/fgl/pull/104 The maintainer Ivan Miljenovic has not been active on GitHub since January. I wrote Ivan on August 12th offering to help out with maintenance, but have received no response yet. The package is part of the 'haskell' organisation on GitHub. I don't know whether that is supposed to signify some kind of "community maintenance" (it appears Ivan is not the original author of fgl), but I would eventually need Hackage upload rights as well.

2 1

selectively allow alternatives in a sum type
by Olaf Klinke 30 Aug '22

30 Aug '22

Dear Café, Is there prior art/existing packages for the following? Is it maybefunctional programming folklore? Is it a sign of bad program design? Sometimes I feel the need to selectively allow or disallow alternatives in a sum type. That is, suppose we have a sum type data Foo = LeftFoo !A | RightFoo !B and at some places in the program we want the type system to enforce that only the constructor LeftFoo can be used. My solution would be to use a strict version of Data.Functor.Const and make the type higher rank: newtype Const' a b = Const' !a -- Const' Void b ~ Void -- Const' () b ~ () data Foo' f = LeftFoo' !A | RightFoo' !(f B) type Foo = Foo' Identity type LeftFoo = Foo' (Const' Void) -- can not construct a RightFoo' The advantage over defining LeftFoo as an entirely different type is that Foo and LeftFoo can share functions operating entirely on the left option. Olaf

6 6

With cabal.project, what's the story about warning and -Werror compiler flags?
by Nicolas Trangez 30 Aug '22

30 Aug '22

All, Working on some project, I was wondering about best-practices and community standards for compiler flags now that `cabal.project` is a thing. Before, I put compiler warning flags like `-Wall` in `Ghc-Options` and `Cc-Options` in `mypackage.cabal` files. The use of `-Werror`, whilst (IMHO) useful in development and CI was a bit more troublesome, since having those in `package.cabal` (not under a default-disabled flag) was frowned upon (and even not allowed by Hackage?) Having these options in `mypackage.cabal` always felt slightly weird, since they are in no way required for a package to function: they're developer options, not user/consumer options. Where `-wavx2` could be a required `Cc-Options` setting for a package to build/function, `-Wall` is not. With the advent of `cabal.project`, it seems to me this is the ideal place to put developer flags: from what I understood, `cabal.project` doesn't influence sdist/Hackage distribution, and hence could contain all kind of GHC and C compiler flags that are useful during development but not required for a package to build/function, including `-Werror` (if desired by the project authors). Does this sound like a reasonable stance? If it is, I did run into a couple of issues getting things to actually work. Whilst putting `Ghc-Options` in a `Package mypackage` section in `cabal.project` seems to work, I'm unable to achieve the same resulsts for C compiler invocations. Presumably there's a `Gcc-Options` setting one can use (which is also generated in `cabal.project.local` by `cabal configure --gcc-options ...`). However, in testing, it appears said compiler optons are only passed to GCC when compiling, e.g., a HSC2HS file, but not when compiling a C file part of a `C-Sources` setting (whilst `Cc-Options` in `mypackage.cabal` are). Is there some discrepancy between what can be done from `cabal.project` vs. `mypackage.cabal`? Is this intentional? Am I trying to accomplish something that isn't/shouldn't be supported by Cabal in the first place? Cheers, Nicolas

2 5

GHC Proposals session at Haskell Symposium at ICFP
by Joachim Breitner 30 Aug '22

30 Aug '22

Dear friends of GHC, this year’s Haskell Symposium will host a special “GHC Proposals session” where current, future and past GHC Proposals can be presented and discussed: https://icfp22.sigplan.org/home/haskellsymp-2022#GHC-Proposals-Session I invite all GHC Proposal authors (or otherwise interested party) who are in Ljubljana to present your ideas and plans; just e-mail me if you want a slot. I also invite everyone else – users, developers, educators – to join the session for the discussions of these proposals. Your chance to get your voice heard, and not just your writing on GitHub! Cheers, Joachim -- Joachim Breitner mail(a)joachim-breitner.de http://www.joachim-breitner.de/

1 0

[ANN] mtl-2.3.1-rc1
by Emily Pillmore 30 Aug '22

30 Aug '22

Hi Everyone, mtl-2.3.1-rc1 ( https://github.com/haskell/mtl/releases/tag/v2.3.1-rc1 ) is up on Github. We'll give this a 2 week window for issues relating to the changelog, and then do a release. Please review and upgrade if you're interested. Backported is also a migration doc for people interested in migrating to mtl-2.3. You can find it in the repo. Special thanks to Koz and everyone else who contributed. Cheers, E

1 0

Three Haskell roles with Core Strats at Standard Chartered
by José Pedro Magalhães 28 Aug '22

28 Aug '22

Core Strats at Standard Chartered Bank are hiring Haskell developers again. We're currently looking for three developers, and we're flexible with regards to seniority / experience. The head of our group has given a talk at the Haskell Implementer’s Workshop last year where he described the team and what we do: https://www.youtube.com/watch?v=A70SN7vFsKU These roles are specifically for Applications & Services development, so expect some GUI work and plenty of stakeholder interaction. Applications should go via these links: Warsaw: https://scb.taleo.net/careersection/ex/jobdetail.ftl?job=2200023433 for direct employment, or CoreStratsRoles(a)sc.com for contracting London: https://scb.taleo.net/careersection/ex/jobdetail.ftl?job=2200023448 Singapore: https://scb.taleo.net/careersection/ex/jobdetail.ftl?job=2200017272 Shanghai: reach out to CoreStratsRoles(a)sc.com The Warsaw position is open to both contractors and direct employment, whereas the others are only open for direct employment. Standard Chartered supports (practically fully) remote working, but only from the country of payroll, and after an initial 3-month in-office period. We cover visa and relocation costs for successful employment applicants. Note that the first step of the application is a Valued Behaviours Assessment and it is quite important: our team won’t be able to see your application until you pass this assessment. Feel free to contact us at CoreStratsRoles(a)sc.com if you have any questions about these positions.

1 0

Two mysteries
by Henry Laxen 28 Aug '22

28 Aug '22

-- run this with ghci -package microlens-platform -package stm -package containers SC.hs {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE AllowAmbiguousTypes #-} {-# LANGUAGE FlexibleContexts #-} {-# LANGUAGE TemplateHaskell #-} module Games.SC where import qualified Data.Map.Strict as M import GHC.IO.Unsafe ( unsafePerformIO ) import Lens.Micro.Platform import Control.Concurrent.STM.TVar import Control.Concurrent.STM import Control.Monad.IO.Class type Lenstype f a b = (b -> f b) -> a -> f a instance Show a => Show (TVar a) where show x = unsafePerformIO $ do sx <- readTVarIO x return ("TVar: " <> show sx) newtype TMap k v = TMap (TVar (M.Map k (TVar v))) deriving Show -- TMap (TVar (Map k (TVar v))) -- ^^^^ modify this TVar to add/delete a key -- TMap (TVar (Map k (TVar v))) -- ^^^^ modify this TVar to change a value withKey :: (MonadIO m, Ord k) => k -> (Maybe v -> v) -> TMap k v -> m () withKey k f (TMap x) = liftIO $ do atomically $ do tMap <- readTVar x let mbK = M.lookup k tMap case mbK of -- insert a new (key,value) into the map Nothing -> do v' <- newTVar (f Nothing) let newMap = M.insert k v' tMap writeTVar x newMap Just tv -> do -- modify the value of an existing key v' <- readTVar tv let newV = f (Just v') writeTVar tv newV return () class State a where type StateKey a :: * type StateValue a :: * lensTmap :: Functor f => Lenstype f a (TMap (StateKey a) (StateValue a)) lensKey :: Functor f => Lenstype f a (StateKey a) lensCounter :: Functor f => Lenstype f (StateValue a) Int updateState state f = liftIO $ do let key = state ^. lensKey -- read the key mutable = state ^. lensTmap -- find the TVar of the TMap withKey key (\(Just x) -> x & lensCounter %~ f) mutable -- update it -- THE FIRST MYSTERY: If I use the inferred type explicitly for updateState -- above, this no longer compiles. I get a "could not deduce" error -- reproduced below: -- xupdateState -- :: (MonadIO m, Ord (StateKey s), State s, State a, -- StateValue s ~ StateValue a) => -- s -> (Int -> Int) -> m () -- xupdateState state f = liftIO $ do -- let -- key = state ^. lensKey -- read the key -- mutable = state ^. lensTmap -- find the TVar of the TMap -- withKey key (\(Just x) -> x & lensCounter %~ f) mutable -- update it -- /home/henry/nadineloveshenry/projects/nlh/src/Games/SC.hs:84:33-43: error: -- • Could not deduce: StateValue a0 ~ StateValue a -- from the context: (MonadIO m, Ord (StateKey s), State s, State a, -- StateValue s ~ StateValue a) -- bound by the type signature for: -- xupdateState :: forall (m :: * -> *) s a. -- (MonadIO m, Ord (StateKey s), State s, State a, -- StateValue s ~ StateValue a) => -- s -> (Int -> Int) -> m () -- at /home/henry/nadineloveshenry/projects/nlh/src/Games/SC.hs:(76,1)-(79,30) -- Expected type: ASetter (StateValue a) (StateValue a) Int Int -- Actual type: Lenstype -- Data.Functor.Identity.Identity (StateValue a0) Int -- NB: ‘StateValue’ is a non-injective type family -- The type variable ‘a0’ is ambiguous -- • In the first argument of ‘(%~)’, namely ‘lensCounter’ -- In the second argument of ‘(&)’, namely ‘lensCounter %~ f’ -- In the expression: x & lensCounter %~ f -- • Relevant bindings include -- x :: StateValue a -- (bound at /home/henry/nadineloveshenry/projects/nlh/src/Games/SC.hs:84:23) -- mutable :: TMap (StateKey s) (StateValue a) -- (bound at /home/henry/nadineloveshenry/projects/nlh/src/Games/SC.hs:83:5) data SampleState = SampleState { _key :: String , _tMap :: TMap String SampleValue } deriving Show data SampleValue = SampleValue { _counter :: Int , _other :: () } deriving Show $(makeLenses ''SampleState) $(makeLenses ''SampleValue) makeSampleState :: IO SampleState makeSampleState = do let sampleValue = SampleValue 1 () tvar1 <- newTVarIO sampleValue let sampleTMap = M.fromList [("a", tvar1)] tvar2 <- newTVarIO sampleTMap return (SampleState "a" (TMap tvar2)) -- I can show the result of makeSampleState: -- λ> makeSampleState -- SampleState {_key = "a", _tMap = TMap TVar: fromList [("a",TVar: SampleValue {_counter = 1, _other = ()})]} bump1 :: IO () bump1 = do xss <- makeSampleState let xTmap = xss ^. tMap withKey "a" (\(Just x) -> x & counter %~ (+1)) xTmap print xTmap -- Everything here is tickety-boo -- λ> bump1 -- TMap TVar: fromList [("a",TVar: SampleValue {_counter = 2, _other = ()})] -- Now let's make SampleState an instance of State instance State SampleState where type StateKey SampleState = String type StateValue SampleState = SampleValue lensTmap = tMap lensKey = key lensCounter = counter -- THE SECOND MYSTERY: now lets try bump1 with the type family, but there is no joy -- bump2 :: IO () -- bump2 = do -- xss <- makeSampleState -- let xTmap = xss ^. lensTmap -- withKey "a" (\(Just x) -> x & lensCounter %~ (+1)) xTmap -- print xTmap -- SC.hs:163:33-43: error: -- • Couldn't match type ‘StateValue a0’ with ‘SampleValue’ -- Expected type: ASetter SampleValue SampleValue Int Int -- Actual type: Lenstype -- Data.Functor.Identity.Identity (StateValue a0) Int -- The type variable ‘a0’ is ambiguous -- • In the first argument of ‘(%~)’, namely ‘lensCounter’ -- In the second argument of ‘(&)’, namely ‘lensCounter %~ (+ 1)’ -- In the expression: x & lensCounter %~ (+ 1) -- Can someone please explain what is going on, or point me at a book/paper -- Thanks in advance. -- You can load this into ghci and uncomment to "bad" code to see for -- yourself what happens -- Nadine and Henry Laxen The rest is silence Gral. Manuel Márquez de León 1301 Onix #2302 Zona Urban Rio Never try to teach a pig to sing; Tijuana It wastes your time +52 (333) 667-8633 And it annoys the pig

3 3

[ANN] gitlab-haskell 1.0.0.1
by Rob Stewart 23 Aug '22

23 Aug '22

Hi, I'm pleased to announce the release of gitlab-haskell-1.0.0.1 . This library lifts the GitLab web API into Haskell. The library also has an event driven API for implementing server-side GitLab file hooks. This 1.0.0.1 release features: 1. Complete coverage of the GitLab v4 REST API. 2. An extensive suite of unit tests for parsing and serialising GitLab JSON objects. Documentation: https://hackage.haskell.org/package/gitlab-haskell Repository: https://gitlab.com/robstewart57/gitlab-haskell Details of the real-time API for GitLab events: https://www.macs.hw.ac.uk/~rs46/posts/2020-06-06-gitlab-system-hooks.html -- Rob Stewart https://www.macs.hw.ac.uk/~rs46/

1 0

Munich Haskell Meeting, 2022-08-25 @ 19:30
by Leah Neukirchen 22 Aug '22

22 Aug '22

Dear all, This week, our monthly Munich Haskell Meeting will take place again on Wednesday, August 25 at *Hofbräukeller am Wiener Platz* at 19h30. For details see here: http://muenchen.haskell.bayern/dates.html If you plan to join, please add yourself to this dudle so we can look out for you: https://nuudel.digitalcourage.de/haskell-munich-aug-2022 (dudle is broken today, so we use nuudel instead.) Everybody is welcome! cu, -- Leah Neukirchen <leah(a)vuxu.org> https://leahneukirchen.org/

1 0

[ANNOUNCE] GHC 9.4.2 is now available
by Ben Gamari 22 Aug '22

22 Aug '22

The GHC developers are happy to announce the availability of GHC 9.4.2. Binary distributions, source distributions, and documentation are available at downloads.haskell.org: https://downloads.haskell.org/ghc/9.4.2 This release is primarily a bugfix release addressing a few packaging issues found in 9.4.1. See the [release notes] for a full accounting. Note that, as GHC 9.4 is the first release series where the release artifacts are all generated by our new Hadrian build system, it is possible that there will be packaging issues. If you enounter trouble while using a binary distribution, please open a [ticket]. Likewise, if you are a downstream packager, do consider migrating to [Hadrian] to run your build; the Hadrian build system can be built using `cabal-install`, `stack`, or the in-tree [bootstrap script]. See the accompanying [blog post] for details on migrating packaging to Hadrian. We would also like to emphasize that GHC 9.4 must be used in conjunction with Cabal-3.8 or later. This is particularly important for Windows users due to changes in GHC's Windows toolchain. 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. Happy Haskelling, - Ben [ticket]: https://gitlab.haskell.org/ghc/ghc/-/issues/new [bootstrap script]: https://gitlab.haskell.org/ghc/ghc/-/blob/e2520df3fffa0cf22fb19c5fb872832d1… [Hadrian]: https://gitlab.haskell.org/ghc/ghc/-/blob/e2520df3fffa0cf22fb19c5fb872832d1… [release notes]: https://downloads.haskell.org/~ghc/9.4.2/docs/users_guide/9.4.2-notes.html [blog post]: https://www.haskell.org/ghc/blog/20220805-make-to-hadrian.html

1 0

ANN: LeanCheck v1.0.0 – Enumerative Property Testing
by Rudy Matela 22 Aug '22

22 Aug '22

Hello Haskell Café, A new version of LeanCheck <https://hackage.haskell.org/package/leancheck> is out (v1.0.0 <https://hackage.haskell.org/package/leancheck>). LeanCheck is a property testing library (like QuickCheck) that tests values enumeratively. *Example.* Here is a simple example of LeanCheck in action showing that sorting is idempotent and list union is not commutative: > import Test.LeanCheck > import Data.List (sort, union) > check $ \xs -> sort (sort xs) == sort (xs::[Int]) +++ OK, passed 200 tests. > check $ \xs ys -> xs `union` ys == ys `union` (xs::[Int]) *** Failed! Falsifiable (after 4 tests): [] [0,0] LeanCheck works on all types that are instances of the Listable typeclass and is able to derive instances automatically using either Template Haskell or GHC.Generics. See LeanCheck’s Haddock documentation <https://hackage.haskell.org/package/leancheck/docs/Test-LeanCheck.html> for more details. LeanCheck is compatible with Hspec <https://hackage.haskell.org/package/hspec-leancheck>, Tasty <https://hackage.haskell.org/package/tasty-leancheck> and test-framework <https://hackage.haskell.org/package/test-framework-leancheck>. *What's new?* Version 1.0.0 signalizes stability in the API. LeanCheck has not actually changed much in the past couple of years and there are no significant differences between the early 0.9 series. *Installing.* You can find LeanCheck on Hackage <https://hackage.haskell.org/package/leancheck> or GitHub <https://github.com/rudymatela/leancheck>. It is also tracked on Stackage <https://www.stackage.org/package/leancheck>. You can install it with: $ cabal install leancheck – Rudy

1 0

[ANN]: dunai-0.9.0, dunai-test-0.9.0, bearriver-0.13.6
by Ivan Perez 21 Aug '22

21 Aug '22

Hi everyone! I've just released version 0.9.0 of the dunai libraries, which comes with version 0.13.6 of bearriver. For those unfamiliar, dunai is a reactive programming library structured around a notion of Monadic Stream Functions <https://dl.acm.org/doi/abs/10.1145/3241625.2976010>. dunai can be used to implement other reactive and FRP frameworks on top, including Classic FRP and Arrowized FRP variants. bearriver itself is an API-compatible implementation of Yampa. dunai also comes with a QuickCheck-based temporal testing library, and can be connected with the testing system haskell-titan. All versions of GHC from 7.6 to 9.4 are supported. *Release information* This is mainly a maintenance release. Among other changes, this version improves the documentation in dunai-test. Additionally, a function that was exposed unnecessarily is being deprecated in preparation for its future removal. - Release: https://github.com/ivanperez-keera/dunai/releases/tag/v0.9.0. - Hackage: - dunai: https://hackage.haskell.org/package/dunai. - dunai-test: https://hackage.haskell.org/package/dunai-test - bearriver: https://hackage.haskell.org/package/bearriver - Repo: https://github.com/ivanperez-keera/dunai. *Upcoming changes* We are synchronizing releases with the Yampa project to ensure that bearriver incorporates any changes added to Yampa. Additionally, the goal is to eventually use Yampa's tests also to give bearriver full test coverage. Two changes are being discussed that will potentially affect users: - The introduction of a new constraint in VectorSpace in simple-affine-space would alter the type constraints of some functions. See #298 <https://github.com/ivanperez-keera/dunai/issues/298>. - A re-structuring of the API to better reflect the purpose of the implementation. This could also lead to a division of dunai into multiple libraries. See #305 <https://github.com/ivanperez-keera/dunai/issues/305>. The next release is expected to be published on October 21, 2022. Happy Haskelling! Ivan

1 0

[ANNOUNCE] GHC 9.4.1 is now available
by Ben Gamari 21 Aug '22

21 Aug '22

The GHC developers are very pleased to announce the availability of GHC 9.4.1. Binary distributions, source distributions, and documentation are available at downloads.haskell.org: https://downloads.haskell.org/ghc/9.4.1 This release includes: - A new profiling mode, `-fprof-late`, which adds automatic cost-center annotations to all top-level functions *after* Core optimisation has run. This provides informative profiles while interfering significantly less with GHC's aggressive optimisations, making it easier to understand the performance of programs which depend upon simplification.. - A variety of plugin improvements including the introduction of a new plugin type, *defaulting plugins*, and the ability for typechecking plugins to rewrite type-families. - An improved constructed product result analysis, allowing unboxing of nested structures, and a new boxity analysis, leading to less reboxing. - Introduction of a tag-check elision optimisation, bringing significant performance improvements in strict programs. - Generalisation of a variety of primitive types to be levity polymorphic. Consequently, the `ArrayArray#` type can at long last be retired, replaced by standard `Array#`. - Introduction of the `\cases` syntax from [GHC proposal 0302]. - A complete overhaul of GHC's Windows support. This includes a migration to a fully Clang-based C toolchain, a deep refactoring of the linker, and many fixes in WinIO. - Support for multiple home packages, significantly improving support in IDEs and other tools for multi-package projects. - A refactoring of GHC's error message infrastructure, allowing GHC to provide diagnostic information to downstream consumers as structured data, greatly easing IDE support. - Significant compile-time improvements to runtime and memory consumption. - On overhaul of our packaging infrastructure, allowing full traceability of release artifacts and more reliable binary distributions. - Reintroduction of deep subsumption (which was previously dropped with the *simplified subsumption* change) as a language extension. - ... and much more. See the [release notes] for a full accounting. Note that, as 9.4.1 is the first release for which the released artifacts will all be generated by our Hadrian build system, it is possible that there will be packaging issues. If you enounter trouble while using a binary distribution, please open a [ticket]. Likewise, if you are a downstream packager, do consider migrating to [Hadrian] to run your build; the Hadrian build system can be built using `cabal-install`, `stack`, or the in-tree [bootstrap script]. See the accompanying [blog post] for details on migrating packaging to Hadrian. 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. Happy testing, - Ben [GHC proposal 0302]: https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0302-c… [ticket]: https://gitlab.haskell.org/ghc/ghc/-/issues/new [bootstrap script]: https://gitlab.haskell.org/ghc/ghc/-/blob/e2520df3fffa0cf22fb19c5fb872832d1… [Hadrian]: https://gitlab.haskell.org/ghc/ghc/-/blob/e2520df3fffa0cf22fb19c5fb872832d1… [release notes]: https://downloads.haskell.org/~ghc/9.4.1/docs/users_guide/9.4.1-notes.html [blog post]: https://www.haskell.org/ghc/blog/20220805-make-to-hadrian.html

5 6