- Haskell-Cafe - Haskell.org

[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 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