From olf at aatal-apotheke.de Fri Mar 1 13:52:39 2024 From: olf at aatal-apotheke.de (Olaf Klinke) Date: Fri, 01 Mar 2024 14:52:39 +0100 Subject: [Haskell-cafe] Is it possible to type a function to accept only literal values? Message-ID: <79bc5a0d8406ea1df5f975458656772aa2547724.camel@aatal-apotheke.de> > 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 From oleg.grenrus at iki.fi Fri Mar 1 17:27:16 2024 From: oleg.grenrus at iki.fi (Oleg Grenrus) Date: Fri, 1 Mar 2024 19:27:16 +0200 Subject: [Haskell-cafe] Is it possible to type a function to accept only literal values? In-Reply-To: <79bc5a0d8406ea1df5f975458656772aa2547724.camel@aatal-apotheke.de> References: <79bc5a0d8406ea1df5f975458656772aa2547724.camel@aatal-apotheke.de> Message-ID: <8a87246b-16eb-7bca-4159-e3ebca77cde2@iki.fi> No, you can opportunistically do processing of your data. That's what SAX/SAJ (vs. DOM) parsers allow you to do. Similar approaches are there for JSON. simdjson [1] is streaming too, but the interface is different from SAX/SAJ. - Oleg [1] https://simdjson.github.io/simdjson/md_doc_ondemand_design.html On 1.3.2024 15.52, Olaf Klinke wrote: > Is streaming and parallel processing > incompatible with formats such as XML or JSON, From Graham.Hutton at nottingham.ac.uk Mon Mar 4 09:10:51 2024 From: Graham.Hutton at nottingham.ac.uk (Graham Hutton) Date: Mon, 4 Mar 2024 09:10:51 +0000 Subject: [Haskell-cafe] Midlands Graduate School (MGS) Message-ID: <456ADF99-5A0E-41DD-A141-50B4F3A76FDD@nottingham.ac.uk> 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. From jmct at haskell.foundation Tue Mar 5 04:36:26 2024 From: jmct at haskell.foundation (Jose Calderon) Date: Mon, 4 Mar 2024 23:36:26 -0500 Subject: [Haskell-cafe] 2024 Haskell Ecosystem Workshop, June 6-7, co-located with Zurihac Message-ID: 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-851066431607?utm-campaign=social&utm-content=attendeeshare&utm-medium=discovery&utm-term=listing&utm-source=cp&aff=ebdsshcopyurl More details on the Haskell Foundation website: https://haskell.foundation/events/2024-haskell-ecosystem-workshop.html I hope to see you there! -Jose From liyao at pdx.edu Tue Mar 5 19:01:02 2024 From: liyao at pdx.edu (Yao Li) Date: Tue, 5 Mar 2024 11:01:02 -0800 Subject: [Haskell-cafe] PLMW@PLDI 2024: Call for Scholarship Applications Message-ID: 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 at 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/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From andreas.abel at ifi.lmu.de Wed Mar 6 10:56:19 2024 From: andreas.abel at ifi.lmu.de (Andreas Abel) Date: Wed, 6 Mar 2024 11:56:19 +0100 Subject: [Haskell-cafe] [ANN] Agda-2.6.4.3 Message-ID: <807ac15d-7713-4d0a-a44e-0688fb1e3126@ifi.lmu.de> 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 From ivanperezdominguez at gmail.com Fri Mar 8 14:40:56 2024 From: ivanperezdominguez at gmail.com (Ivan Perez) Date: Fri, 8 Mar 2024 06:40:56 -0800 Subject: [Haskell-cafe] [ANN] Copilot 3.19 Message-ID: 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From andrew.lelechenko at gmail.com Sat Mar 9 15:30:13 2024 From: andrew.lelechenko at gmail.com (Andrew Lelechenko) Date: Sat, 9 Mar 2024 15:30:13 +0000 Subject: [Haskell-cafe] Package takeover: bzlib Message-ID: <635FF9C8-BFEE-420C-8D41-9A1FDEF0AA00@gmail.com> 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 From duncan at well-typed.com Sat Mar 9 19:20:09 2024 From: duncan at well-typed.com (Duncan Coutts) Date: Sat, 09 Mar 2024 19:20:09 +0000 Subject: [Haskell-cafe] Package takeover: bzlib Message-ID: <7ee87a62683addd174f42a81ed4571888f1320d9.camel@well-typed.com> 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 -------------- next part -------------- An embedded message was scrubbed... From: Duncan Coutts Subject: Re: Package takeover: bzlib Date: Sat, 09 Mar 2024 19:20:09 +0000 Size: 2670 URL: From andrew.lelechenko at gmail.com Sat Mar 9 19:36:54 2024 From: andrew.lelechenko at gmail.com (Andrew Lelechenko) Date: Sat, 9 Mar 2024 19:36:54 +0000 Subject: [Haskell-cafe] Package takeover: bzlib Message-ID: <7A79C2D4-DD67-4434-8AD9-C410DF33478C@gmail.com> 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 -------------- next part -------------- An embedded message was scrubbed... From: Andrew Lelechenko Subject: Re: Package takeover: bzlib Date: Sat, 9 Mar 2024 19:36:54 +0000 Size: 4673 URL: From icfp.publicity at googlemail.com Mon Mar 11 15:27:59 2024 From: icfp.publicity at googlemail.com (ICFP Publicity) Date: Mon, 11 Mar 2024 23:27:59 +0800 Subject: [Haskell-cafe] ICFP 2024: Call for Tutorials Message-ID: 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/ 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 at inria.fr and chandra at 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/icfp2024-files/icfp24-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 at inria.fr and chandra at certora.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From jgbm at acm.org Mon Mar 11 23:50:49 2024 From: jgbm at acm.org (J. Garrett Morris) Date: Mon, 11 Mar 2024 18:50:49 -0500 Subject: [Haskell-cafe] CFP: Haskell Symposium 2024 Message-ID: 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) . Submission Submissions must adhere to SIGPLAN’s republication policy , and authors should be aware of ACM’s policies on 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 and ACM Author Rights . 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: From sperber at deinprogramm.de Wed Mar 13 12:44:51 2024 From: sperber at deinprogramm.de (Michael Sperber) Date: Wed, 13 Mar 2024 13:44:51 +0100 Subject: [Haskell-cafe] Call for Papers: ACM Workshop on Functional Software Architecture Message-ID: ====================================================================== *** 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 . 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. From icfp.publicity at googlemail.com Wed Mar 13 14:57:24 2024 From: icfp.publicity at googlemail.com (ICFP Publicity) Date: Wed, 13 Mar 2024 22:57:24 +0800 Subject: [Haskell-cafe] FUNARCH 2024: Call for Papers Message-ID: 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 . 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben at well-typed.com Wed Mar 13 23:11:02 2024 From: ben at well-typed.com (Ben Gamari) Date: Wed, 13 Mar 2024 19:11:02 -0400 Subject: [Haskell-cafe] [ANNOUNCE] GHC 9.10.1-alpha1 is now available Message-ID: <871q8dd8xo.fsf@smart-cactus.org> 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-notes.html [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 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From ufarooq at lsu.edu Fri Mar 15 21:41:11 2024 From: ufarooq at lsu.edu (Umar Farooq) Date: Fri, 15 Mar 2024 21:41:11 +0000 Subject: [Haskell-cafe] Call for Papers: OOPSLA 2024 Message-ID: ======================================================================== 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-authors). #### 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-human-participants-and-subjects). 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](https://www.acm.org/publications/policies/new-acm-policy-on-authorship) ##### 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From johns243a at gmail.com Sat Mar 16 22:57:33 2024 From: johns243a at gmail.com (John Creighton) Date: Sat, 16 Mar 2024 16:57:33 -0600 Subject: [Haskell-cafe] Bing/Copilot Answer: "->", has highest precedence for type construction but in general has nuanced precedence order Message-ID: 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 * 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-precedence-in-haskell > 2 https://www.haskellsos.com/basics/what-order-would-haskell-evaluate-2-operands-of-the-same-precedence/ > 3 https://devhubby.com/thread/what-is-the-precedence-of-and-in-haskell > 4 https://studentprojectcode.com/blog/how-to-change-precedence-of-constructor-in-haskell > 5 https://stackoverflow.com/questions/3125395/haskell-operator-vs-function-precedence > 6 https://stackoverflow.com/questions/56202894/what-is-the-precedence-of-and-in-haskell > 7 https://codereview.stackexchange.com/questions/120900/expression-parser-in-haskell-using-operator-precedence-table > 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/item582390849 I wonder how people would rate Bing's answer. -------------- next part -------------- An HTML attachment was scrubbed... URL: From newsletters at istaletan.com Sun Mar 17 01:15:57 2024 From: newsletters at istaletan.com (Ben) Date: Sun, 17 Mar 2024 02:15:57 +0100 (CET) Subject: [Haskell-cafe] Bing/Copilot Answer: "->", has highest precedence for type construction but in general has nuanced precedence order In-Reply-To: References: Message-ID: I think this is just a case of confusing unrelated concepts that use the same symbol. There is an operator named -> (for forming function types), but that's not what the exact same character sequence -> means in lambda syntax. The lambda syntax is roughly \args -> expr. The arrow there is more like a keyword than an operator; it doesn't have precedence, it just separates parts of a code structure. Much like the `=` in a function or type definitions. The parsing rule for lambas is a bit weird, because there is deep ambiguity in how much of the code following the -> should be taken as part of the lamba's body. The rule that resolves the ambiguity is that the lamba's body extends as far as it can without causing a parsing error. So when you have multiple lambas occurring near each other, as in your example, usually the latter ones are inside the body of the first one, unless there are parentheses or the end of an aligned block or something else to force a specific place where the first one ends. But this isn't really the operator precedence system at work, it's the specific parsing rule for lambas syntax. Bing Copilot is giving you misleading information because when you ask about the precedence of ->, the only interpretation that can really make sense of that question is if you're talking about it as an operator, and it then gets distracted talking about operator precedence in general (and the way fixity declarations mean you can't necessarily tell an operator's precedence without the full context). But in lamba syntax (and case syntax, etc) the arrow simply isn't an operator, so none of this is really relevant. Ben 17 Mar 2024, 9:58 am by johns243a at gmail.com: > 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>   > 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-precedence-in-haskell > > 2 > https://www.haskellsos.com/basics/what-order-would-haskell-evaluate-2-operands-of-the-same-precedence/ > > 3 > https://devhubby.com/thread/what-is-the-precedence-of-and-in-haskell > > 4 > https://studentprojectcode.com/blog/how-to-change-precedence-of-constructor-in-haskell > > 5 > https://stackoverflow.com/questions/3125395/haskell-operator-vs-function-precedence > > 6 > https://stackoverflow.com/questions/56202894/what-is-the-precedence-of-and-in-haskell > > 7 > https://codereview.stackexchange.com/questions/120900/expression-parser-in-haskell-using-operator-precedence-table > > 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/item582390849 > > I wonder how people would rate Bing's answer.  > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jo at durchholz.org Sun Mar 17 13:19:58 2024 From: jo at durchholz.org (jo at durchholz.org) Date: Sun, 17 Mar 2024 14:19:58 +0100 Subject: [Haskell-cafe] Bing/Copilot Answer: "->", has highest precedence for type construction but in general has nuanced precedence order In-Reply-To: References: Message-ID: <8b087a0e-c7dd-43f8-a369-fe9391a4e4b7@durchholz.org> On 16.03.24 23:57, John Creighton wrote: > 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. The thing with GPT AIs like what's currently hyped is that it's essentially just piecing together sentences on the basis of "in all the training data, what was the most likely follow-up word". IN particular, they do not follow any reasoning or do any semantic analysis whatsoever. This is great for writing speeches. It's also great for boilerplate code. It's bad for accuracy. It essentially depends on the quality of the training data, and since these GPT bots need humongous amounts of training, that's typically "just the Internet". (The companies behind these bots try to filter out nonsense, with a focus on avoiding public outcry, which tends to create even more humorous results.) Regards, Jo From olf at aatal-apotheke.de Sun Mar 17 19:59:46 2024 From: olf at aatal-apotheke.de (Olaf Klinke) Date: Sun, 17 Mar 2024 20:59:46 +0100 Subject: [Haskell-cafe] Bing/Copilot Answer: "->", has highest precedence for type construction but in general has nuanced precedence order Message-ID: <7508b6b5ec3ca3ce206c16f620eebf232f653ae4.camel@aatal-apotheke.de> 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 (->) :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 From raoknz at gmail.com Sun Mar 17 20:13:05 2024 From: raoknz at gmail.com (Richard O'Keefe) Date: Mon, 18 Mar 2024 09:13:05 +1300 Subject: [Haskell-cafe] Bing/Copilot Answer: "->", has highest precedence for type construction but in general has nuanced precedence order In-Reply-To: References: Message-ID: Not all grammatical issues are operator precedence issues. Why on earth would you ask Bing/Copilot about this rather than reading the report? That's like saying "Hey, there's a spring of fresh pure water just over there, so I'll drink from this muddy puddle instead." As others have remarked, there are two separate but essentially related symbols -> , and one of them is a type constructor that is rather like an operator, but the other is part of the syntax of lambda expressions and is NOT an operator and so does not have an operator precedence. It is traditional in the lambda calculus, in order to reduce the number of required parentheses, to parse \x -> \y -> \z -> ... as \x -> (\y -> (\z -> ...)) with the lambda expression extending as far to the right as possible and as little to the left as necessary. (Which is not how infix operators work.) As a type, x -> y -> z -> t is parsed as x -> (y -> (z -> t)) and again this has traditionally not been anything to do with operator precedence. There are other things, like (,,) and [..], which can appear in both types (as type constructors) and expressions. On Sun, 17 Mar 2024 at 11:58, John Creighton wrote: > > 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 > > 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-precedence-in-haskell > > 2 https://www.haskellsos.com/basics/what-order-would-haskell-evaluate-2-operands-of-the-same-precedence/ > > 3 https://devhubby.com/thread/what-is-the-precedence-of-and-in-haskell > > 4 https://studentprojectcode.com/blog/how-to-change-precedence-of-constructor-in-haskell > > 5 https://stackoverflow.com/questions/3125395/haskell-operator-vs-function-precedence > > 6 https://stackoverflow.com/questions/56202894/what-is-the-precedence-of-and-in-haskell > > 7 https://codereview.stackexchange.com/questions/120900/expression-parser-in-haskell-using-operator-precedence-table > > 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/item582390849 > > I wonder how people would rate Bing's answer. > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. From w.s.swierstra at uu.nl Tue Mar 19 10:28:42 2024 From: w.s.swierstra at uu.nl (Wouter Swierstra) Date: Tue, 19 Mar 2024 11:28:42 +0100 Subject: [Haskell-cafe] Utrecht Summer School on Advanced Functional Programming Message-ID: # 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 From adbrucker at 0x5f.org Wed Mar 20 19:54:36 2024 From: adbrucker at 0x5f.org (Achim D. Brucker) Date: Wed, 20 Mar 2024 19:54:36 +0000 Subject: [Haskell-cafe] Funded PhD Position in Formalizing/Verification of Golang (Application Deadline 2024-03-31) Message-ID: 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#version 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 From keithshep at gmail.com Thu Mar 21 01:39:59 2024 From: keithshep at gmail.com (Keith Sheppard) Date: Wed, 20 Mar 2024 21:39:59 -0400 Subject: [Haskell-cafe] my ancient hackage account Message-ID: 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From fa-ml at ariis.it Thu Mar 21 08:45:01 2024 From: fa-ml at ariis.it (Francesco Ariis) Date: Thu, 21 Mar 2024 09:45:01 +0100 Subject: [Haskell-cafe] my ancient hackage account In-Reply-To: References: Message-ID: Hello Keith, Il 20 marzo 2024 alle 21:39 Keith Sheppard ha scritto: > 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? Maybe your account is so old you have to upgrade it? [1] If this fails, join #hackage [2] and they will help for sure —F [1] https://hackage.haskell.org/accounts [2] https://matrix.to/#/#haskell:matrix.org From tdecacqu at redhat.com Thu Mar 21 16:38:25 2024 From: tdecacqu at redhat.com (Tristan Cacqueray) Date: Thu, 21 Mar 2024 12:38:25 -0400 Subject: [Haskell-cafe] Requesting For Comments for a new simple-dsp library Message-ID: <8734sjfsla.tristanC@fedora> 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 515 bytes Desc: not available URL: From lemming at henning-thielemann.de Thu Mar 21 18:04:22 2024 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Thu, 21 Mar 2024 19:04:22 +0100 (CET) Subject: [Haskell-cafe] Requesting For Comments for a new simple-dsp library In-Reply-To: <8734sjfsla.tristanC@fedora> References: <8734sjfsla.tristanC@fedora> Message-ID: <16793b58-ab-98b9-2d97-b1bbacf939ec@henning-thielemann.de> On Thu, 21 Mar 2024, Tristan Cacqueray wrote: > 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. The 'dsp' package is pretty old, predating any Vector data type or refined numeric type class hierarchies. I decided to leave it as it is, for educational reasons, since it contains many literal translations of signal processing algorithms from various text books. I have not used most of the contained functions myself. > 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. For a filter that computes lowpass, highpass and bandpass in one go, I use the "universal filter", also known as "state variable filter": https://hackage.haskell.org/package/synthesizer-core-0.8.3/docs/Synthesizer-Plain-Filter-Recursive-Universal.html You can see running examples here: https://hackage.haskell.org/package/synthesizer-core-0.8.3/docs/src/Synthesizer.Plain.Filter.Recursive.Test.html#universalTest Frequencies are specified as ratio with respect to the sampling rate, e.g. 440 Hz resonance frequency at 44100 Hz sampling rate translates to 440/44100. For working on storable vectors you would instead use Universal.causal and apply this to Data.StorableVector.Lazy. For very fast processing I have the synthesizer-llvm package, which however depends on the LLVM package in a compatible version. (LLVM-16 currently preferred.) Unfortunately I do not understand your application well, thus I do not know whether the state variable filter is the right choice for your application. From tdecacqu at redhat.com Thu Mar 21 19:02:19 2024 From: tdecacqu at redhat.com (Tristan Cacqueray) Date: Thu, 21 Mar 2024 15:02:19 -0400 Subject: [Haskell-cafe] Requesting For Comments for a new simple-dsp library In-Reply-To: <16793b58-ab-98b9-2d97-b1bbacf939ec@henning-thielemann.de> References: <8734sjfsla.tristanC@fedora> <16793b58-ab-98b9-2d97-b1bbacf939ec@henning-thielemann.de> Message-ID: <87wmpvo1c4.tristanC@fedora> On Thu, Mar 21, 2024 at 19:04 Henning Thielemann wrote: > On Thu, 21 Mar 2024, Tristan Cacqueray wrote: > >> 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. > > The 'dsp' package is pretty old, predating any Vector data type or refined > numeric type class hierarchies. I decided to leave it as it is, for > educational reasons, since it contains many literal translations of signal > processing algorithms from various text books. I have not used most of the > contained functions myself. > >> 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. > > For a filter that computes lowpass, highpass and bandpass in one go, I use > the "universal filter", also known as "state variable filter": > https://hackage.haskell.org/package/synthesizer-core-0.8.3/docs/Synthesizer-Plain-Filter-Recursive-Universal.html > > You can see running examples here: > https://hackage.haskell.org/package/synthesizer-core-0.8.3/docs/src/Synthesizer.Plain.Filter.Recursive.Test.html#universalTest > > Frequencies are specified as ratio with respect to the sampling rate, e.g. > 440 Hz resonance frequency at 44100 Hz sampling rate translates to > 440/44100. For working on storable vectors you would instead use > Universal.causal and apply this to Data.StorableVector.Lazy. For very fast > processing I have the synthesizer-llvm package, which however depends on > the LLVM package in a compatible version. (LLVM-16 currently preferred.) > I see, thank you for the details, that sounds useful. The 'step' function looks simple to use too. It's surprising that such a filter seems to only need 2 values for its state. > > Unfortunately I do not understand your application well, thus I do not > know whether the state variable filter is the right choice for your > application. The final application is named animation-fractal, it renders a video at 60 fps, using external inputs to drive a generative art function (shader). For each frame, the process: - collects inputs such as midi events or audio frames. - applies a modulation function to produce discrete values. - updates the shader input with the modulation outputs. In this demo, I used 6 sound stems and extracted their peak RMS volume (using 735 samples per frame, or 44100 / 60): https://www.youtube.com/watch?v=qZTqUQumC6s My goal with simple-dsp, is to enable using a single sound file to drive the animation, for example, by extracting the peak RMS volume of the low/mid/high frequency to approximate the drum/melody/hats elements of a sound and use that as the animation source. In a previous implementation, I used an fft to extract such values, but it was challenging to get a smooth result and that's why I'm looking into filters. For what it's worth, my current implementation is done in the 'mkFilters' and 'updateFilters' of: https://gitlab.com/TristanCacqueray/animation-fractal/-/blob/main/src/AnimationFractal/Input/AudioFilter.hs Note that it's ok if the signal gets distorted, as long as the value somehow represent a meaningful element of the sound input. Thanks again for getting back to me, I'll give synthesizer-core a try soon. -Tristan -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 515 bytes Desc: not available URL: From lemming at henning-thielemann.de Thu Mar 21 19:42:40 2024 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Thu, 21 Mar 2024 20:42:40 +0100 (CET) Subject: [Haskell-cafe] Requesting For Comments for a new simple-dsp library In-Reply-To: <87wmpvo1c4.tristanC@fedora> References: <8734sjfsla.tristanC@fedora> <16793b58-ab-98b9-2d97-b1bbacf939ec@henning-thielemann.de> <87wmpvo1c4.tristanC@fedora> Message-ID: <6a811a7e-4f63-be4b-b9dd-d5a2639dec43@henning-thielemann.de> On Thu, 21 Mar 2024, Tristan Cacqueray wrote: > I see, thank you for the details, that sounds useful. The 'step' > function looks simple to use too. It's surprising that such a filter > seems to only need 2 values for its state. The state variable filter models a very simplistic solver of a linear differential equation of second order. This is done by two integrations, each integration maintains a running sum. These sums form the state. > In this demo, I used 6 sound stems and extracted their peak RMS volume > (using 735 samples per frame, or 44100 / 60): > https://www.youtube.com/watch?v=qZTqUQumC6s Nice! > Thanks again for getting back to me, I'll give synthesizer-core a try > soon. Btw. there is a mailing list dedicated to any form of Art produced with Haskell: Haskell Art Mailing list There is also the FARM workshop as part of the ICFP. From benoit.montagu at inria.fr Mon Mar 25 13:40:26 2024 From: benoit.montagu at inria.fr (Benoit Montagu) Date: Mon, 25 Mar 2024 14:40:26 +0100 Subject: [Haskell-cafe] Volunteers for ICFP 2024 Artifact Evaluation Committee (AEC) Message-ID: <03f095bc-4a4d-4908-bc40-39a168ec023b@inria.fr> 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 From post at volker-wysk.de Fri Mar 29 13:26:35 2024 From: post at volker-wysk.de (Volker Wysk) Date: Fri, 29 Mar 2024 14:26:35 +0100 Subject: [Haskell-cafe] Cabal install fails, don't understand why Message-ID: <3ebe3a64d08864659dcfd3f76380a73dad5c7d74.camel@volker-wysk.de> 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 at 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 From fa-ml at ariis.it Fri Mar 29 13:36:50 2024 From: fa-ml at ariis.it (Francesco Ariis) Date: Fri, 29 Mar 2024 14:36:50 +0100 Subject: [Haskell-cafe] Cabal install fails, don't understand why In-Reply-To: <3ebe3a64d08864659dcfd3f76380a73dad5c7d74.camel@volker-wysk.de> References: <3ebe3a64d08864659dcfd3f76380a73dad5c7d74.camel@volker-wysk.de> Message-ID: Hello Volker, Il 29 marzo 2024 alle 14:26 Volker Wysk ha scritto: > 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----- If you are trying to install a library, use cabal install --lib and let us know if it worked as you expected —F From post at volker-wysk.de Fri Mar 29 13:50:26 2024 From: post at volker-wysk.de (Volker Wysk) Date: Fri, 29 Mar 2024 14:50:26 +0100 Subject: [Haskell-cafe] Cabal install fails, don't understand why In-Reply-To: References: <3ebe3a64d08864659dcfd3f76380a73dad5c7d74.camel@volker-wysk.de> Message-ID: <791d1499de1a1ec6d8d9a6207aaf54089c72cca6.camel@volker-wysk.de> Am Freitag, dem 29.03.2024 um 14:36 +0100 schrieb Francesco Ariis: > Hello Volker, > > Il 29 marzo 2024 alle 14:26 Volker Wysk ha scritto: > > 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----- > > If you are trying to install a library, use > > cabal install --lib > > and let us know if it worked as you expected The install succeeds with "--lib". It had to be something stupid. It's been three years since I used cabal and meanwhile things look like they moved forward. There are other errors, but they don't look cabal-related. Thanks for your help. Volker From allbery.b at gmail.com Fri Mar 29 16:05:25 2024 From: allbery.b at gmail.com (Brandon Allbery) Date: Fri, 29 Mar 2024 12:05:25 -0400 Subject: [Haskell-cafe] Cabal install fails, don't understand why In-Reply-To: <791d1499de1a1ec6d8d9a6207aaf54089c72cca6.camel@volker-wysk.de> References: <3ebe3a64d08864659dcfd3f76380a73dad5c7d74.camel@volker-wysk.de> <791d1499de1a1ec6d8d9a6207aaf54089c72cca6.camel@volker-wysk.de> Message-ID: The short version is what Francesco said. The longer version is that with modern cabal (and stack), libraries are managed by cabal/stack and you don't normally install them directly. For the cases where you need a library to be available outside cabal's implicit sandboxing, there is `cabal install --lib`; but be aware that multiple versions of packages in the resulting environment may cause other build problems down the line, and it's on you to manage the environment file as needed. The proper way to work with libraries outside of a project is "cabal repl" or "stack ghci" as appropriate. For quick one-offs with cabal, you can use e.g. `cabal repl -b HsShellScript`. (I don't know the stack equivalent, sorry.) This whole rigmarole is intended to avoid situations where multiple versions of libraries are in ghc's environment and it picks inconsistent versions, leading to the old "cabal hell". On Fri, Mar 29, 2024 at 9:50 AM Volker Wysk wrote: > Am Freitag, dem 29.03.2024 um 14:36 +0100 schrieb Francesco Ariis: > > Hello Volker, > > > > Il 29 marzo 2024 alle 14:26 Volker Wysk ha scritto: > > > 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----- > > > > If you are trying to install a library, use > > > > cabal install --lib > > > > and let us know if it worked as you expected > > The install succeeds with "--lib". It had to be something stupid. It's been > three years since I used cabal and meanwhile things look like they moved > forward. > > There are other errors, but they don't look cabal-related. > > Thanks for your help. > > Volker > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. -- brandon s allbery kf8nh allbery.b at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From post at volker-wysk.de Fri Mar 29 17:15:53 2024 From: post at volker-wysk.de (Volker Wysk) Date: Fri, 29 Mar 2024 18:15:53 +0100 Subject: [Haskell-cafe] Cabal install fails, don't understand why In-Reply-To: References: <3ebe3a64d08864659dcfd3f76380a73dad5c7d74.camel@volker-wysk.de> <791d1499de1a1ec6d8d9a6207aaf54089c72cca6.camel@volker-wysk.de> Message-ID: Hi, Brandon! That's some interesting information... Am Freitag, dem 29.03.2024 um 12:05 -0400 schrieb Brandon Allbery: > The short version is what Francesco said. The longer version is that with > modern cabal (and stack), libraries are managed by cabal/stack and you > don't normally install them directly.  My case is this. I've written a new version of the HsShellScript library, and have uploaded it to Hackage. Now I wanted to use it to compile a script (written in Haskell). I though it wouldn't hurt to install it, so the new version is available. Now I understand that all I had to do is "cabal update", so the new version's on cabal's radar. The new version would then be downloaded and compiled automagically. > For the cases where you need a library to be available outside cabal's > implicit sandboxing, there is `cabal install --lib`; but be aware that > multiple versions of packages in the resulting environment may cause other > build problems down the line, and it's on you to manage the environment > file as needed.  Hmm... I've googled what that "environment file" is: https://ghc.gitlab.haskell.org/ghc/doc/users_guide/packages.html#package-environments I certainly don't want to manage it by hand. > The proper way to work with libraries outside of a project is "cabal repl" > or "stack ghci" as appropriate. For quick one-offs with cabal, you can use > e.g. `cabal repl -b HsShellScript`. (I don't know the stack equivalent, > sorry.) What do you mean by "libraries outside of a project"? The library is one project by itself. I don't (?) have any libraries outside of projects (that I know of). > This whole rigmarole is intended to avoid situations where multiple > versions of libraries are in ghc's environment and it picks inconsistent > versions, leading to the old "cabal hell". I don't want to go there!! ;-) Thanks for your explanation. Now the question is: How do I get back to the normal/regular state, without any library outside of a project? The next version of my library will sure come... Cheers, Volker > On Fri, Mar 29, 2024 at 9:50 AM Volker Wysk wrote: > > Am Freitag, dem 29.03.2024 um 14:36 +0100 schrieb Francesco Ariis: > > > Hello Volker, > > > > > > Il 29 marzo 2024 alle 14:26 Volker Wysk ha scritto: > > > > 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----- > > > > > > If you are trying to install a library, use > > > > > >      cabal install --lib > > > > > > and let us know if it worked as you expected > > > > The install succeeds with "--lib". It had to be something stupid. It's > > been > > three years since I used cabal and meanwhile things look like they moved > > forward. > > > > There are other errors, but they don't look cabal-related. > > > > Thanks for your help. > > > > Volker > > _______________________________________________ > > Haskell-Cafe mailing list > > To (un)subscribe, modify options or view archives go to: > > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > > Only members subscribed via the mailman list are allowed to post. > > > -- > brandon s allbery kf8nh > allbery.b at gmail.com From allbery.b at gmail.com Fri Mar 29 17:48:14 2024 From: allbery.b at gmail.com (Brandon Allbery) Date: Fri, 29 Mar 2024 13:48:14 -0400 Subject: [Haskell-cafe] Cabal install fails, don't understand why In-Reply-To: References: <3ebe3a64d08864659dcfd3f76380a73dad5c7d74.camel@volker-wysk.de> <791d1499de1a1ec6d8d9a6207aaf54089c72cca6.camel@volker-wysk.de> Message-ID: On Fri, Mar 29, 2024 at 1:15 PM Volker Wysk wrote: > > The proper way to work with libraries outside of a project is "cabal > repl" > > or "stack ghci" as appropriate. For quick one-offs with cabal, you can > use > > e.g. `cabal repl -b HsShellScript`. (I don't know the stack equivalent, > > sorry.) > > What do you mean by "libraries outside of a project"? The library is one > project by itself. I don't (?) have any libraries outside of projects (that > I know of). > Cabal and stack are designed around the notion of projects, defined by a cabal file (or `package.yaml` if you use Hpack), `stack.yaml` for stack, optional `cabal.project` for cabal. Projects are sandboxed such that the package(s) in the project use consistent versions of all dependencies. Neither tool handles use outside of a project well, although stack has a global configuration (whose use for this is deprecated iirc) and cabal uses ghc's environment files when requested. So something that isn't really intended for use as part of a project isn't well handled by either one. The biggest problem with both stack's global configuration and cabal's use of environment files is the need for manual management when new versions of packages are released: neither tool currently gives you any way to manage either, and having multiple versions of a package in either invites trouble. I can't speak for stack, but cabal devs are aware of the problem and considering how best to deal with it (see for example https://github.com/haskell/cabal/issues/9581). -- brandon s allbery kf8nh allbery.b at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From lemming at henning-thielemann.de Fri Mar 29 19:32:32 2024 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Fri, 29 Mar 2024 20:32:32 +0100 (CET) Subject: [Haskell-cafe] Cabal install fails, don't understand why In-Reply-To: <3ebe3a64d08864659dcfd3f76380a73dad5c7d74.camel@volker-wysk.de> References: <3ebe3a64d08864659dcfd3f76380a73dad5c7d74.camel@volker-wysk.de> Message-ID: <3bebc2c0-6bdd-f280-5e7c-28539f2396f5@henning-thielemann.de> On Fri, 29 Mar 2024, Volker Wysk wrote: > 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. Things changed from Cabal-1 to Cabal-3. Old behaviour is retained by 'cabal v1-install'. Today, 'cabal install' is synonym for 'cabal v2-install' and refers to Nix-style builds. From ben at well-typed.com Fri Mar 29 21:30:16 2024 From: ben at well-typed.com (Ben Gamari) Date: Fri, 29 Mar 2024 17:30:16 -0400 Subject: [Haskell-cafe] [ANNOUNCE] GHC 9.10.1-alpha2 is now available Message-ID: <87v854afq2.fsf@smart-cactus.org> 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-notes.html [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 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From adbrucker at 0x5f.org Sat Mar 30 11:12:06 2024 From: adbrucker at 0x5f.org (Achim D. Brucker) Date: Sat, 30 Mar 2024 11:12:06 +0000 Subject: [Haskell-cafe] PostDoc in using Formal Methods for finding security vulnerabilities and misconfigurations in business-process-driven systems (Deadline: 2024-04-18) Message-ID: 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: * 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 From post at volker-wysk.de Sat Mar 30 17:22:15 2024 From: post at volker-wysk.de (Volker Wysk) Date: Sat, 30 Mar 2024 18:22:15 +0100 Subject: [Haskell-cafe] Cabal install fails, don't understand why In-Reply-To: References: <3ebe3a64d08864659dcfd3f76380a73dad5c7d74.camel@volker-wysk.de> <791d1499de1a1ec6d8d9a6207aaf54089c72cca6.camel@volker-wysk.de> Message-ID: Am Freitag, dem 29.03.2024 um 13:48 -0400 schrieb Brandon Allbery: > > > On Fri, Mar 29, 2024 at 1:15 PM Volker Wysk wrote: > > > The proper way to work with libraries outside of a project is "cabal > > > repl" > > > or "stack ghci" as appropriate. For quick one-offs with cabal, you can > > > use > > > e.g. `cabal repl -b HsShellScript`. (I don't know the stack > > > equivalent, > > > sorry.) > > > > What do you mean by "libraries outside of a project"? The library is one > > project by itself. I don't (?) have any libraries outside of projects > > (that > > I know of). > > > > > Cabal and stack are designed around the notion of projects, defined by a > cabal file (or `package.yaml` if you use Hpack), `stack.yaml` for stack, > optional `cabal.project` for cabal. Projects are sandboxed such that the > package(s) in the project use consistent versions of all dependencies. > > Neither tool handles use outside of a project well, although stack has a > global configuration (whose use for this is deprecated iirc) and cabal > uses ghc's environment files when requested. So something that isn't > really intended for use as part of a project isn't well handled by either > one. Sounds complicated. I guess the best way to avoid trouble, is to do everything in projects and avoid code outside of projects.   > The biggest problem with both stack's global configuration and cabal's use > of environment files is the need for manual management when new versions > of packages are released: neither tool currently gives you any way to > manage either, and having multiple versions of a package in either invites > trouble. I can't speak for stack, but cabal devs are aware of the problem > and considering how best to deal with it (see for > example https://github.com/haskell/cabal/issues/9581). You mean when you have code outside of projects, I guess. Multiple versions should be easily managed by cabal (or stack, which I don't know). I'm willing to subject myself to the way to do it, which is predefined by cabal (or stack), when in return, it all works without much hassle. I want to write code, not fight with the package management system. Happy hacking, Volker From lemming at henning-thielemann.de Sat Mar 30 22:33:10 2024 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Sat, 30 Mar 2024 23:33:10 +0100 (CET) Subject: [Haskell-cafe] Cabal install fails, don't understand why In-Reply-To: References: <3ebe3a64d08864659dcfd3f76380a73dad5c7d74.camel@volker-wysk.de> <791d1499de1a1ec6d8d9a6207aaf54089c72cca6.camel@volker-wysk.de> Message-ID: <3bda6afb-cda3-8f1c-b09f-314685c4d87a@henning-thielemann.de> On Sat, 30 Mar 2024, Volker Wysk wrote: > Am Freitag, dem 29.03.2024 um 13:48 -0400 schrieb Brandon Allbery: >> >> Cabal and stack are designed around the notion of projects, defined by a >> cabal file (or `package.yaml` if you use Hpack), `stack.yaml` for stack, >> optional `cabal.project` for cabal. Projects are sandboxed such that the >> package(s) in the project use consistent versions of all dependencies. >> >> Neither tool handles use outside of a project well, although stack has a >> global configuration (whose use for this is deprecated iirc) and cabal >> uses ghc's environment files when requested. So something that isn't >> really intended for use as part of a project isn't well handled by either >> one. > > Sounds complicated. I guess the best way to avoid trouble, is to do > everything in projects and avoid code outside of projects. You can easily turn code outside of a project into code inside a project, by adding something to the 'packages' field in cabal.project or add a separate 'source-repository-package' entry in the cabal.project. Or you stick to 'cabal v1-install'. From post at volker-wysk.de Sun Mar 31 10:16:45 2024 From: post at volker-wysk.de (Volker Wysk) Date: Sun, 31 Mar 2024 12:16:45 +0200 Subject: [Haskell-cafe] Hackage: "Build: PlanningFailed" Message-ID: <60d104a71b747f99abea9f101ea100853913167c.camel@volker-wysk.de> 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 From tom-lists-haskell-cafe-2023 at jaguarpaw.co.uk Sun Mar 31 10:27:49 2024 From: tom-lists-haskell-cafe-2023 at jaguarpaw.co.uk (Tom Ellis) Date: Sun, 31 Mar 2024 11:27:49 +0100 Subject: [Haskell-cafe] Hackage: "Build: PlanningFailed" In-Reply-To: <60d104a71b747f99abea9f101ea100853913167c.camel@volker-wysk.de> References: <60d104a71b747f99abea9f101ea100853913167c.camel@volker-wysk.de> Message-ID: On Sun, Mar 31, 2024 at 12:16:45PM +0200, Volker Wysk wrote: > 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". 4.13 was shipped with GHC 8.8 and 4.18 was shipped with 9.6. See https://wiki.haskell.org/Base_package I guess you called "cabal gen-bounds" with ghc version 8.8 in your PATH but you're now trying to install the library with ghc 9.6 in your PATH. The solution is most likely to change the base bound to < 4.20 (so it works with every version of base released so far). You can avoid uploading a new version of your package by making a package revision to do this, accessed via the link "edit package information" under your package's Hackage page. Tom From post at volker-wysk.de Sun Mar 31 10:50:43 2024 From: post at volker-wysk.de (Volker Wysk) Date: Sun, 31 Mar 2024 12:50:43 +0200 Subject: [Haskell-cafe] Hackage: "Build: PlanningFailed" In-Reply-To: References: <60d104a71b747f99abea9f101ea100853913167c.camel@volker-wysk.de> Message-ID: <6364b4595482525289613c54ba30e2df6adb0806.camel@volker-wysk.de> Hi, Tom! Am Sonntag, dem 31.03.2024 um 11:27 +0100 schrieb Tom Ellis: > On Sun, Mar 31, 2024 at 12:16:45PM +0200, Volker Wysk wrote: > > 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". > 4.13 was shipped with GHC 8.8 and 4.18 was shipped with 9.6. See > https://wiki.haskell.org/Base_package > > I guess you called "cabal gen-bounds" with ghc version 8.8 in your > PATH  That's correct. > but you're now trying to install the library with ghc 9.6 in your > PATH.   No, I'm just trying to upload it to Hackage properly. That's where I got that error. > The solution is most likely to change the base bound to < 4.20 > (so it works with every version of base released so far). Why aren't all the base package versions available? I thought this was one of the purposes of the Cabal system... And wouldn't it be better to remove the upper bound entirely? > You can avoid uploading a new version of your package by making a > package revision to do this, accessed via the link "edit package > information" under your package's Hackage page. Thanks!! I'm editing the package information next. Cheers, Volker From post at volker-wysk.de Sun Mar 31 11:15:19 2024 From: post at volker-wysk.de (Volker Wysk) Date: Sun, 31 Mar 2024 13:15:19 +0200 Subject: [Haskell-cafe] Hackage: "Build: PlanningFailed" In-Reply-To: <6364b4595482525289613c54ba30e2df6adb0806.camel@volker-wysk.de> References: <60d104a71b747f99abea9f101ea100853913167c.camel@volker-wysk.de> <6364b4595482525289613c54ba30e2df6adb0806.camel@volker-wysk.de> Message-ID: <041cc11e5a27b6a53d6e89d2cfff6a3043da7fb5.camel@volker-wysk.de> Am Sonntag, dem 31.03.2024 um 12:50 +0200 schrieb Volker Wysk: > (...) > > You can avoid uploading a new version of your package by making a > > package revision to do this, accessed via the link "edit package > > information" under your package's Hackage page. > > Thanks!! I'm editing the package information next. I've done that, but the "Build: PlanningFailed" error is still there. And the build log is the old one (with the previous version bounds). Even though the new bounds are displayed on the package's Hackage page... How can I trigger a new build? Cheers, Volker From post at volker-wysk.de Sun Mar 31 11:18:03 2024 From: post at volker-wysk.de (Volker Wysk) Date: Sun, 31 Mar 2024 13:18:03 +0200 Subject: [Haskell-cafe] Hackage: "Build: PlanningFailed" In-Reply-To: <041cc11e5a27b6a53d6e89d2cfff6a3043da7fb5.camel@volker-wysk.de> References: <60d104a71b747f99abea9f101ea100853913167c.camel@volker-wysk.de> <6364b4595482525289613c54ba30e2df6adb0806.camel@volker-wysk.de> <041cc11e5a27b6a53d6e89d2cfff6a3043da7fb5.camel@volker-wysk.de> Message-ID: <9aa2a1871b56ade5b7fb36d26e2057a566277bc5.camel@volker-wysk.de> Am Sonntag, dem 31.03.2024 um 13:15 +0200 schrieb Volker Wysk: > Am Sonntag, dem 31.03.2024 um 12:50 +0200 schrieb Volker Wysk: > > (...) > > > You can avoid uploading a new version of your package by making a > > > package revision to do this, accessed via the link "edit package > > > information" under your package's Hackage page. > > > > Thanks!! I'm editing the package information next. > > I've done that, but the "Build: PlanningFailed" error is still there. And > the build log is the old one (with the previous version bounds). Even though > the new bounds are displayed on the package's Hackage page... > > How can I trigger a new build? Never mind, I found it on the "edit package information" page. Volker From lemming at henning-thielemann.de Sun Mar 31 11:18:29 2024 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Sun, 31 Mar 2024 13:18:29 +0200 (CEST) Subject: [Haskell-cafe] Hackage: "Build: PlanningFailed" In-Reply-To: <041cc11e5a27b6a53d6e89d2cfff6a3043da7fb5.camel@volker-wysk.de> References: <60d104a71b747f99abea9f101ea100853913167c.camel@volker-wysk.de> <6364b4595482525289613c54ba30e2df6adb0806.camel@volker-wysk.de> <041cc11e5a27b6a53d6e89d2cfff6a3043da7fb5.camel@volker-wysk.de> Message-ID: On Sun, 31 Mar 2024, Volker Wysk wrote: > Am Sonntag, dem 31.03.2024 um 12:50 +0200 schrieb Volker Wysk: >> (...) >> > You can avoid uploading a new version of your package by making a >> > package revision to do this, accessed via the link "edit package >> > information" under your package's Hackage page. >> >> Thanks!! I'm editing the package information next. > > I've done that, but the "Build: PlanningFailed" error is still there. And > the build log is the old one (with the previous version bounds). Even though > the new bounds are displayed on the package's Hackage page... > > How can I trigger a new build? If you login at Hackage, then under https://hackage.haskell.org/package/hsshellscript/maintain the last item is: "Trigger rebuild" From post at volker-wysk.de Sun Mar 31 11:23:55 2024 From: post at volker-wysk.de (Volker Wysk) Date: Sun, 31 Mar 2024 13:23:55 +0200 Subject: [Haskell-cafe] Hackage: "Build: PlanningFailed" In-Reply-To: References: <60d104a71b747f99abea9f101ea100853913167c.camel@volker-wysk.de> <6364b4595482525289613c54ba30e2df6adb0806.camel@volker-wysk.de> <041cc11e5a27b6a53d6e89d2cfff6a3043da7fb5.camel@volker-wysk.de> Message-ID: <9c519a6a0eed414c27b5cd64f511d769c32e5f22.camel@volker-wysk.de> Am Sonntag, dem 31.03.2024 um 13:18 +0200 schrieb Henning Thielemann: > On Sun, 31 Mar 2024, Volker Wysk wrote: > > > Am Sonntag, dem 31.03.2024 um 12:50 +0200 schrieb Volker Wysk: > > > (...) > > > > You can avoid uploading a new version of your package by making a > > > > package revision to do this, accessed via the link "edit package > > > > information" under your package's Hackage page. > > > > > > Thanks!! I'm editing the package information next. > > > > I've done that, but the "Build: PlanningFailed" error is still there. And > > the build log is the old one (with the previous version bounds). Even though > > the new bounds are displayed on the package's Hackage page... > > > > How can I trigger a new build? > > > If you login at Hackage, then under > > https://hackage.haskell.org/package/hsshellscript/maintain > > the last item is: "Trigger rebuild" Hmm... That doesn't seem to do anything. I've tried it several times, but I always get only two build reports. These are from before. The "Build: PlanningFailed" message persists. Seems like I need to upload it again. Cheers Volker From allbery.b at gmail.com Sun Mar 31 14:51:04 2024 From: allbery.b at gmail.com (Brandon Allbery) Date: Sun, 31 Mar 2024 10:51:04 -0400 Subject: [Haskell-cafe] Hackage: "Build: PlanningFailed" In-Reply-To: <6364b4595482525289613c54ba30e2df6adb0806.camel@volker-wysk.de> References: <60d104a71b747f99abea9f101ea100853913167c.camel@volker-wysk.de> <6364b4595482525289613c54ba30e2df6adb0806.camel@volker-wysk.de> Message-ID: On Sun, Mar 31, 2024 at 6:51 AM Volker Wysk wrote: > Why aren't all the base package versions available? I thought this was one > of the purposes of the Cabal system... > > And wouldn't it be better to remove the upper bound entirely? > `base` is special, since it's tightly linked to the compiler (the compiler hardcodes the addresses of key data types and values, such as `Bool` and specifically `True` so it can compile guards). As such, it is impossible to pick a different version of `base` for use with a given compiler version. Removing the upper bound has the opposite problem: if `base` changes enough (say, a wholesale change from `String` to `Text`, not that that seems likely to happen in the near term) you will be claiming that your code is compatible with it. -- brandon s allbery kf8nh allbery.b at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From post at volker-wysk.de Sun Mar 31 15:30:53 2024 From: post at volker-wysk.de (Volker Wysk) Date: Sun, 31 Mar 2024 17:30:53 +0200 Subject: [Haskell-cafe] Hackage: "Build: PlanningFailed" In-Reply-To: References: <60d104a71b747f99abea9f101ea100853913167c.camel@volker-wysk.de> <6364b4595482525289613c54ba30e2df6adb0806.camel@volker-wysk.de> Message-ID: <8381a3ff3f20f9bb72f9b0805c6b1b4903d7f773.camel@volker-wysk.de> Am Sonntag, dem 31.03.2024 um 10:51 -0400 schrieb Brandon Allbery: > On Sun, Mar 31, 2024 at 6:51 AM Volker Wysk wrote: > > Why aren't all the base package versions available? I thought this was > > one > > of the purposes of the Cabal system... > > > > And wouldn't it be better to remove the upper bound entirely? > > > > > `base` is special, since it's tightly linked to the compiler (the compiler > hardcodes the addresses of key data types and values, such as `Bool` and > specifically `True` so it can compile guards). As such, it is impossible > to pick a different version of `base` for use with a given compiler > version. > > Removing the upper bound has the opposite problem: if `base` changes > enough (say, a wholesale change from `String` to `Text`, not that that > seems likely to happen in the near term) you will be claiming that your > code is compatible with it. This makes sense. So what happens when a new GHC version is released? It depends on the version of the base package, which it ships. When the base package doesn't get an API-breaking change, then all is well.  When it *does* have such a change, all the Hackage packages must be checked for compatibility with the new compiler version, and the upper bound of the base package version must be adjusted. That sounds like a lot of effort. It would be major happening in the Haskell community. This makes sense, too. Thanks, now it's clear. Volker From allbery.b at gmail.com Sun Mar 31 15:39:15 2024 From: allbery.b at gmail.com (Brandon Allbery) Date: Sun, 31 Mar 2024 11:39:15 -0400 Subject: [Haskell-cafe] Hackage: "Build: PlanningFailed" In-Reply-To: <8381a3ff3f20f9bb72f9b0805c6b1b4903d7f773.camel@volker-wysk.de> References: <60d104a71b747f99abea9f101ea100853913167c.camel@volker-wysk.de> <6364b4595482525289613c54ba30e2df6adb0806.camel@volker-wysk.de> <8381a3ff3f20f9bb72f9b0805c6b1b4903d7f773.camel@volker-wysk.de> Message-ID: On Sun, Mar 31, 2024 at 11:30 AM Volker Wysk wrote: > So what happens when a new GHC version is released? It depends on the > version of the base package, which it ships. When the base package doesn't > get an API-breaking change, then all is well. > There's an implicit contract that such major changes will be guarded behind an epoch version bump, so you'll see many packages depending on `base < 5`. > When it *does* have such a change, all the Hackage packages must be checked > for compatibility with the new compiler version, and the upper bound of the > base package version must be adjusted. That sounds like a lot of effort. It > would be major happening in the Haskell community. > See https://ghc.gitlab.haskell.org/head.hackage/ . In short, a large proportion of Hackage (I think corresponding to the most recent Stackage LTS?) is tested regularly, and needed changes to packages are made as overlays in head.hackage and submitted upstream before releases. -- brandon s allbery kf8nh allbery.b at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From bryan at haskell.foundation Sun Mar 31 15:58:05 2024 From: bryan at haskell.foundation (Bryan Richter) Date: Sun, 31 Mar 2024 18:58:05 +0300 Subject: [Haskell-cafe] Hackage: "Build: PlanningFailed" In-Reply-To: <6364b4595482525289613c54ba30e2df6adb0806.camel@volker-wysk.de> References: <60d104a71b747f99abea9f101ea100853913167c.camel@volker-wysk.de> <6364b4595482525289613c54ba30e2df6adb0806.camel@volker-wysk.de> Message-ID: Hi all, On Sun, 31 Mar 2024 at 13:51, Volker Wysk wrote: > > Hi, Tom! > > Am Sonntag, dem 31.03.2024 um 11:27 +0100 schrieb Tom Ellis: > > On Sun, Mar 31, 2024 at 12:16:45PM +0200, Volker Wysk wrote: > > > 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 > > > > > > but you're now trying to install the library with ghc 9.6 in your > > PATH. > > No, I'm just trying to upload it to Hackage properly. That's where I got > that error. > I guess the problem here is that the Hackage Builder itself is using GHC 9.6, while Volker had been building with GHC 8.8. Therefore, Hackage was stuck trying to use base-4.18.1.0. I think that is the direct answer to Volker's question. I can imagine there may be follow-up questions, however... -------------- next part -------------- An HTML attachment was scrubbed... URL: From post at volker-wysk.de Sun Mar 31 16:09:44 2024 From: post at volker-wysk.de (Volker Wysk) Date: Sun, 31 Mar 2024 18:09:44 +0200 Subject: [Haskell-cafe] Hackage: "Build: PlanningFailed" In-Reply-To: References: <60d104a71b747f99abea9f101ea100853913167c.camel@volker-wysk.de> <6364b4595482525289613c54ba30e2df6adb0806.camel@volker-wysk.de> Message-ID: <5b8e977442f35f8b5846cf57a5daf119c6d9b23e.camel@volker-wysk.de> Am Sonntag, dem 31.03.2024 um 18:58 +0300 schrieb Bryan Richter: > Hi all, > > On Sun, 31 Mar 2024 at 13:51, Volker Wysk wrote: > > > > Hi, Tom! > > > > Am Sonntag, dem 31.03.2024 um 11:27 +0100 schrieb Tom Ellis: > > > On Sun, Mar 31, 2024 at 12:16:45PM +0200, Volker Wysk wrote: > > > > 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 > > > > > > > > > but you're now trying to install the library with ghc 9.6 in your > > > PATH.  > > > > No, I'm just trying to upload it to Hackage properly. That's where I got > > that error. > > > > I guess the problem here is that the Hackage Builder itself is using GHC > 9.6, while Volker had been building with GHC 8.8. Therefore, Hackage was > stuck trying to use base-4.18.1.0. I think that is the direct answer to > Volker's question. I can imagine there may be follow-up questions, > however... Yes, that's right. And the follow-up question is: Why aren't all base package versions available to the Hackage Builder? Brandon answered that and made it clear. Cheers Volker From andrew.lelechenko at gmail.com Sun Mar 31 16:52:25 2024 From: andrew.lelechenko at gmail.com (Andrew Lelechenko) Date: Sun, 31 Mar 2024 17:52:25 +0100 Subject: [Haskell-cafe] Cabal install fails, don't understand why In-Reply-To: <3bda6afb-cda3-8f1c-b09f-314685c4d87a@henning-thielemann.de> References: <3ebe3a64d08864659dcfd3f76380a73dad5c7d74.camel@volker-wysk.de> <791d1499de1a1ec6d8d9a6207aaf54089c72cca6.camel@volker-wysk.de> <3bda6afb-cda3-8f1c-b09f-314685c4d87a@henning-thielemann.de> Message-ID: The easiest way to work outside of a package is https://cabal.readthedocs.io/en/latest/getting-started.html#running-a-single-file-haskell-script. Works pretty well, both in cabal run and cabal repl mode, and you can forget about any cabal *-install commands. Best regards, Andrew > On 30 Mar 2024, at 22:33, Henning Thielemann wrote: > > > On Sat, 30 Mar 2024, Volker Wysk wrote: > >> Am Freitag, dem 29.03.2024 um 13:48 -0400 schrieb Brandon Allbery: >>> Cabal and stack are designed around the notion of projects, defined by a >>> cabal file (or `package.yaml` if you use Hpack), `stack.yaml` for stack, >>> optional `cabal.project` for cabal. Projects are sandboxed such that the >>> package(s) in the project use consistent versions of all dependencies. >>> Neither tool handles use outside of a project well, although stack has a >>> global configuration (whose use for this is deprecated iirc) and cabal >>> uses ghc's environment files when requested. So something that isn't >>> really intended for use as part of a project isn't well handled by either >>> one. >> >> Sounds complicated. I guess the best way to avoid trouble, is to do >> everything in projects and avoid code outside of projects. > > You can easily turn code outside of a project into code inside a project, by adding something to the 'packages' field in cabal.project or add a separate 'source-repository-package' entry in the cabal.project. > > Or you stick to 'cabal v1-install'. > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. -------------- next part -------------- An HTML attachment was scrubbed... URL: From andrew.lelechenko at gmail.com Sun Mar 31 17:22:44 2024 From: andrew.lelechenko at gmail.com (Andrew Lelechenko) Date: Sun, 31 Mar 2024 18:22:44 +0100 Subject: [Haskell-cafe] Hackage: "Build: PlanningFailed" In-Reply-To: <9c519a6a0eed414c27b5cd64f511d769c32e5f22.camel@volker-wysk.de> References: <60d104a71b747f99abea9f101ea100853913167c.camel@volker-wysk.de> <6364b4595482525289613c54ba30e2df6adb0806.camel@volker-wysk.de> <041cc11e5a27b6a53d6e89d2cfff6a3043da7fb5.camel@volker-wysk.de> <9c519a6a0eed414c27b5cd64f511d769c32e5f22.camel@volker-wysk.de> Message-ID: <506BB5E6-F1F5-4045-BCAA-6F8137949CAF@gmail.com> If triggering rebuild does not work immediately, remove documentation first and trigger rebuild afterwards. There are 4 build reports now: https://hackage.haskell.org/package/hsshellscript-3.6.2/reports/4, but the latest one fails because, as it seems, your package does not actually support GHC 9.6 and newer dependencies. Best regards, Andrew > On 31 Mar 2024, at 12:23, Volker Wysk wrote: > > Am Sonntag, dem 31.03.2024 um 13:18 +0200 schrieb Henning Thielemann: >> On Sun, 31 Mar 2024, Volker Wysk wrote: >> >>> Am Sonntag, dem 31.03.2024 um 12:50 +0200 schrieb Volker Wysk: >>>> (...) >>>>> You can avoid uploading a new version of your package by making a >>>>> package revision to do this, accessed via the link "edit package >>>>> information" under your package's Hackage page. >>>> >>>> Thanks!! I'm editing the package information next. >>> >>> I've done that, but the "Build: PlanningFailed" error is still there. And >>> the build log is the old one (with the previous version bounds). Even though >>> the new bounds are displayed on the package's Hackage page... >>> >>> How can I trigger a new build? >> >> >> If you login at Hackage, then under >> >> https://hackage.haskell.org/package/hsshellscript/maintain >> >> the last item is: "Trigger rebuild" > > Hmm... That doesn't seem to do anything. I've tried it several times, but I > always get only two build reports. These are from before. The "Build: > PlanningFailed" message persists. Seems like I need to upload it again. > > Cheers > Volker > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. -------------- next part -------------- An HTML attachment was scrubbed... URL: