- Haskell-Cafe - Haskell.org

PLDI 2024 - Call for Participation (Early registration: May 15)
by Yao Li 03 Apr '24

03 Apr '24

Call for Participation for PLDI 2024, the ACM SIGPLAN Conference on Programming Language Design and Implementation! ------------------------------------------------------------------------ PLDI is a premier forum for programming language research, broadly construed, including design, implementation, theory, applications, and performance. Come join us, online or in Copenhagen, Denmark, to discuss the latest programming languages research! * Website : https://pldi24.sigplan.org/attending/registration * Time : Mon 24--Fri 28 June 2024 * Place : Radisson Blu Scandinavia, Amager Boulevard 70, 2300 Copenhagen S, Denmark ### Important dates * Early Registration: 15th of May, 2024 ### Important rates (Registration rates include a 25% VAT; The prices displayed include tax) Registration rates (in-person) On or before 15 May, 2024 After 15 May, 2024 Regular (ACM or SIGPLAN member) €770.00 €850.00 Regular (non-member) €850.00 €935.00 Student (ACM or SIGPLAN member) €425.00 €505.00 Student (non-member) €475.00 €540.00 Registration rates (virtual) On or before 15 May, 2024 After 15 May, 2024 Regular (ACM or SIGPLAN member) €37.50 €50.00 Regular (non-member) €37.50 €50.00 Student (ACM or SIGPLAN member) €37.50 €50.00 Student (non-member) €37.50 €50.00 1-Day Pass (Co-Located events) On or before 15 May, 2024 After 15 May, 2024 Regular (ACM or SIGPLAN member) €225.00 €250.00 Regular (non-member) €250.00 €275.00 Student (ACM or SIGPLAN member) €150.00 €175.00 Student (non-member) €175.00 €200.00 ### Co-located events: Co-located Conferences: - ISMM, ACM SIGPLAN International Symposium on Memory Management https://conf.researchr.org/home/ismm-2024 - LCTES, ACM SIGPLAN/SIGBED International Conference on Languages, Compilers, and Tools for Embedded Systems https://pldi24.sigplan.org/home/LCTES-2024 Workshops: - ARRAY, the Array Programming Workshop https://pldi24.sigplan.org/home/ARRAY-2024 - CP, International Workshop on Choreographic Programming https://pldi24.sigplan.org/home/cp-2024 - EGRAPHS, the E-Graph Research, Applications, Practices, and Human-factors Symposium https://pldi24.sigplan.org/home/egraphs-2024 - Infer, the Infer Practitioners Workshop https://pldi24.sigplan.org/home/infer-2024 - PLMW, the Programming Languages Mentoring Workshop https://pldi24.sigplan.org/track/PLMW-PLDI-2024 - PODELSKI, PLDI 2024 Workshop Honoring Andreas Podelsk https://pldi24.sigplan.org/home/podelski-2024 - RTFM, Red-Hot Topics in Faculty Mentoring https://pldi24.sigplan.org/home/rtfm-2024 - SOAP, the ACM SIGPLAN International Workshop on the State Of the Art in Program Analysis https://pldi24.sigplan.org/home/SOAP-2024 - Sparse, the Sparse workshop (formerly CTSTA) https://pldi24.sigplan.org/home/sparse-2024 - WQS, Workshop on Quantum Software https://pldi24.sigplan.org/home/wqs-2024 Tutorials: https://pldi24.sigplan.org/track/pldi-2024-tutorials - Algorithms and Applications for Provable Repair of Deep Neural Networks Aditya V. Thakur - Concurrent Algorithms in Kotlin Coroutines Nikita Koval - Democratizing DSL development with the BuildIt Framework Ajay Brahmakshatriya, Saman Amarasinghe - PODELSKI Thomas Wies, Martin Schäf, Andrey Rybalchenko - Quick and dirty development of static analyses with LiSA Luca Negrini, Pietro Ferrara - Static Code Analysis with SootUp Eric Bodden, Markus Schmidt, Jonas Klauke, Kadiray Karakaya, Stefan Schott Student Research Competition! https://pldi24.sigplan.org/track/pldi-2024-src ### Student Volunteering Sign up to be a Volunteer and help us make PLDI 2024 a great experience for all attendants! https://pldi24.sigplan.org/track/pldi-2024-student-volunteering Apply here: https://forms.gle/QB9Tdmhr9v9ZPGx9A. The deadline is 15th of April. Best regards, Yao Li, Ph.D., (He/Him) Assistant Professor, Computer Science Department, Portland State University

1 0

Announce: HsShellScript 3.6.4
by Volker Wysk 03 Apr '24

03 Apr '24

Hi! HsShellScript is a library that lets you do your Unix scripting in Haskell. It was outdated with respect to the supported compiler (meaning base- package) version, but now I've ported it to base >= 4.17.0.0 && < 5 (GHC 9.4/9.5). That's the recommended version (as of 2024-04-02). Here's the homepage: https://volker-wysk.de/hsshellscript/ Cheers, Volker

1 0

Hackage: "Build: PlanningFailed"
by Volker Wysk 03 Apr '24

03 Apr '24

Hello I'm fighting with Hackage. To make things short, I've published my HsShellScript library (was a package candidate before). Here's the library's Hackage page: https://hackage.haskell.org/package/hsshellscript-3.6.2 And there's a button labeled "Build: PlanningFailed". When I click on it, I get the following messages under "Build Log": -----snip----- Resolving dependencies... Error: cabal: Could not resolve dependencies: [__0] trying: hsshellscript-3.6.2 (user goal) [__1] next goal: base (dependency of hsshellscript) [__1] rejecting: base-4.18.1.0/installed-4.18.1.0 (conflict: hsshellscript => base>=4.13.0 && <4.14) [__1] skipping: base-4.19.1.0, base-4.19.0.0, base-4.18.2.0, base-4.18.1.0, base-4.18.0.0, base-4.17.2.1, base-4.17.2.0, base-4.17.1.0, base-4.17.0.0, base-4.16.4.0, base-4.16.3.0, base-4.16.2.0, base-4.16.1.0, base-4.16.0.0, base-4.15.1.0, base-4.15.0.0, base-4.14.3.0, base-4.14.2.0, base-4.14.1.0, base-4.14.0.0 (has the same characteristics that caused the previous version to fail: excluded by constraint '>=4.13.0 && <4.14' from 'hsshellscript') [__1] rejecting: base-4.13.0.0, base-4.12.0.0, base-4.11.1.0, base-4.11.0.0, base-4.10.1.0, base-4.10.0.0, base-4.9.1.0, base-4.9.0.0, base-4.8.2.0, base-4.8.1.0, base-4.8.0.0, base-4.7.0.2, base-4.7.0.1, base-4.7.0.0, base-4.6.0.1, base-4.6.0.0, base-4.5.1.0, base-4.5.0.0, base-4.4.1.0, base-4.4.0.0, base-4.3.1.0, base-4.3.0.0, base-4.2.0.2, base-4.2.0.1, base-4.2.0.0, base-4.1.0.0, base-4.0.0.0, base-3.0.3.2, base-3.0.3.1 (constraint from non-upgradeable package requires installed instance) [__1] fail (backjumping, conflict set: base, hsshellscript) After searching the rest of the dependency tree exhaustively, these were the goals I've had most trouble fulfilling: base, hsshellscript -----snip----- Why does it reject the base library? The versions conflict, but why does it think the version should be base-4.18.1.0? The library compiles okay on my machine (using "cabal build"). I have this in the hsshellscript.cabal file, under "build-depends:": base >= 4.13.0 && < 4.14 I've got this version information from calling "cabal gen-bounds". Cheers, Volker

7 20

Cabal: Can only one processor core be used?
by Volker Wysk 02 Apr '24

02 Apr '24

