March 2024 - Haskell-Cafe

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 13 Mar '24

13 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 11 Mar '24

11 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