Hi I've searched the web and the cabal user guide on how to use more processor cores for compilation via cabal. I couldn't find anything. It looks like only one processor core can be used with cabal, even though (I've read on the web) GHC supports parallel compilation. Cabal compilation times can be a pain. It can't be that you can use only one processor core with cabal, can it ..? Cheers, Volker

7 9

Cabal install fails, don't understand why
by Volker Wysk 31 Mar '24

31 Mar '24

Hi I've migrated my HsShellScript library to Cabal 3.0 and now I get an error when I try to install it: -----snip----- desktop /usr/local/src/hsshellscript $ cabal install --user Wrote tarball sdist to /usr/local/src/hsshellscript/dist-newstyle/sdist/hsshellscript-3.6.0.tar.gz Resolving dependencies... Error: cabal: Cannot build the executables in the package hsshellscript because it does not contain any executables. Check the .cabal file for the package and make sure that it properly declares the components that you expect. -----snip----- I don't understand this error message. Why does it think it should build executables? There aren't any. It's a library only. The hsshellscript.cabal file is this (comments and description removed): -----snip----- cabal-version: 3.0 name: hsshellscript version: 3.6.0 synopsis: Using Haskell for Unix shell scripting tasks Description: (...) Homepage: http://www.volker-wysk.de/hsshellscript/ license: LGPL-3.0-or-later license-file: LICENSE author: Volker Wysk maintainer: post(a)volker-wysk.de Copyright: (C) 2021-2024 by Volker Wysk category: System build-type: Simple extra-doc-files: CHANGELOG.md, README.md Extra-source-files: Makefile common warnings Library import: warnings Exposed-Modules: HsShellScript HsShellScript.Args HsShellScript.Paths HsShellScript.Shell Other-Modules: HsShellScript.Commands HsShellScript.GetOpt HsShellScript.Misc HsShellScript.ProcErr Default-Extensions: DeriveDataTypeable, ForeignFunctionInterface, RecordWildCards, ScopedTypeVariables, NamedFieldPuns, StandaloneDeriving Build-depends: base ^>=4.13.0.0, directory >= 1.3.6 && < 1.4, unix >= 2.7.2 && < 2.8, parsec >= 3.1.14 && < 3.2, random >= 1.1 && < 1.2 hs-source-dirs: src C-Sources: src/cbits/hsshellscript.c default-language: Haskell2010 source-repository head type: git location: https://gitlab.com/volkerwysk/hsshellscript.git -----snip----- Thanks for any help! Cheers, Volker

5 9

PostDoc in using Formal Methods for finding security vulnerabilities and misconfigurations in business-process-driven systems (Deadline: 2024-04-18)
by Achim D. Brucker 30 Mar '24

30 Mar '24

Dear all, As part of a US funded project, we have an exciting opportunity for a PostDoc in the Security and Trust of Advanced Systems Group at the University of Exeter (UK) to work applying formal methods to enterprise systems: We will use formal methods (e.g., model checking, SMT solving, interactive theorem proving), to analyze business-process-driven (enterprise) systems (e.g., business logic and workflows described a BPMN models). A particular focus will be the analysis of complex compositions of workflows within one organization as well as across multiple organizations. In particular, we will develop novel techniques to detect faults and vulnerabilities (that can be exploited by both internal and external attackers) in complex business-process-driven systems, contributing to protecting critical workflows such as manufacturing or logistics. In such environments, attackers can exploit such faults and vulnerabilities to cause all kinds of harm such as direct financial losses or causing the production of safety or security critical products to stop. Overall, the project aims to develop automated techniques for assessing the risk of business process or workflows as well as finding and mitigating such attacks. This is a unique opportunity for somebody wanting to use/apply formal methods to the security of large enterprise systems. More information and application details can be found at: * <https://jobs.exeter.ac.uk/hrpr_webrecruitment/wrd/run/etrec179gf.open?WVID=…> Application deadline is the 18th of April 2024. Please contact me for more details. Best, Achim -- Prof. Achim Brucker | Chair in Cybersecurity & Head of Group | University of Exeter https://www.brucker.ch | https://logicalhacking.com/blog @adbrucker | @logicalhacking

1 0

[ANNOUNCE] GHC 9.10.1-alpha2 is now available
by Ben Gamari 29 Mar '24

29 Mar '24

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

1 0

Volunteers for ICFP 2024 Artifact Evaluation Committee (AEC)
by Benoit Montagu 25 Mar '24

25 Mar '24

Dear all, We are looking for motivated people to be members of the ICFP 2024 Artifact Evaluation Committee (AEC). Students, researchers and people from the industry or the free software community are all welcome. The artifact evaluation process aims to improve the quality and reproducibility of research artifacts for ICFP papers. In case you want to nominate someone else (students, colleagues, etc.), please send them the nomination form. Nomination form: https://forms.gle/KJAjtDzhm5VLxjVf9 Deadline for nominations: Mon April 8th 2024 For more information, see the AEC webpage: https://icfp24.sigplan.org/track/icfp-2024-artifact-evaluation The primary responsibility of committee members is to review the artifacts submitted corresponding to the already conditionally accepted papers in the main research track. In particular, run the associated tool or benchmark, check whether the results in the paper can be reproduced, and inspect the tool and the data. We expect evaluation of one artifact to take about a full day. Each committee member will receive 2 to 3 artifacts to review. All of the AEC work will be done remotely/online. The AEC will work in June, with the review work happening between June 5th and July 5th. Come join us in improving the quality of research in our field! Best, the Artifact Evaluation chairs: Quentin Stiévenart and Benoît Montagu

1 0

Requesting For Comments for a new simple-dsp library
by Tristan Cacqueray 21 Mar '24

21 Mar '24

Dear cafe and Dr. Henning Thielemann, I'd like to propose a new package named simple-dsp. I couldn't figure out how to use the existing dsp library, so I made my own version featuring a little GUI to try the code in realtime. I'd be happy to contribute this work directly to dsp. My goal is to be able to extract sensible discrete values from a sound input at 60 Hz for video production. I implemented low/band/high pass filters to compute 3 RMS volumes, but the values I'm getting are not sharp enough, e.g. the band pass picks the low end. Ideally I would extract the transient events of the percusive sound and the note pitch of the melodic elements. I have very little understanding of DSP, and I'm sure there are better ways to achieve this goal, so I would appreciate it if someone more experienced could take a look: * Doc: https://tristancacqueray.github.io/simple-dsp/ * Candidate: https://hackage.haskell.org/package/simple-dsp-0.1/candidate * Forum: https://discourse.haskell.org/t/rfc-a-new-simple-dsp-library/9094 Thanks in advance, -Tristan

2 3

my ancient hackage account
by Keith Sheppard 21 Mar '24

21 Mar '24

Hi All, I wrote https://hackage.haskell.org/package/txt-sushi a long long time ago. I'd like to clean some things up and make some improvements. I tried to use the password recovery tool but it said it "wasn't available" for this account. Maybe because it's so old? Can anyone suggest how to recover the account? Thank you, Keith

2 1

Funded PhD Position in Formalizing/Verification of Golang (Application Deadline 2024-03-31)
by Achim D. Brucker 20 Mar '24

20 Mar '24

We have an exciting opportunity for PhD study with myself and Prof. Burkhart Wolff from the Université Paris-Saclay on developing a formal semantics for Go(lang) in Isabelle/HOL. This is part of a new 'double PhD' programme leading to a PhD award from the University of Exeter and the Université Paris-Saclay. More information and application details can be found at: * https://www.exeter.ac.uk/study/pg-research/funding/phdfunding/paris-saclay/ * https://adum.fr/as/ed/voirproposition.pl?site=adumR&matricule_prop=53822#ve… Application deadline is the 31st of March 2024. Please contact me for more details. Best, Achim -- Prof. Achim Brucker | Chair in Cybersecurity & Head of Group | University of Exeter https://www.brucker.ch | https://logicalhacking.com/blog @adbrucker | @logicalhacking

1 0

Utrecht Summer School on Advanced Functional Programming
by Wouter Swierstra 19 Mar '24

19 Mar '24

# Call for Participation SUMMER SCHOOL ON ADVANCED FUNCTIONAL PROGRAMMING Utrecht, the Netherlands, 08 July – 12 July 2024 http://www.afp.school **Please register before June 1st ** ## ABOUT The Advanced Functional Programming summer school has been running for more than ten years. We aim to educate aspiring Haskell programmers beyond the basic material covered by many textbooks. The lectures will cover several more advanced topics regarding the theory and practice of Haskell programming, including topics such as: * lambda calculus; * monads and monad transformers; * lazy evaluation; * generalized algebraic data types; * type families and type-level programming; * concurrency and parallelism. The summer school will be held in Utrecht and consists of a mix of lectures, labs, and a busy social program. ## PREREQUISITES We expect students to have a basic familiarity with Haskell already. You should be able to write recursive functions over algebraic data types, such as lists and trees. There is a great deal of material readily available that covers this material. If you've already started learning Haskell and are looking to take your functional programming skills to the next level, this is the course for you. ## DATES **Registration deadline: June 1st, 2024** School: 08 July – 12 July 2024 ## COSTS 750 euro - Profession registration fee 250 euro - Student registration fee 200 euro - Housing fee We will charge a registration fee of 750 euros (or 250 euros for students) to cover our expenses. If this is problematic for you for any reason at all, please email the organisers and we can try to offer you a discounted rate or a fee waiver. We have a limited number of scholarships or discounts available for students that would not be able to attend otherwise, especially for women and under-represented minorities. ## FURTHER INFORMATION Further information, including instructions on how to register, is available on our website: http://www.afp.school

1 0

Bing/Copilot Answer: "->", has highest precedence for type construction but in general has nuanced precedence order
by John Creighton 17 Mar '24

17 Mar '24

I was asking Bing Copilot questions to better understand the order of precedence in: sequence :: Monad m => [m a] -> m [a] sequence = foldr mcons (return []) where mcons p q = p >>= \x -> q >>= \y -> return (x:y) I noticed that for evaluation (e.g. binding variables to real world data), the left most "->" seems to have it's lambda variables bound first but with regards parsing this left most "->" seems to be the least deeply nested which in a strick language would suggest a low order of precedence. In the summary part of bing's answer, bing actually said that "->" has the highest order of precedence but if you read the whole answer you see it is only for type construction where Bing specifically made claims of the order of precedence and in the other case (parsing & fixity), bing said that the fixity of "->" is not defined in the Haskell 98 report, and nuanced it by saying that the parsing rules depend on both fixity and associativity. Here is my Question to bing: > Related to the above there seems to be ambiguity in the > phrase “order of precedence here”. With regards to evaluation > the order -- in the case of mcons (shown above) -- the “->” > operator seems to get bound first, with real world data. > This suggests a higher order of precedence for “->” than > the other operators. However, with regards to parsing the > operator “->” is associated with less deeply nested brackets, > which in a strict language would suggest a lower order of > precedence, or equivalently in Haskell lingual, a lower fixity. > Fixity is defined in Talb 2 at but this table doesn’t give the > fixity for “->”. www.haskell.org/onlinereport/decls.html#nested *https://www.pearltrees.com/s243a/question-evaluation-questions/id76447605/item582390761 <https://www.pearltrees.com/s243a/question-evaluation-questions/id76447605/i…> * and here is bing's answer: > You’ve raised an interesting point regarding the perceived > ambiguity in the phrase “order of precedence” when it > comes to the -> operator in Haskell. Let’s delve into this > topic and clarify the nuances. > *1. Operator Precedence and Associativity:> * *In Haskell, operator precedence determines > the order in which operators are evaluated. It > ensures that expressions are parsed unambiguously. > * The associativity of an operator determines whether > it is evaluated from left to right (left-associative) or from > right to left (right-associative). > * The -> operator (function type constructor) has a > specific precedence and associativity. *> 2. Function Type Constructor (->) Precedence:**> * *The -> operator has the *highest precedence* among > all operators in Haskell. > It is used to specify a function’s type signature, such > as Int -> Int -> Float. > * Being right-associative, it means that function types > associate from right to left. For example, > Int -> Int -> Float is equivalent to Int -> (Int -> Float). > *3. Parsing and Fixity:**> * *When parsing expressions, Haskell follows specific > rules for each operator, including the -> operator. > * The compiler determines how to group expressions based on the fixity (precedence and associativity) of operators. > * Fixity declarations allow you to control how > operators are parsed. > *Unfortunately, the Haskell 98 Report does not > explicitly list the fixity of the -> operator. > *4. Custom Operators and Readability:**> * *Custom operators (including symbolic ones) > can indeed decrease readability and maintainability. > * When encountering unfamiliar operators, it’s > challenging to deduce their meaning solely from > their names. > * The arbitrary-looking names lack hints for understanding > their purpose, especially for newcomers. > 5. *Using $ to Clarify Expressions:**> * *The $ operator is defined with very low precedence. > * Writing f $ x is equivalent to f x, but it helps avoid > parentheses. > * By using $, you can explicitly indicate the evaluation > order without relying on operator precedence. > *6. Conclusion:**> * *While the -> operator has the highest precedence, > its behavior is influenced by associativity and context. > * Fixity declarations (such as infixr 0 ->) can help > control how operators are parsed. > * Understanding operator behavior and using $ judiciously > can lead to more idiomatic and maintainable code. > > In summary, the -> operator’s precedence is indeed high, > but its behavior is nuanced due to associativity and > parsing rules. Fixity declarations and careful usage of > operators contribute to code clarity. > > For more details, refer to the Haskell 98 Report. > > Feel free to ask if you have further questions or need additional clarification! 😊 >Learn more > 1 https://stackoverflow.com/questions/23553139/operator-and-function-preceden… > 2 https://www.haskellsos.com/basics/what-order-would-haskell-evaluate-2-opera… > 3 https://devhubby.com/thread/what-is-the-precedence-of-and-in-haskell > 4 https://studentprojectcode.com/blog/how-to-change-precedence-of-constructor… > 5 https://stackoverflow.com/questions/3125395/haskell-operator-vs-function-pr… > 6 https://stackoverflow.com/questions/56202894/what-is-the-precedence-of-and-… > 7 https://codereview.stackexchange.com/questions/120900/expression-parser-in-… > 8 https://kowainik.github.io/posts/fixity > 9 https://devtut.github.io/haskell/infix-operators.html > 10 https://www.haskell.org/onlinereport/decls.html https://sl.bing.net/gHzlncNjtLw https://www.pearltrees.com/s243a/question-evaluation-questions/id76447605/i… I wonder how people would rate Bing's answer.

4 3

Bing/Copilot Answer: "->", has highest precedence for type construction but in general has nuanced precedence order
by Olaf Klinke 17 Mar '24

17 Mar '24

Next time ask GHCi first. (Perhaps you did, but wanted to learn Copilot's opinion anyways): ghci> :info (->) data (->) (a :: TYPE q) (b :: TYPE r) -- Defined in ‘GHC.Prim’ infixr -1 -> ghci> :type (->) <interactive>:1:2: error: parse error on input ‘->’ So while (->) as a type-level function is an infix operator with a precedence, there is no such operator on the term level, otherwise the :type query would have shown it. That the term-level -> is not an operator arguably makes it a lot harder to obtain proper information about. The relevant part of the language documentation I think is this: https://www.haskell.org/onlinereport/exps.html Olaf

1 0

Call for Papers: OOPSLA 2024
by Umar Farooq 15 Mar '24

15 Mar '24

======================================================================== PACMPL Issue OOPSLA 2024 Call for Papers OOPSLA 2024 will be held as part of The ACM Conference on Systems, Programming, Languages, and Applications: Software for Humanity (SPLASH'24) October 20-25, 2024, Pasadena, California, United States https://2024.splashcon.org/track/splash-2024-oopsla ======================================================================== ### Important dates #### ROUND 2: Submission Deadline: Fri Apr 5, 2024 Author Response: Mon Jun 3 - Wed Jun 5, 2024 Author Notification: Fri Jun 21, 2024 Artifact Submission: Fri Jul 5, 2024 Artifact kick-tires: Sat Jul 6 - Fri Jul 19, 2024 Submission of Revisions: Sun Aug 4, 2024 Author Notification of Revisions: Sun Aug 18, 2024 Artifact Notification: Fri Aug 23, 2024 Camera Ready: Sun Sep 1, 2024 Papers accepted at either of the rounds will be published in the 2024 volume of PACMPL(OOPSLA) and invited to be presented at the SPLASH conference in October 2024. ### 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, modelling, 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 with submission deadlines around October and April each year. As you submit your paper you will receive around three reviews and an opportunity to provide an author response that will be read and addressed by the reviewers in the final decision outcome summary. There are 5 possible outcomes at the end of the round: *Accept*: Your paper will appear in the upcoming volume of PACMPL (OOPSLA). *Conditional Accept*: You will receive a list of required revisions that you will need to address. You must submit a revised paper, a clear explanation of how your revision addresses these comments, and "if possible" a diff of the PDF as supplementary material. Assuming you meet the listed requirements, after further review by the same reviewers, your paper will very likely be accepted. This process *has to be completed within two months of the initial decision* for the paper to be accepted, so we encourage timely turnaround in case revisions take more than one cycle to be accepted. *Minor Revision*: The reviewers have concerns that go beyond what can be enumerated in a list. Therefore, while you may receive a list of revisions suggested by the reviewers, this will not necessarily be comprehensive. You will have the opportunity to resubmit your revised paper and have it re-reviewed by the same reviewers, which may or may not result in your paper's acceptance. When you resubmit, you should clearly explain how the revisions address the comments of the reviewers, by including a document describing the changes and "if possible" a diff of the PDF as supplementary material. This process *has to be completed within two months of the initial decision* for the paper to be accepted in the current round, so we encourage timely turnaround in case revisions take more than one cycle to be accepted. *Major Revision*: You will receive a list of revisions suggested by the reviewers. 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 you resubmit, you should clearly explain how the revisions address the comments of the reviewers, by including a document describing the changes and "if possible" a diff of the PDF as supplementary material. The revised paper will be re-evaluated in the next round. Resubmitted papers will retain the same reviewers throughout the process to the extent possible. *Reject*: Rejected papers will not be included in the upcoming volume of PACMPL(OOPSLA). Papers in this category are not guaranteed a review if resubmitted less than one year from the date of the original submission. A paper will be judged to be a resubmission if it is substantially similar to the original submission. The Chairs will decide whether or not a paper is a resubmission of the same work. ### 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. Please note that the artifact submission deadline will be following closely the paper submission deadline so make sure you check the Artifact Call as soon as you submit your paper to PACMPL(OOPSLA). ##### Data-Availability Statement To help readers find data and software, OOPSLA recommends adding a section just before the references titled Data-Availability Statement. If the paper has an artifact, cite it here. If there is no artifact, this section can explain how to obtain relevant code. The statement does not count toward the OOPSLA 2024 page limit. It may be included in the submitted paper; in fact we encourage this, even if the DOI is not ready yet. Example: \section{Conclusion} .... \section*{Data-Availability Statement} The software that supports~\cref{s:design,s:evaluation} is available on Software Heritage~\cite{artifact-swh} and Zenodo~\cite{artifact-doi}. \begin{acks} .... #### Expert PC Members During the submission, we will ask you to list up to 3 non-conflicted PC members who you think are experts on the topic of this submission, starting with the most expert. This list will not be used as an input during the paper assignment and it will not be visible to the PC. It may be used by the PC Chair and Associate Chairs for advice on external experts if the paper lacks expert reviews. ### 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 USD), but payment is not required. The official publication date is the date the journal is 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. The official publication date affects the deadline for any patent filings related to published work. By submitting your article to an ACM Publication, you are acknowledging that you and your co-authors are subject to all [ACM Publications Policies](https://www.acm.org/publications/policies), including ACM’s [new Publications Policy on Research Involving Human Participants and Subjects](https://www.acm.org/publications/policies/research-involving-huma…. Alleged violations of this policy or an ACM Publications Policy will be investigated by ACM and may result in a full retraction of your paper, in addition to other potential penalties, as per ACM Publications Policy. Please ensure that you and your co-authors obtain [an ORCID ID](https://orcid.org/register), so you can complete the publishing process for your accepted paper. ACM has been involved in ORCID from the start and we have recently made a [commitment to collect ORCID IDs from all of our published authors](https://authors.acm.org/author-resources/orcid-faqs). We are committed to improving author discoverability, ensuring proper attribution and contributing to ongoing community efforts around name normalization; your ORCID ID will help in these efforts. The ACM Publications Board has recently updated the ACM Authorship Policy in several ways: - Addressing the use of generative AI systems in the publications process - Clarifying criteria for authorship and the responsibilities of authors - Defining prohibited behaviour, such as gift, ghost, or purchased authorship - Providing a linked FAQ explaining the rationale for the policy and providing additional details You can find the updated policy here: [https://www.acm.org/publications/policies/new-acm-policy-on-authorship](htt… ##### Review Committee Review Committee Chairs: Alex Potanin, Australian National University, Australia Bor-Yuh Evan Chang, University of Colorado Boulder, USA Review Committee Associate Chairs: Anders Møller, Aarhus University, Denmark Lingming Zhang, UIUC, USA Review Committee: Aleksandar Nanevski, IMDEA Software Institute, Spain Alex Summers, University of British Columbia, Canada Alexandra Bugariu, ETH Zurich, Switzerland Ana Milanova, Rensselaer Polytechnic Institute, USA Andreas Zeller, CISPA Helmholtz Center for Information Security, Germany Anitha Gollamudi, UMass, USA Ankush Desai, AWS, USA Ashish Tiwari, Microsoft Research, USA Ben Hermann, TU Dortmund, Germany Ben Titzer, CMU, USA Benjamin Delaware, Purdue University, USA Bernardo Toninho, Universidade Nova de Lisboa, Portugal Bruno C. d. S. Oliveira, U. Hong Kong, Hong Kong Burcu Kulahcioglu Ozkan, Delft University of Technology, The Netherlands Casper Bach Poulsen, Delft University of Technology, Netherlands Colin Gordon, Drexel University, USA Corina Pasarenau, NASA, USA Cyrus Omar, University of Michigan, USA Damien Zufferey, Sonar Source, Switzerland Dana Drachsler Cohen, Technion, Israel David Darais, Galois, USA David Pearce, ConsenSys, New Zealand Di Wang, Peking University, China Emma Söderberg, Lund University, Sweden Emma Tosch, Northeastern University, USA Fabian Muehlboeck, Australian National University, Australia Fei He, Tsinghua University, China Filip Niksic, Google, USA Fredrik Kjolstad, Stanford University, USA Guido Salvaneschi, University of St. Gallen, Switzerland Hila Peleg, Technion, Israel Jiasi Shen, The Hong Kong University of Science and Technology, China (Hong Kong) Jonathan Bell, Northeastern University, USA Jonathan Brachthäuser, University of Tübingen, Germany Joseph Tassarotti, New York University, USA Justin Hsu, Cornell University, USA Karine Even-Mendoza, King's College London, UK Kenji Maillard, Inria Rennes, France Matthew Flatt, U. Utah, USA Matthew Parkinson, Microsoft, UK Max Schaefer, GitHub, UK Michael Coblenz, UCSD, USA Milos Gligoric, UT Austin, USA Minseok Jeon, Korea University, Korea Mohamed Faouzi Atig, Uppsala University, Sweden Owolabi Legunsen, Cornell University, USA Pamela Zave, AT&T Laboratories, USA Pavel Panchekha, University of Utah, USA Rahul Gopinath, University of Sydney, Australia Rajiv Gupta, UC Riverside, USA Saman Amarasinghe, MIT, USA Santosh Pande, Georgia Institute of Technology, USA Sean Treichler, NVIDIA, USA Shachar Itzhaky, Technion, Israel Shaz Qadeer, Facebook, USA Sheng Chen, University of Louisiana at Lafayette, USA Shigeru Chiba, University of Tokyo, Japan Shriram Krishnamurthi, Brown University, USA Sreepathi Pai, University of Rochester, USA Stefan Brunthaler, University of the Federal Armed Forces in Munchen, Germany Steve Blackburn, Google, Australia Subhajit Roy, IIT Kanpur, India Sukyoung Ryu, KAIST, Korea Swarnendu Biswas, IIT Kanpur, India Thanh Vu Nguyen, George Mason University, USA Tiark Rompf, Purdue, USA Tien Nguyen, University of Texas at Dallas, USA Tomas Petricek, Charles University, Czech Republic Umut Acar, CMU, USA Wei Le, Iowa State, USA Wei Zhang , Meta, USA Xiaokang Qiu, Purdue University, USA Yingfei Xiong, Peking University, China Yizhou Zhang, University of Waterloo, Canada Youyou Cong, Tokyo Institute of Technology, Japan Yu David Liu, Binghamton, USA Yu Feng, UCSB, USA Yuepeng Wang, Simon Fraser University, Canada ##### Artifact Evaluation Committee Artifact Evaluation Committee Chairs: Guillaume Baudart, Inria - École normale supérieure, France Sankha Narayan Guria, University of Kansas, USA

1 0

[ANNOUNCE] GHC 9.10.1-alpha1 is now available
by Ben Gamari 14 Mar '24

14 Mar '24

The GHC developers are very pleased to announce the availability of the first alpha release of GHC 9.10.1. Binary distributions, source distributions, and documentation are available at https://downloads.haskell.org/ghc/9.10.1-alpha1 We hope to have this release available via ghcup shortly. GHC 9.10 will bring a number of new features and improvements, including: * The introduction of the GHC2024 language edition, building upon GHC2021 with the addition of a number of widely-used extensions. * Partial implementation of the [GHC Proposal #281], allowing visible quantification to be used in the types of terms. * Extension of LinearTypes to allow linear `let` and `where` bindings ([linear-let]) * The implementation of the exception backtrace proposal, allowing the annotation of exceptions with backtraces, as well as other user-defined context [exception backtrace] * Further improvements in the info table provenance mechanism, reducing code size to allow IPE information to be enabled more widely * Javascript FFI support in the WebAssembly backend * Improvements in the fragmentation characteristics of the low-latency non-moving garbage collector. * ... and many more A full accounting of changes can be found in the [release notes]. As always, GHC's release status, including planned future releases, can be found on the GHC Wiki [status]. Many will notice that this release comes a fair bit later than the previously-announced schedule. While this delay has been attributable to a variety factors, the most recent cause is a set of issues with GHC 9.10's binary distributions on Windows (#24542). Instead of continuing to hold up the release process while we sort out this situation, we have instead provided this alpha without the usual assortment of Windows binary distributions. We expect to have this resolved by alpha 2; apologies to eager Windows testers for this delay. We would like to thank GitHub, IOG, the Zw3rk stake pool, Well-Typed, Tweag I/O, Serokell, Equinix, SimSpace, the Haskell Foundation, and other anonymous contributors whose on-going financial and in-kind support has facilitated GHC maintenance and release management over the years. Finally, this release would not have been possible without the hundreds of open-source contributors whose work comprise this release. As always, do give this release a try and open a [ticket] if you see anything amiss. Happy compiling, ~ Ben [release notes]: https://downloads.haskell.org/ghc/9.10.1-alpha1/docs/users_guide/9.10.1-not… [status]: https://gitlab.haskell.org/ghc/ghc/-/wikis/GHC-status [exception backtrace]: https://github.com/ghc-proposals/ghc-proposals/pull/330 [GHC Proposal #281]: https://github.com/ghc-proposals/ghc-proposals/pull/281 [linear let]: https://github.com/ghc-proposals/ghc-proposals/pull/624

1 0

FUNARCH 2024: Call for Papers
by ICFP Publicity 13 Mar '24

13 Mar '24

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

1 0

Call for Papers: ACM Workshop on Functional Software Architecture
by Michael Sperber 13 Mar '24

13 Mar '24

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

1 0

CFP: Haskell Symposium 2024
by J. Garrett Morris 12 Mar '24

12 Mar '24

The ACM SIGPLAN Haskell Symposium 2024 will be co-located with the 2024 International Conference on Functional Programming (ICFP). The Haskell Symposium presents original research on Haskell, discusses practical experience and future development of the language, and promotes other forms of declarative programming. Topics of interest include: - *Language design,* with a focus on possible extensions and modifications of Haskell as well as critical discussions of the status quo; - *Theory,* such as formal semantics of the present language or future extensions, type systems, effects, metatheory, and foundations for program analysis and transformation; - *Implementations,* including program analysis and transformation, static and dynamic compilation for sequential, parallel, and distributed architectures, memory management, as well as foreign function and component interfaces; - *Libraries,* that demonstrate new ideas or techniques for functional programming in Haskell; - *Tools,* such as profilers, tracers, debuggers, preprocessors, and testing tools; - *Applications,* to scientific and symbolic computing, databases, multimedia, telecommunication, the web, and so forth; - *Functional Pearls,* being elegant and instructive programming examples; - *Experience Reports,* to document general practice and experience in education, industry, or other contexts; - *Tutorials,* to document how to use a particular language feature, programming technique, tool or library within the Haskell ecosystem; - *System Demonstrations,* based on running software rather than novel research results. Regular papers should explain their research contributions in both general and technical terms, identifying what has been accomplished, explaining why it is significant, and relating it to previous work, and to other languages where appropriate. *New this year*, talk proposals need not be full-length, and should report work in progress relevant to Haskell language design, theory, tools, or applications. Talk proposals will be evaluated by the PC for novelty and relevance to the Haskell community, but are not expected to include finished results. Talk proposals will not be distributed to attendees, but authors of talk proposals may provide links to materials to be included on the program. Experience reports and functional pearls need not necessarily report original academic research results. For example, they may instead report reusable programming idioms, elegant ways to approach a problem, or practical experience that will be useful to other users, implementers, or researchers. The key criterion for such a paper is that it makes a contribution from which other Haskellers can benefit. It is not enough simply to describe a standard solution to a standard programming problem, or report on experience where you used Haskell in the standard way and achieved the result you were expecting. Like an experience report and a functional pearl, tutorials should make a contribution from which other Haskellers can benefit. What distinguishes a tutorial is that its focus is on explaining an aspect of the Haskell language and/or ecosystem in a way that is generally useful to a Haskell audience. Tutorials for many such topics can be found online; the distinction here is that by writing it up for formal review it will be vetted by experts and formally published. System demonstrations should summarize the system capabilities that would be demonstrated. The proposals will be judged on whether the ensuing session is likely to be important and interesting to the Haskell community at large, whether on grounds academic or industrial, theoretical or practical, technical, social or artistic. Please contact the program chair with any questions about the relevance of a proposal. If your contribution is not a research paper, please mark the title of your experience report, functional pearl, tutorial or system demonstration as such, by supplying a subtitle (Talk Proposal, Experience Report, Functional Pearl, Tutorial Paper, System Demonstration). Submission Details Formatting Submitted papers should be in portable document format (PDF), formatted using the ACM SIGPLAN style guidelines. Authors should use the acmart format, with the sigplan sub-format for ACM proceedings. For details, see: http://www.sigplan.org/Resources/Author/#acmart-format It is recommended to use the review option when submitting a paper; this option enables line numbers for easy reference in reviews. Talk proposals, functional pearls, experience reports, tutorials and demo proposals should be labelled clearly as such. Lightweight Double-blind Reviewing Haskell Symposium 2024 will use a lightweight double-blind reviewing process. To facilitate this, submitted papers must adhere to two rules: - Author names and institutions must be omitted, and - References to authors’ own related work should be in the third person (e.g., not “We build on our previous work” but rather "We build on the work of "). The purpose of this process is to help the reviewers come to an initial judgment about the paper without bias, not to make it impossible for them to discover the authors if they were to try. Nothing should be done in the name of anonymity that weakens the submission or makes the job of reviewing the paper more difficult (e.g., important background references should not be omitted or anonymized). In addition, authors should feel free to disseminate their ideas or draft versions of their paper as they normally would. For instance, authors may post drafts of their papers on the web or give talks on their research ideas. A reviewer will learn the identity of the author(s) of a paper after a review is submitted. Page Limits The length of submissions should not exceed the following limits: - *Regular paper:* 12 pages - *Talk proposals:* 6 pages - *Functional pearl:* 12 pages - *Tutorial:* 12 pages - *Experience report:* 6 pages - *Demo proposal:* 2 pages There is no requirement that all pages are used. For example, a good talk proposal might be two pages, and a functional pearl may be much shorter than 12 pages. In all cases, the list of references is not counted against these page limits. Deadlines - *Paper submission:* 3 June 2024 (Mon) - *Notification:* 5 July 2024 (Fri) - *Camera-ready Deadline:* 18 July 2024 (Thu) Deadlines are end of day Anywhere on Earth (UTC-12) <https://www.timeanddate.com/time/zones/aoe>. Submission Submissions must adhere to SIGPLAN’s republication policy <http://sigplan.org/Resources/Policies/Republication/>, and authors should be aware of ACM’s policies on plagiarism <https://www.acm.org/publications/policies/plagiarism>. Program Committee members are allowed to submit papers, but their papers will be held to a higher standard. The paper submission deadline and length limitations are firm. There will be no extensions, and papers violating the length limitations will be summarily rejected. Papers should be submitted through HotCRP at: https://haskell24.hotcrp.com/ Improved versions of a paper may be submitted at any point before the submission deadline using the same web interface. *Supplementary material:* Authors have the option to attach supplementary material to a submission, on the understanding that reviewers may choose not to look at it. This supplementary material should not be submitted as part of the main document; instead, it should be uploaded as a separate PDF document or tarball. Supplementary material should be uploaded at submission time, not by providing a URL in the paper that points to an external repository. Authors can distinguish between anonymized and non-anonymized supplementary material. Anonymized supplementary material will be visible to reviewers immediately; non-anonymized supplementary material will be revealed to reviewers only after they have submitted their review of the paper and learned the identity of the author(s). *Resubmitted Papers:* authors who submit a revised version of a paper that has previously been rejected by another conference have the option to attach an annotated copy of the reviews of their previous submission(s), explaining how they have addressed these previous reviews in the present submission. If a reviewer identifies him/herself as a reviewer of this previous submission and wishes to see how his/her comments have been addressed, the conference chair will communicate to this reviewer the annotated copy of his/her previous review. Otherwise, no reviewer will read the annotated copies of the previous reviews. Proceedings Accepted papers will be included in the ACM Digital Library. Their authors will be required to choose one of the following options: - Author retains copyright of the work and grants ACM a non-exclusive permission-to-publish license (and, optionally, licenses the work with a Creative Commons license); - Author retains copyright of the work and grants ACM an exclusive permission-to-publish license; - Author transfers copyright of the work to ACM. For more information, please see ACM Copyright Policy <http://www.acm.org/publications/policies/copyright-policy> and ACM Author Rights <http://authors.acm.org/main.html>. Accepted proposals for system demonstrations will be posted on the symposium website but not formally published in the proceedings. *Publication date:* The official publication date of accepted papers is the date the proceedings are made available in the ACM Digital Library. This date may be up to two weeks prior to the first day of the conference. The official publication date affects the deadline for any patent filings related to published work. Artifacts Authors of accepted papers are encouraged to make auxiliary material (artifacts like source code, test data, etc.) available with their paper. They can opt to have these artifacts published alongside their paper in the ACM Digital Library (copyright of artifacts remains with the authors). If an accepted paper’s artifacts are made permanently available for retrieval in a publicly accessible archival repository like the ACM Digital Library, that paper qualifies for an Artifacts Available badge ( https://www.acm.org/publications/policies/artifact-review-badging#available) Applications for such a badge can be made after paper acceptance and will be reviewed by the PC chair.

1 0

ICFP 2024: Call for Tutorials
by ICFP Publicity 11 Mar '24

11 Mar '24

ICFP 2024 CALL FOR TUTORIAL, PANEL, AND DISCUSSION PROPOSALS 29th ACM SIGPLAN International Conference on Functional Programming https://icfp24.sigplan.org/track/icfp-2024-tutorials September 2 - 7, 2024 Milan, Italy https://icfp24.sigplan.org/ <https://icfp23.sigplan.org/> The 29th ACM SIGPLAN International Conference on Functional Programming will be held in Milan, Italy on September 2 - 7, 2024, with the option of virtual participation. ICFP provides a forum for researchers and developers to hear about the latest work on the design, implementations, principles, and uses of functional programming. Proposals are invited for tutorials, lasting approximately 3 hours each, to be presented during ICFP and its co-located workshops and other events. The tutorials may target an audience who is interested in commercial uses of functional programming, but we also welcome tutorials whose primary audience is researchers rather than practitioners. Tutorials may focus either on a concrete technology or on a theoretical or mathematical tool. Ideally, tutorials will have a concrete result, such as "Learn to do X with Y" rather than "Learn language Y". Just like last year, following the success of the #ShutDownPL event, we are also inviting proposals for panels and discussions on topics of broader interest to the PL community. Tutorials, panels, and discussions may occur before or after ICFP, co-located with the associated workshops, on September 2 or September 6-7. ---------------------------------------------------------------------- Submission details Deadline for submission: May 24, 2024 Notification of acceptance: May 27, 2024 Prospective organizers of tutorials are invited to submit a completed tutorial proposal form in plain text format to the ICFP 2024 workshop co-chairs (Yannick Forster and Chandrakana Nandi), via email to yannick.forster(a)inria.fr and chandra(a)certora.com by May 24rd, 2024. Please note that this is a firm deadline. The proposal form is available at: http://www.icfpconference.org/icfp2024-files/icfp24-panel-form.txt <http://www.icfpconference.org/icfp2023-files/icfp23-panel-form.txt> http://www.icfpconference.org/icfp2024-files/icfp24-tutorials-form.txt <http://www.icfpconference.org/icfp2023-files/icfp23-tutorials-form.txt> ---------------------------------------------------------------------- Selection committee The proposals will be evaluated by a committee comprising the following members of the ICFP 2024 organizing committee, together with the members of the SIGPLAN executive committee. Workshop Co-Chair: Yannick Forster (Inria Nantes) Workshop Co-Chair: Chandrakana Nandi (Certora Inc.) General Chair: Marco Gaboardi (Boston University) Program Chair: Brigitte Pientka (McGill University) ---------------------------------------------------------------------- Further information Any queries should be addressed to the workshop co-chairs (Yannick Forster and Chandrakana Nandi), via email to yannick.forster(a)inria.fr and chandra(a)certora.com

1 0

Re: [Haskell-cafe] Package takeover: bzlib
by Andrew Lelechenko 09 Mar '24

09 Mar '24

Spam detection software, running on the system "mail.haskell.org", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see @@CONTACT_ADDRESS@@ for details. Content preview: Thanks a ton, Duncan! > On 9 Mar 2024, at 19:20, Duncan Coutts wrote: > > Done! > > https://hackage.haskell.org/package/bzlib/maintainers/ > > On Sat, 2024-03-09 at 15:30 +0000, Andrew Lelechenko wrote: >> Iâd like to take over `bzlib` package (https://hackage.haskell.org/package/bzlib) >> >> Iâve contacted the package maintainer (Duncan Coutts, CC'd) by email twice in Aug 2023 and Oct 2023, but never heard back. Earlier Duncan granted me rights for `tar` and `zlib` packages, so I imagine he is just exceedingly busy. >> >> `bzlib` package has been on life support by Hackage Trustees for many years with a fork maintained at https://github.com/hackage-trustees/bzlib. While I can do another non-maintainer upload in my Trustee hat, Iâd like to seek a more permanent solution and maintain `bzlib` back to its canonical home at https://github.com/haskell/bzlib (which I already have access to). >> >> I do not plan any drastic changes. The immediate cause of this request is HSEC-2024-0002 (https://github.com/haskell/security-advisories/pull/157, https://github.com/hackage-trustees/bzlib/issues/4) which identifies a security vulnerability in `bzlib`, thus raising a need for urgent update. >> >> Best regards, >> Andrew > [...] Content analysis details: (5.8 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (andrew.lelechenko[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record 5.0 UNWANTED_LANGUAGE_BODY BODY: Message written in an undesired language 0.8 BAYES_50 BODY: Bayes spam probability is 40 to 60% [score: 0.4999] 0.0 T_DKIM_INVALID DKIM-Signature header exists but is not valid

1 0

Re: [Haskell-cafe] Package takeover: bzlib
by Duncan Coutts 09 Mar '24

09 Mar '24

Spam detection software, running on the system "mail.haskell.org", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see @@CONTACT_ADDRESS@@ for details. Content preview: Done! https://hackage.haskell.org/package/bzlib/maintainers/ On Sat, 2024-03-09 at 15:30 +0000, Andrew Lelechenko wrote: > Iâd like to take over `bzlib` package (https://hackage.haskell.org/package/bzlib) > > Iâve contacted the package maintainer (Duncan Coutts, CC'd) by email twice in Aug 2023 and Oct 2023, but never heard back. Earlier Duncan granted me rights for `tar` and `zlib` packages, so I imagine he is just exceedingly busy. > > `bzlib` package has been on life support by Hackage Trustees for many years with a fork maintained at https://github.com/hackage-trustees/bzlib. While I can do another non-maintainer upload in my Trustee hat, Iâd like to seek a more permanent solution and maintain `bzlib` back to its canonical home at https://github.com/haskell/bzlib (which I already have access to). > > I do not plan any drastic changes. The immediate cause of this request is HSEC-2024-0002 (https://github.com/haskell/security-advisories/pull/157, https://github.com/hackage-trustees/bzlib/issues/4) which identifies a security vulnerability in `bzlib`, thus raising a need for urgent update. > > Best regards, > Andrew [...] Content analysis details: (5.8 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -0.0 SPF_HELO_PASS SPF: HELO matches SPF record -0.0 T_RP_MATCHES_RCVD Envelope sender domain matches handover relay domain -0.0 SPF_PASS SPF: sender matches SPF record 5.0 UNWANTED_LANGUAGE_BODY BODY: Message written in an undesired language 0.8 BAYES_50 BODY: Bayes spam probability is 40 to 60% [score: 0.5000] 0.0 T_DKIM_INVALID DKIM-Signature header exists but is not valid

1 0

Package takeover: bzlib
by Andrew Lelechenko 09 Mar '24

09 Mar '24

I’d like to take over `bzlib` package (https://hackage.haskell.org/package/bzlib) I’ve contacted the package maintainer (Duncan Coutts, CC'd) by email twice in Aug 2023 and Oct 2023, but never heard back. Earlier Duncan granted me rights for `tar` and `zlib` packages, so I imagine he is just exceedingly busy. `bzlib` package has been on life support by Hackage Trustees for many years with a fork maintained at https://github.com/hackage-trustees/bzlib. While I can do another non-maintainer upload in my Trustee hat, I’d like to seek a more permanent solution and maintain `bzlib` back to its canonical home at https://github.com/haskell/bzlib (which I already have access to). I do not plan any drastic changes. The immediate cause of this request is HSEC-2024-0002 (https://github.com/haskell/security-advisories/pull/157, https://github.com/hackage-trustees/bzlib/issues/4) which identifies a security vulnerability in `bzlib`, thus raising a need for urgent update. Best regards, Andrew

1 0

[ANN] Copilot 3.19
by Ivan Perez 08 Mar '24

08 Mar '24

Hi everyone!! We are very excited to announce Copilot 3.19 [2]. Copilot is a stream-based EDSL in Haskell for writing and monitoring embedded C programs, with an emphasis on correctness and hard realtime requirements. Copilot is typically used as a high-level runtime verification framework, and supports temporal logic (LTL, PTLTL and MTL), clocks and voting algorithms. Copilot is being used at NASA in drone test flights. Through the NASA tool Ogma [1] (also written in Haskell), Copilot also serves as a runtime monitoring backend for NASA's Core Flight System, Robot Operating System (ROS2), and FPrime (the software framework used in the Mars Helicopter) applications. This release drastically increases the test coverage of copilot-core. We also remove deprecated functions from copilot-core that had been renamed in prior versions to comply with our style guide. I'd also like to highlight major changes that were released in Copilot 3.18.1, which was not broadly announced: the C backend now produces code that complies with MISRA C, we've introduced testing infrastructure for copilot-libraries and copilot-theorem, fixed an issue with how arrays are generated internally when used as arguments to triggers, fixed several bugs related to testing, introduce compatibility with GHC 9.6, and introduce a new function forAll to void clashes with the language keyword forall, which is needed to be compatible with GHC >= 9.8 in future versions. As always, we're releasing exactly 2 months since the last release. Our next release is scheduled for May 7th, 2024. Current emphasis is on improving the codebase in terms of stability and test coverage, removing unnecessary dependencies, hiding internal definitions, and formatting the code to meet our new coding standards. We also plan to add extensions to the language to be able to updates arrays and structs. Users are encouraged to participate by opening issues and asking questions via our github repo [3]. Happy Haskelling! Ivan [1] https://github.com/nasa/ogma [2] https://github.com/Copilot-Language/copilot/releases/tag/v3.19 [3] https://github.com/Copilot-Language/copilot [4] https://hackage.haskell.org/package/copilot

1 0

[ANN] Agda-2.6.4.3
by Andreas Abel 06 Mar '24

06 Mar '24

Agda 2.6.4.3 has been released to replace the deprecated 2.6.4.2. Changes over Agda 2.6.4.2 are two fixes: - [Issue #7148](https://github.com/agda/agda/issues/7148): Regression in 2.6.4.2 concerning `with` - [Issue #7150](https://github.com/agda/agda/issues/7150): Regression in 2.6.4 in `rewrite` with instances # GHC supported versions Agda 2.6.4.3 has been tested with GHC 9.8.1, GHC 9.6.4, 9.4.8, 9.2.8, 9.0.2, 8.10.7, 8.8.4 and 8.6.5 on Linux, macOS and Windows. # Installation Agda 2.6.4.3 can be installed using cabal-install or stack: 1. Getting the release candidate $ cabal get https://hackage.haskell.org/package/Agda-2.6.4.3/Agda-2.6.4.3.tar.gz $ cd Agda-2.6.4.3 2. a. Using cabal-install $ cabal install -f +optimise-heavily -f +enable-cluster-counting 2. b. Using stack $ stack --stack-yaml stack-a.b.c.yaml install --flag Agda:optimise-heavily --flag Agda:enable-cluster-counting replacing `a.b.c` with your version of GHC. The flags mean: - optimise-heavily: Turn on extra optimisation for a faster Agda. Takes large resources during compilation of Agda. - enable-cluster-counting: Enable unicode clusters for alignment in the LaTeX backend. Requires the ICU lib to be installed and known to pkg-config. These flags can be dropped from the install if causing trouble. # Standard library You can use standard library v1.7.3, v2.0 or the `master` branch of the standard library with Agda 2.6.4.3. This branch is available at https://github.com/agda/agda-stdlib/ # Fixed issues over Agda 2.6.4.2 https://hackage.haskell.org/package/Agda-2.6.4.3/changelog Enjoy Agda! Report problems and regressions to: https://github.com/agda/agda/issues Andreas, on behalf of the Agda Developers

1 0

PLMW@PLDI 2024: Call for Scholarship Applications
by Yao Li 05 Mar '24

05 Mar '24

The application for attending the Programming Language Mentoring Workshop (PLMW) @PLDI 2024 is open. The deadline is March 25th AOE for full consideration but we'll continue on a rolling basis after that as long as we have funding. The application link is here https://forms.gle/2haU1bMM7UKxU39y8. Please encourage undergraduates, MS students, and junior PhD students that you think could benefit from the workshop to apply. Below is more information about PLMW@PLDI 2024. PLMW aims to broaden the exposure of late-stage undergraduate students and early-stage graduate students to research and career opportunities in programming languages. The workshop includes mentoring sessions that cover effective habits for navigating research careers, technical sessions that cover core subfields of programming languages research, and social sessions that create opportunities for students to interact with researchers in the field. Applications from underrepresented groups in computing are especially welcome. PLMW @ PLDI 2024 will be co-located with the conference on Programming Language Design and Implementation. It will be held on June 24-25, 2024, Copenhagen, Denmark. The workshop program will cover important topics such as: • Career paths after graduate school • Interplay between PL and other areas of research in Computer Science • Useful research skills such as giving good talks and writing papers • Overview of key PL research areas both in academia and industry Find out more about the workshop at https://pldi24.sigplan.org/track/PLMW-PLDI-2024 Anitha Gollamudi. Assistant Professor, Miner School of Computer Science, Univ. of Massachusetts, Lowell. https://sites.uml.edu/anitha-gollamudi/

1 0

2024 Haskell Ecosystem Workshop, June 6-7, co-located with Zurihac
by Jose Calderon 05 Mar '24

05 Mar '24

Hello, In this two-day event, held on the lakeside campus of OST in lovely Rapperswil, Switzerland, you can learn what you need to know in order to get started working on these tools. We’ve asked the presenters to identify ‘good first issues’ for those wanting to get their feet wet on contributing. Because the workshop is immediately prior to Zurihac 2024, you will have the opportunity to tackle one of these issues while the core developers are easily available! The following speakers have been confirmed, with more to follow: Michael Peyton Jones: Haskell Language Server Julian Ospald: GHCUp Richard Eisenberg: GHC Alan Zimmerman: ghc-exactprint Hécate: Haddock and Documentation There will also be experts on ecosystem-wide issues (e.g. Security), in order to facilitate conversations about how to address cross-cutting issues in our tooling ecosystem. We will update the list of confirmed speakers as we receive confirmation. Registration is via eventbrite: https://www.eventbrite.com/e/2024-haskell-ecosystem-workshop-tickets-851066… More details on the Haskell Foundation website: https://haskell.foundation/events/2024-haskell-ecosystem-workshop.html I hope to see you there! -Jose

1 0

Midlands Graduate School (MGS)
by Graham Hutton 04 Mar '24

04 Mar '24

Dear all, There are just a few days left now to register for this years Midlands Graduate School (MGS) in Leicester. Seven fantastic courses on category theory, proof theory, type theory, session types, and more. 8-12 April 2024, Leicester, UK. Registration closes Friday 8th March. Best wishes, Graham Hutton ========================================================== Midlands Graduate School 2024 8-12 April 2024, Leicester, UK https://www.cs.le.ac.uk/events/mgs2024/ BACKGROUND: The Midlands Graduate School (MGS) in the Foundations of Computing Science provides an intensive course of lectures on the mathematical foundations of computing. The MGS has been running since 1999, and is aimed at PhD students in their first or second year of study, but the school is open to everyone, and has increasingly seen participation from industry. We welcome participants from all over the world! COURSES: Seven courses will be given. Participants usually take all the introductory courses and choose additional options from the advanced courses depending on their interests. Guest lecture - Formalisation of Mathematics, Kevin Buzzard Introductory courses - Category Theory, Thorsten Altenkirch - Proof Theory, Abhishek De and Iris van der Giessen - Type Theory with Agda, Todd Ambridge Advanced courses - Session Types, Sonia Marin - Synthetic Homotopy Theory with HoTT/UF, Ulrik Buchholtz - Graph Rewriting, Reiko Heckel - Categorical Realisability, Tom de Jong REGISTRATION: Registration is £295 for students, and £550 for academic, industry and independent participants. The fee includes all lecture courses and example classes, lunch and coffee breaks, and the conference dinner. The registration deadline is ** Friday 8th March **. Spaces are limited, so please register early to secure your place. SPONSORSHIP: We offer a range of sponsorship opportunities for industry (bronze, silver, gold and platinum), each with specific benefits. Please see the website for further details. ========================================================== — Professor Graham Hutton School of Computer Science University of Nottingham, UK http://www.cs.nott.ac.uk/~pszgmh This message and any attachment are intended solely for the addressee and may contain confidential information. If you have received this message in error, please contact the sender and delete the email and attachment. Any views or opinions expressed by the author of this email do not necessarily reflect the views of the University of Nottingham. Email communications with the University of Nottingham may be monitored where permitted by law.

1 0

Re: [Haskell-cafe] Is it possible to type a function to accept only literal values?
by Olaf Klinke 01 Mar '24

01 Mar '24

> Recently I was experimenting with a GCC intrinsic functions for x86 > SMID instructions to write a fast CSV parser Could you please elaborate on what you are planning to vectorize? Profiling shows that for usually number-heavy formats such as CSV or JSON, decoding the data fields outweighs the work necessary to decode the structure of the data format. Thus I assume you would want a streaming parser to decode input into a structure of yet unparsed blobs (cassava does this), then traverse the structure in parallel to finish parsing. I can imagine this poses difficulties to the standard model of parse error reporting, though, which often relies on sequential processing. Pretty much every streaming framework has incorporated cassava, and some streaming frameworks have abstractions for parsing. What is missing? (Not related to the OP:) Is streaming and parallel processing incompatible with formats such as XML or JSON, where well-formedness is typically determined by the very last byte in the input? (The last closing parenthesis or tag.) Olaf

2 1

S-REPLS 14 at Jane Street London on March 8th: Call for participation
by Richard Eisenberg 29 Feb '24

29 Feb '24

============================================================================ S-REPLS 14 South of England Regional Programming Language Seminar series Jane Street London, 2 & A Half Devonshire Square, Premier Place, London EC2M 4UJ Fri 8 March 2024 ============================================================================ S-REPLS is a series of informal meetings for people in the South of England interested in the principles, design and implementation of programming languages. Events take place approximately thrice yearly, organised by members of the community. Attendance at S-REPLS 14 is free and lunch will be provided. Due to security concerns and planning needs all attendees need to register. Please RSVP here: https://docs.google.com/forms/d/e/1FAIpQLSeODsd6ZXNi58hTBBP1oMOLkjgkZK40QdK… <https://docs.google.com/forms/d/e/1FAIpQLSeODsd6ZXNi58hTBBP1oMOLkjgkZK40QdK…> Schedule below. Talk abstracts and further details can be found on the S-REPLS 14 website: https://www.cl.cam.ac.uk/events/s-repls14/ <https://www.cl.cam.ac.uk/events/s-repls14/> 0900 Arrival and breakfast 1000 Keynote: Graded types and Algebraic Effects Dominic Orchard (University of Kent and University of Cambridge) 1100 Break 1130 Automatically Finding Upper and Lower Time Complexity Bounds for Parallel Evaluation Carsten Fuhs (Birkbeck, University of London) 1200 Somewhat Dynamic Build Systems Neil Mitchell (Meta) 1230 Lunch 1330 The Dafny Programming Language and Static Verifier Stefan Zetzsche (Amazon) 1400 Implementing a Dependently Typed Language Modelling Algebraic Equivalences Zhiyi Liu (University of Cambridge) 1430 Programming with First-class Constructor Contexts Anton Lorenzen (University of Edinburgh) 1500 Break 1530 Finding cheaper straightline instruction sequences more cheaply Maria A Schett 1600 Starlark: between configuration and programming language Stiopa Koltsov (Meta) 1630 Ill-Typed programs don’t evaluate Charlie Walpole (University of Bristol)

1 0

Is it possible to type a function to accept only literal values?
by Daneel Yaitskov 27 Feb '24

27 Feb '24

Hi List, Recently I was experimenting with a GCC intrinsic functions for x86 SMID instructions to write a fast CSV parser and noticed that some arguments are required to be literal values (known at compile time), which makes live hard, e.g. bit shift operation expects number of bits to shift in such a way. Nonetheless the intel manual defines function prototypes as normal: __m128i _mm_bsrli_si128 (__m128i a, int imm8) Using a variable as second argument in _mm_bsrli_si128 produces unclear, but compilation error with exact line number. Definitely some magic happens here, because it is not possible to express this constraint type system of C language. Haskell is known as one of the best languages in type acrobatics, but could it beat C here? -- Best regards, Daniil Iaitskov

3 2

[ANNOUNCE] Agda 2.6.4.2
by Andreas Abel 26 Feb '24

26 Feb '24

Dear all, The Agda Team is pleased to announce the release of Agda 2.6.4.2. Agda 2.6.4.2 is a bugfix release over Agda 2.6.4.1: - Fix an inconsistency in Cubical Agda related to catch-all clauses. - Fix some internal errors. - Fix an issue with `opaque`. - Fix building with cabal flag `-f debug-serialisation`. # GHC supported versions Agda 2.6.4.2 has been tested with GHC 9.8.1, GHC 9.6.4, 9.4.8, 9.2.8, 9.0.2, 8.10.7, 8.8.4 and 8.6.5 on Linux, macOS and Windows. # Installation Agda 2.6.4.2 can be installed using cabal-install or stack: 1. Getting the tarball $ cabal update $ cabal get Agda-2.6.4.2 $ cd Agda-2.6.4.2 2. a. Using cabal-install $ cabal install -f +optimise-heavily -f +enable-cluster-counting 2. b. Using stack $ stack --stack-yaml stack-a.b.c.yaml install --flag Agda:optimise-heavily --flag Agda:enable-cluster-counting replacing `a.b.c` with your version of GHC. The flags mean: - optimise-heavily: Turn on extra optimisation for a faster Agda. Takes large resources during compilation of Agda. - enable-cluster-counting: Enable unicode clusters for alignment in the LaTeX backend. Requires the ICU lib to be installed and known to pkg-config. These flags can be dropped from the install if causing trouble. # Standard library You can use standard library v1.7.3, v2.0 or the `master` branch of the standard library with Agda 2.6.4.2. This branch is available at https://github.com/agda/agda-stdlib/ # Fixed issues over Agda 2.6.4.1 https://hackage.haskell.org/package/Agda-2.6.4.2/candidate/changelog Enjoy Agda 2.6.4.2! Andreas, on behalf of the Agda Team -- Andreas Abel <>< Du bist der geliebte Mensch. Department of Computer Science and Engineering Chalmers and Gothenburg University, Sweden andreas.abel(a)gu.se http://www.cse.chalmers.se/~abela/

1 1

[ANN] Darcs 2.18.1 release
by Ganesh Sittampalam 25 Feb '24

25 Feb '24

Hi, On behalf of the Darcs team, I would like to announce the release of Darcs 2.18.1 [1]. The full release notes [2] are appended below. Regards, Ganesh [1] https://hackage.haskell.org/package/darcs-2.18.1 [2] https://hackage.haskell.org/package/darcs-2.18.1/changelog Darcs 2.18.1, 25 Feb 2024 * Supports GHC 9.8 and the most recent version of other dependencies at the time of release, with the exception of the tls 2.0 package, which has been held back because of problems connecting to hub.darcs.net (see https://bugs.darcs.net/issue2715) * Substantial rewrite of the 'darcs test' command. The most important user visible change is that a test script can now return an exit code of 125 to reflect an untestable/skipped state (as with with "git bisect run"). This in turn means that a group of patches can be found to be responsible for a failure rather than just a single one. By default, Darcs will try to minimise such a group by reordering patches to remove irrelevant ones from the initial group found from the patch ordering in the repository. This behaviour can be disabled with --no-shrink-failure. * Remove support for downloading via curl This is no longer particularly useful as we now use modern, maintained Haskell libraries for native HTTP downloading, and substantially simplifies this area of the code. * Patch index: Significant performance improvement The patch index is used in commands like annotate and log. A couple of performance improvements were made that should speed up using the patch index. * Progress reporting Progress reports are now provided during more long-running operations, including updating the "index" (a cache that speeds up detecting changes in the working directory), and during merge operations. They also behave better on Windows and when outputting long lines. * Other changes/fixes: * Use hardlinks more often to share files between repositories/caches. * Support --leave-test-dir for all commands that support --test * Avoid extraneous "repo:." entries in _darcs/prefs/sources [issue2672] * Add 'darcs clean' command as an alias for 'darcs revert -l' * 'darcs rebase unsuspend': add more patch editing options * Fix stale lock files after Ctrl-C * External merge tools: preserve output, and fail if tool does * Properly reference renamed files in external merge [issue189] * Mark conflicts properly if tag pulled at the same time [issue2682] * Remove the useless optimize pristine subcommand * 'darcs convert': honour the --compress and --diff-algorithm options * Fix contrib/darcs-shell [issue2646] * Fix 'darcs pull --dont-allow-conflicts' with external-merge [issue1819] * Problems with local pristine files now tell user to run 'darcs repair' [issue1981] * Fix various problems with symlinks, including on Windows * Add --no-prefs-templates option when creating a repository * Allow 'darcs rebase unsuspend' when there are non-conflicting unrecorded changes * Handle broken pending patches in 'darcs check' and 'darcs repair' * Improve error reporting when remote _darcs/format doesn't exist * 'darcs optimize reorder': add --deep/--shallow options * 'darcs optimize compress/uncompress': also handle pristine files * 'darcs optimize cache': don't work with lists of darcs repos Instead just the global cache is cleaned by checking hard-link counts * Skip the pager when $DARCS_PAGER / $PAGER are set to the empty string * 'darcs convert export': allow relative paths for --read-marks and --write-marks * Fix 'darcs amend --unrecord' to move unrecorded changes to pending [issue2697] * Don't treat cancelling an operation as failure [issue2074] * Fix cloning of ssh repo when using Ctrl-C to stop getting patches [issue2701] * Don't report invalid regexes as a bug in darcs [issue2702] * Add short option -n for --dry-run * 'darcs diff': support --look-for-moves and --look-for-adds * Fix buffering problem with 'darcs diff' [issue2704] * 'darcs obliterate' and 'darcs rebase': offer to revert any conflicting unrecorded changes * Stop displaying context lines in various interactive scenarios: it didn't work properly and would require a lot of work to fix. * Improve conflict display for Rebase and V3 patches * Increase size limit to 100K for environment variables like DARCS_PATCHES_XML, and warn when it is exceeded * 'darcs rebase unsuspend': improve the display of dropped dependencies * 'darcs amend --ask-deps': also provide a way to remove dependencies * 'darcs push': support --reorder-patches option * Remove the --remote-repo option * Don't display hints about using --set-default * Conflict resolution: unrecorded changes will suppress conflict marking of appropriate changes [issue2708] * Explain what a "clean tag" is in help for tag command * Fix problem with naming patch bundles after patches that contain characters incompatible with the current locale [issue2716]

2 1

Package Takeover: Hexpat
by Pavan Rikhi 25 Feb '24

25 Feb '24

Hi, as per the "Taking over a package" wiki page, I am sending this message as I would like to takeover basic maintenance of the hexpat package: https://hackage.haskell.org/package/hexpat I have attempted to reach the original author from multiple of their publicly available addresses 3 weeks ago & have gotten no response. The last commit to the package was over 7 years ago. I have submit multiple PRs to fix compilations to their repository with no response: https://github.com/the-real-blackh/hexpat/pull/13 https://github.com/the-real-blackh/hexpat/pull/14 The hackage trustees have applied some of these, but co-maintainership by me would mean less work for them, and eventually code changes will be required to keep the package compiling: https://github.com/haskell-infra/hackage-trustees/issues/363 https://github.com/haskell-infra/hackage-trustees/issues/394 Pavan Rikhi

1 0

[ANNOUNCE] GHC 9.8.2 is now available
by Zubin Duggal 23 Feb '24

23 Feb '24

The GHC developers are happy to announce the availability of GHC 9.8.2. Binary distributions, source distributions, and documentation are available on the [release page](https://www.haskell.org/ghc/download_ghc_9_8_2.html). GHC Blog Post: https://www.haskell.org/ghc/blog/20240223-ghc-9.8.2-released.html This release is primarily a bugfix release addressing many issues found in the 9.8 series. These include: * A fix for a bug where certain warnings flags were not recognised (#24071) * Fixes for bugs in the renamer and typechecker (#24084, #24134, #24279, #24083) * Fixes for bugs in the simplifier and code generator (#24160, #24242, #23628, #23659, #24160, #23862, #24295, #24370) * Fixes for some memory leaks in GHCi (#24107, #24118) * Improvements to error messages (#21097, #16996, #11050, #24196, #24275, #23768, #23784, #23778) * A fix for a recompilation checking bug where GHC may miss changes in transitive dependencies when deciding to relink a program (#23724). * And many more fixes A full accounting of changes can be found in the [release notes]. As some of the fixed issues do affect correctness users are encouraged to upgrade promptly. We would like to thank Microsoft Azure, GitHub, IOG, the Zw3rk stake pool, Well-Typed, Tweag I/O, Serokell, Equinix, SimSpace, Haskell Foundation, and other anonymous contributors whose on-going financial and in-kind support has facilitated GHC maintenance and release management over the years. Finally, this release would not have been possible without the hundreds of open-source contributors whose work comprise this release. As always, do give this release a try and open a [ticket][] if you see anything amiss. Enjoy! -Zubin [ticket]: https://gitlab.haskell.org/ghc/ghc/-/issues/new [release notes]: https://downloads.haskell.org/~ghc/9.8.2/docs/users_guide/9.8.2-notes.html

1 0

what monad is this?
by Johannes Waldmann 21 Feb '24

21 Feb '24

Dear Cafe, I was surprised to see ghc accept this code ghci> do let {x = False}; not x True because I initially thought: there's a `do`, so there must be some monad, but which is it? some implicit Identity monad perhaps? But the type is indeed plain `Bool`, and the explanation is (I think): there is a `do` but there is no monad, since the translation according to ( https://www.haskell.org/onlinereport/haskell2010/haskellch3.html#x8-470003.… ) does never produce `(>>=)`. So, all is fine, nothing to see here. Perhaps keep in mind as an edge case, useful to confuse students. Actually, to motivate them to read the language standard ... - J.W.

5 4

Invitation Guest Speaker @ ACFTI Cybersecurity stream
by Andrew Zayine 08 Feb '24

08 Feb '24

On behalf of the Association of Cyber Forensics and Threat Investigators (ACFTI), I am pleased to invite you to the new Cybersecurity stream lecture/seminar series. The presentation is a maximum of 1 hour in length, with an audience of about 60+, made up of undergraduate and postgraduate students plus cybersecurity students from developing countries. Our goal is to shine a spotlight on the broad array of new advances in cybersecurity science and operations currently adopted in the industry. This session will be conducted online. It will be fantastic to have any hands-on topics related to cyber forensics. Your discussion on this topic will be a great addition to our event. Expressions of interest to present from anyone doing research or applying cybersecurity techniques to practical or theoretical applications related to the interactions between cyber forensics and threat investigations can be sent as a summary of your work (c.200 words) to acfti (at) acfti (dot) org by February 15, 2024 Thank you in advance for your consideration, and we are very much looking forward to hearing from you. To get more news about our events, please join our low-traffic announcement group @ https://groups.google.com/g/acfti ________________________________________________________ Association of Cyber Forensics and Threat Investigators https://www.acfti.org Twitter: @acfti

5 4

Haskell Ecosystem Workshop @ Zurihac
by Jose Calderon 08 Feb '24

08 Feb '24

Hello everyone, Much like last year, the Haskell Foundation is putting on a technical workshop co-located with Zurihac. Last year the focus was on GHC, this year we are changing the scope of the workshop in order to include tools that ‘fill out’ the Haskell and GHC development ecosystem, including: * Haskell Language Server * Cabal * Haskell Ecosystem Security * GHC The event will be held during the 2 days prior to Zurihac , 6-7 June, 2024. Please take this into account when planning your trip to Zurihac. The event's aim is to help folks interested in contributing to these tools get up to speed on the context, design, and workflow necessary in order to make contributions to these projects. We're asking our speakers to have 'good first issues' ready for volunteers to work on, and Zurihac itself will be a great time to dive in whilst still having access to the various maintainers. Additionally, the talks will be recorded as a form of documentation for these tools. We have a few speakers committed, but are still working on the overall program. Once we have the program finalized, we will open registration. We expect to have all speakers and talks finalized within the next few weeks. Just as last year, the event will have a modest registration fee in order to cover its costs and pay for the speakers to attend. If you have any suggestions on what tools/topics you would like to see represented, I’m happy to hear them. While this year’s program is mostly filled, it can help us know what to plan for future events like this. I hope to see you there!

1 0

Call for Participation: HAFDAL workshop, 3rd March in Edinburgh
by Rob Stewart 08 Feb '24

08 Feb '24

*Call for Participation* The Hardware Acceleration of Functional and Declarative Languages (HAFDAL) workshop on 3rd March is co-located with HPCA, CGO, CC and PPoPP in Edinburgh. Confirmed speakers are: *Reflections on compiling Haskell to Hardware*, Christiaan Baaij (QBayLogic) *The Cephalopode Project: Creating a low-power IoT device aimed at functional language execution*, Carl-Johan Seger (Chalmers University of Technology) *Prefetching in Functional Languages: a Hardware-Software Retrospective*, Sam Ainsworth (Research Consultant and University of Edinburgh) *Heron: A graph reduction processor with concurrent garbage collection*, Craig Ramsay (Heriot-Watt University) *PipelineC: Easier hardware description between RTL and HLS*, Julian Kemmerer (Deepwave Digital) *From Open Hardware Design to Silicon: Lessons From Some Big (Academic) Chips*, Jon Balkind (UC Santa Barbara) *BRAT: Compositional programming for hybrid quantum algorithms*, Craig Roy (Quantinuum) Workshop registration includes lunch, coffee and access to industry tutorials in the morning. https://haflang.github.io/workshops/hafdal24.html Best wishes, -- Rob Stewart Associate Professor Computer Science, Heriot-Watt University W: https://www.macs.hw.ac.uk/~rs46

1 0

PhD studentship in functional programming (closing date 9th Feb)
by Graham Hutton 02 Feb '24

02 Feb '24

Dear all, If you are interested in applying for the advertised PhD studentship in functional programming, please note that the closing date is now one week away (9th February). Best wishes, Graham +-----------------------------------------------------------+ Fully-Funded PhD Studentship Functional Programming Lab School of Computer Science University of Nottingham, UK http://tinyurl.com/fplab-phd Applications are invited for a fully-funded PhD studentship under the supervision of Prof Graham Hutton, starting on 1st October 2024. The successful applicant will join the Functional Programming Lab, an internationally-leading centre for programming language research. The topic for the studentship is open, but should relate to the research interests of Prof Hutton on the mathematics of program construction. The studentship forms part of the recently-funded EPSRC project on Semantics-Directed Compiler Construction, which seeks to develop new techniques for constructing certified compilers from semantics. The studentship is open to home and international students, is fully-funded for three and a half years, and includes a stipend of £18,622 per year and tuition fees. Applicants are expected to have a first-class Masters or Bachelors degree (or equivalent) in Computer Science and/or Mathematics, and an excellent ability and interest in the mathematical foundations of programming (topics such as logic and semantics), together with experience of programming in a functional language. Further information and advice for prospective applicants is available from http://tinyurl.com/369xwzc7. Funding for this studentship is already in place. To apply, please submit the following items by email to graham.hutton(a)nottingham.ac.uk: (1) a brief covering letter that describes your reasons for wishing to undertake a PhD and any ideas you have about potential topics; (2) a copy of your CV, including your actual or expected degree class(es) and results of all university examinations; (3) an example of your technical writing, such as a report or dissertation; (4) email addresses for two academic referees. Closing date for applications: Friday 9th February 2024. +-----------------------------------------------------------+ -- Professor Graham Hutton School of Computer Science University of Nottingham, UK http://www.cs.nott.ac.uk/~pszgmh This message and any attachment are intended solely for the addressee and may contain confidential information. If you have received this message in error, please contact the sender and delete the email and attachment. Any views or opinions expressed by the author of this email do not necessarily reflect the views of the University of Nottingham. Email communications with the University of Nottingham may be monitored where permitted by law.

1 0

CGO24 - Early-bird Deadline Registration
by L. Cicolini 31 Jan '24

31 Jan '24

ACM/IEEE International Symposium on Code Generation and Optimization (CGO 2024) Call for Participation - Early Bird Registration The International Symposium on Code Generation and Optimization (CGO) is a premier venue to bring together researchers and practitioners working at the interface of hardware and software on a wide range of optimization and code generation techniques and related issues. The conference spans the spectrum from purely static to fully dynamic approaches, and from pure software-based methods to specific architectural features and support for code generation and optimization. Registration (early-bird deadline: February 2) https://conf.researchr.org/attending/cgo-2024/registration Registration to CGO will give you full access to all co-located events on the day(s) selected (CC, PPoPP, HPCA). Detailed program: https://conf.researchr.org/program/cgo-2024/program-cgo-2024/ List of accepted papers: https://conf.researchr.org/info/cgo-2024/accepted-papers List of workshops/tutorials: https://conf.researchr.org/info/cgo-2024/workshops For more information, please visit the CGO conference website at https://conf.researchr.org/home/cgo-2024 *Copyright © 2024 CGO Conference, All rights reserved.* You are receiving this email because you have submitted to or attended CGO.

1 0

GHC Steering Committee Call for Nominations
by Adam Gundry 28 Jan '24

28 Jan '24

Dear Haskellers, The GHC Steering Committee is seeking nominations for new members. The committee scrutinizes, debates and eventually decides to accept or reject proposals to change the language or major features supported by GHC. Our processes are described in the GitHub repository where proposals are submitted (https://github.com/ghc-proposals/ghc-proposals) In particular, please have a look at the committee bylaws (https://github.com/ghc-proposals/ghc-proposals/blob/master/committee.rst) We are looking for members who have the ability to: - understand GHC proposals (e.g. for new language extensions), - find holes and missing corner cases in the specifications, - foresee the interaction with other language or compiler features, - comment constructively and improve proposals through engagement with others, - judge the cost/benefit ratio of changes, and - come to a justifiable conclusion. Ideally, committee members should: - have substantial experience of writing or teaching Haskell; - have a track record of active contributions to the Haskell community; or - have expertise in language design and implementation, in either Haskell or related languages. It is our aim that this committee be diverse; by representing different viewpoints, we will make decisions that benefit larger segments of our community. Even if you are uncertain whether your background qualifies you for the role, you are warmly encouraged to apply. 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 adam(a)well-typed.com by February 16th 2024, briefly summarising your background and relevant experience. I will distribute the nominations among the committee, and we will keep the nominations and our deliberations private. Self-nominations are the norm. You can nominate someone else, but please obtain their explicit consent to do so. (We don't want to choose someone who turns out to be unable to serve.) On behalf of the committee, Adam Gundry -- Adam Gundry, Haskell Consultant Well-Typed LLP, https://www.well-typed.com/ Registered in England & Wales, OC335890 27 Old Gloucester Street, London WC1N 3AX, England

1 0

`queue` package take-over request
by Mitchell Rosen 24 Jan '24

24 Jan '24

Hi all, I'd like to take over the `queue` package, last updated 14 years ago, and marked "deprecated" on Hackage. I intend to replace it with a simple, clean implementation of Okasaki's "real time" (meaning O(1) worst-case operations) queue, which you can find implemented here: https://github.com/awkward-squad/queues I had originally named the package `queues` (with an s), but figured it would be better to repurpose the singular `queue` with something useful, if possible. Thanks! Mitchell

4 7

heads-up: tls v2.0.0
by Kazu Yamamoto 21 Jan '24

21 Jan '24

Hello guys, I'm planning to release the "tls" package v2.0.0 probably within one month. It removes TLS 1.0/1.1 and provides only TLS 1.2/1.3 with safe cipher suites according to recent RFCs and internet-drafts. This version does not change the default usage. But if you are using custom parameters, you might have to modify your code. This breaking change is *intentional* to notice users that they are using vulnerable versions and/or parameters. The attached is the current change log. --Kazu ## Version 2.0.0 * `tls` now only supports TLS 1.2 and TLS 1.3 with safe cipher suites. * Security: BREAKING CHANGE: TLS 1.0 and TLS 1.1 are removed. * Security: BREAKING CHANGE: all CBC cipher suite are removed. * Security: BREAKING CHANGE: RC4 and 3DES are removed. * Security: BREAKING CHANGE: DSS(digital signature standard) is removed. * Security: BREAKING CHANGE: TLS 1.2 servers require EMS(extended master secret) by default. * BREAKING CHANGE: the package is now complied with `Strict` and `StrictData`. * BREAKING CHANGE: Many data structures are re-defined with `PatternSynonyms` for extensibility. * BREAKING CHANGE: the structure of `SessionManager` is changed to support session tickets. * API: `handshake` can receive an alert of client authentication failure for TLS 1.3 [#463](https://github.com/haskell-tls/hs-tls/pull/463) * API: `bye` can receive NewSessionTicket for TLS 1.3 * Channel binding: `getFinished` and `getPeerFinished` are deprecated. Use `getTLSUnique` instead. * Channel binding: `getTLSExporter` and `getTLSServerEndPoint` are provided. [#462](https://github.com/haskell-tls/hs-tls/pull/462) * Refactoring: the monolithic `handshake` is divided to follow the diagram of TLS 1.2 and 1.3 for readability. * Refactoring: test cases are refactored for maintenability and readablity. `hspec` is used instead of `tasty`. * Code format: `fourmolu` is used as an official formatter.

5 18

Re: [Haskell-cafe] Wincomplete-uni-patterns and bidirectional patterns
by Olaf Klinke 20 Jan '24

20 Jan '24

> For functions types, there is only one equivalence class, because > there > is only one way to pattern-match a function. Observe that two > elements > can be distinguished by a set of patterns if and only if there is one > element in the pattern set that already distinguishes them. Do > pattern > synonyms refine the equivalence relation induced by ordinary > constructors? No. What I said is only true in the absence of view patterns. With view patterns, a pattern match is no longer guaranteed to terminate, since the viewing function could diverge on the value being matched. Consider -- diverges on infinite lists end :: [a] -> [a] end xs = case tl xs of [] -> [] (_:xs') -> end xs' pattern Finite <- (end -> []) isFinite :: [a] -> Bool isFinite xs = case xs of Finite -> True _ -> False Notice that isFinite is no longer a clopen but an open: It either returns True or diverges. Moreover, view patterns introduce fine- grained clopens on function spaces, like pattern Q <- (($ 4) -> 3) We must conclude that in the presence of the ViewPatterns extension, the equivalenve relation induced by pattern matching is: "x~y whenever there is no function v and no pattern P such that (v x) and (v y) can be distinguished by P." It should not be hard to prove that deciding coverage by view patterns such as Finite would solve the halting problem. Olaf

1 0

Parallel Haskell on an M2 Mac
by Dennis Raddle 20 Jan '24

20 Jan '24

I don't know a lot about parallel Haskell, so I'm wondering in general terms how that would work with my M2 Mac. I have a search task that's easily run in parallel. For example, I might map a function over a list, and each item's evaluation can run in parallel. On the M2 MacBook I have, there are 4 efficiency cores with 1 thread each, and 8 performance cores with 2 threads each. Is it fairly easy to use parallel Haskell to spread the task over these 20 possible threads? By any chance could I limit it to using the performance cores if that helps the speed? Thanks, Dennis

3 3

Re: [Haskell-cafe] Wincomplete-uni-patterns and bidirectional patterns
by Olaf Klinke 19 Jan '24

19 Jan '24

> > Should we open a feature request at Haddock? > > I think that would be a good idea. A cursory search suggests there's > no feature request already Done: https://github.com/haskell/haddock/issues/1625 I would also like to humbly suggest that the GHC devs consider my proof that pattern synonym completeness checks are decidable, thus improving the situation that caused this thread. I have a proof-of-concept implementation with a type signature like covers :: PatternMatch t => [Pattern t] -> Bool where type Pattern t = t -> Bool and PatternMatch is a type class much like Generic which derives instances for all Generic Rep types (except V1) plus function spaces and fixed points. What is left to do is to convert the GHC-internal pattern representation into (t -> Bool). Is that feasible? As I elaborated, that task ist quite mechanistic and could likely be done in Template Haskell. Olaf

1 0

ZuriHac 2014 takes place 8-10 June, registration now open
by Jasper Van der Jeugt 19 Jan '24

19 Jan '24

Hi Friends of Haskell, It is our pleasure to announce that ZuriHac 2024 will take place Saturday 8 June - Monday 10 June 2024 as a physical event at the Rapperswil-Jona campus of the OST Eastern Switzerland University of Applied Sciences. The focus of ZuriHac is being a community event and hackathon, but we will also have some exciting keynotes from Ningning Xie, Alex McLean, Ivan Perez and Mary Sheeran. In addition to that, there will be some more hands-on content: Well-Typed will host a workshop, Jesper Cockx will host an Agda track and Manuel Bärenz will host an FRP Track. We also welcome beginners or people unfamiliar to Haskell who are curious to learn more. Eliane Schmidli will teach a beginners workshop, and there will be many mentors from the Haskell Community happy to answer all your questions. Two days prior to ZuriHac, the Haskell Foundation and OST will organize a co-located 2-day Haskell Infrastructure Workshop. More details about that will be announced soon. You can find more information about the event and register at <https://zurihac.info>. The event is free for participants. This is only possible with the help of our generous supporters, who are currently: - The Haskell Foundation - Jane Street - OST Eastern Switzerland University of Applied Sciences - Tweag - Well-Typed In case you would like to support ZuriHac, please get in touch with us. We hope to see you there! The Zurich Friends of Haskell

1 0

Re: [Haskell-cafe] Wincomplete-uni-patterns and bidirectional patterns
by Olaf Klinke 19 Jan '24

19 Jan '24

> My point is that which patterns are expected to be complete is an API > design choice, subject to API stability decisions, and not just a > matter > of deductive reasoning. Now I understand: Even though completeness is (provably) provable, the COMPLETE pragma can signal the library user which sets of patterns the library author intended to cover the (opaque) type, much like the MINIMAL pragma for type classes. Otherwise the library user could only know this by compiling a code snippet with -Wincomplete-uni-patterns. To further draw the parallel between MINIMAL and COMPLETE, is COMPLETE picked up by Haddock? Seems not: The Data.Sequence.Internal module contains {-# COMPLETE (:<|), Empty #-} {-# COMPLETE (:|>), Empty #-} yet the "bundled patterns" section in https://hackage.haskell.org/package/containers-0.7/docs/Data-Sequence.html#… does not show it. If COMPLETE is indeed never picked up by Haddock, I'd say this pragma is currently fairly useless for conveying contracts. Should we open a feature request at Haddock? Olaf

2 1

Re: [Haskell-cafe] Wincomplete-uni-patterns and bidirectional patterns
by Olaf Klinke 18 Jan '24

18 Jan '24

> > Hence I believe that completeness checks in presence of patterns is > > equivalent to determine whether a disjunction of logic formulae, > > which > > are possibly self-referential, is a tautology. That may well be > > semi- > > decidable at best. > > That seems plausible, but I think that interface stability is a more > serious concern. It isn't enough to know that *as-implemented* at a > given time some particular set of patterns is complete. > > The implementation of a set of patterns (or the underlying type) can > change in a manner that changes complete <-> incomplete in either > direction. Such changes are non-breaking, provided there was no > "contract" (COMPLETE pragma) that the patterns are *intended* to be > complete. > You are right: It is possible that the types of the bidirectional patterns do not change, but the completeness changes. In your example given I would argue the contract is broken, because the new patterns are for a different type Foo. Instead -- before: Good, Bad are complete data Foo = A | B pattern Good :: Foo pattern Good = A pattern Bad :: Foo pattern Bad = B -- after: Good, Bad are incomplete -- Foo, Good as before pattern Bad = A Here neither the definition of Foo nor the types of Good or Bad have changed, but completeness has. Here is why I think that completeness checks even with pattern synonyms should work and we would not need COMPLETE pragmas. The algorithm for a set of patterns of type T is: 1. Construct a Stone [1] space X from the given type T. (Often X = T) 2. Translate each pattern to a clopen of that Stone space 3. Use Stone duality to translate coverage into a Zeroth-order logic problem, which is decidable. Let us define an equivalence relation on the elements of a type. Say x~y whenever there is no pattern that can distinguish x and y by pattern match. Notice that any pattern partitions the set of equivalence classes into two disjoint subsets, think of isJust or isNothing. In general, given a pattern Pat for type T, write isPat :: T -> Bool isPat x = case x of Pat -> True _ -> False For functions types, there is only one equivalence class, because there is only one way to pattern-match a function. Observe that two elements can be distinguished by a set of patterns if and only if there is one element in the pattern set that already distinguishes them. Do pattern synonyms refine the equivalence relation induced by ordinary constructors? No. Consider type Clopen x = x -> Bool data C = L C | R C cl :: Clopen C cl = isL . shift where isL :: Clopen C -- a pattern isL (L c) = True isL (R c) = False shift :: C -> C shift (L c) = c shift (R c) = c Can one define a single pattern synonym pattern CL :: C -> C such that CL matches c if any only if cl c == True? Note that cl is the disjunction of two ordinary patterns, namely L (L _) R (L _) CL morally should be the pattern (_(L _)) but that is not valid pattern syntax. Indeed with synonyms we can define the CL pattern: {-# LANGUAGE PatternSynonyms, ViewPatterns #-} swap :: C -> C swap (L (R c)) = R (L c) swap (R (L c)) = L (R c) swap c = c pattern CL c <- (swap -> L c) isCL :: Clopen C isCL c = case c of CL _ -> True _ -> False Now, at least as long as a type X has only a finite number of constructors (integers with numeric literals being an exception), the type Clopen X defines a Stone space, a compact zero-dimensional Hausdorff space. By Stone duality these are dually equivalent to Boolean algebras. The duality translates the problem of coverage by clopens to the problem of proving that the disjunction of some elements in the algebra is the top element 'True'. Since Zeroth-order logic is decidable, completness checks even in the presence of pattern synonyms should be, too. For the countably infinite type C above, one can use the Select monad [2] to decide whether any number of clopens covers the space, pattern or not. For numeric literal patterns we can safely say that any set of patterns is not covering unless a wildcard pattern is among them. Olaf [1] https://en.wikipedia.org/wiki/Stone_space [2] https://hackage.haskell.org/package/transformers-0.6.1.1/docs/Control-Monad… see also https://hackage.haskell.org/package/infinite-search

2 1