- Haskell-Cafe - Haskell.org

Re: [Haskell-cafe] Basic list exercise
by Anthony Clayden 25 Mar '23

25 Mar '23

>* On 24 Mar 2023, at 18:44, Johannes Waldmann <johannes.waldmann at htwk-leipzig.de <http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe>> wrote: *> >* ... *>* Does the implementation in Data.List do better? *> Data.List's sort is doing a different thing. So I'm not seeing the relevance. Specifically, sort doesn't pay any attention to the incoming list's ordering. >* Since this is about "exercise" - I would expect my students *>* to find that code, so perhaps I'd point them to it right away, *>* and give the task to "understand it" (= argue that it is correct). *>* Arguing about cost seems harder. *> This (ex-)student would wonder why you'd sent me to that code. (Perhaps the lesson is: first read the question.) Why does the correctness (or otherwise) of a sort bear any relation to preserving list sequence and chopping up a list into ascending sublists? AntC

2 2

Re: [Haskell-cafe] Never-ending discussion... Was: Basic list exercise
by Johannes Waldmann 25 Mar '23

25 Mar '23

@Jerzy : I like your plan to use combinators. Then let's remove (visible) recursion completely: map (map fst ) $ groupBy (const snd) $ zip xs ( True : zipWith (<=) xs (tail xs))

2 1

Re: [Haskell-cafe] Basic list exercise
by Johannes Waldmann 24 Mar '23

24 Mar '23

> can we do better than this? Does the implementation in Data.List do better? https://hackage.haskell.org/package/base-4.18.0.0/docs/src/Data.OldList.htm… note that 'ascending' does some trickery there - perhaps exactly to solve the problem you describe? Since this is about "exercise" - I would expect my students to find that code, so perhaps I'd point them to it right away, and give the task to "understand it" (= argue that it is correct). Arguing about cost seems harder. NB: 'descending' is different here, and that's no surprise since lists are asymmetric. We do have a symmetric (and strict) implementation of sequences - how do we sort these? https://hackage.haskell.org/package/containers-0.6.7/docs/src/Data.Sequence… That's not exactly an advertisement for functional programming, as it has "state" written all over the place? But it makes for a nice exercise reading the types. I needed some time to understand that the mouse-over block for an identifier contains _two_ types: the instantiated one (for the use site) and, below that, the general one (from the definition). - J.W.

3 2

ANN: NASA's Ogma 1.0.8 -- with FPrime support
by Ivan Perez 24 Mar '23

24 Mar '23

Hi everyone! I'm thrilled to announce the release of Ogma 1.0.8! Ogma is a NASA tool that facilitates integrating runtime monitors or runtime verification applications into other systems. This is one of the biggest releases of Ogma ever: We can now generate monitors for FPrime [1], a component-based flight software framework used in many NASA missions, including the Ingenuity Mars Helicopter. Since the last release, Ogma also has officially become one of the solutions recommended for monitoring in Space ROS applications [2]. Use cases supported by Ogma also include producing Robot Operating System (ROS 2) packages [3] and NASA Core Flight System (cFS) monitoring applications [4], and generating monitors directly from requirements specified using a structured natural language framework [5]. Ogma leverages existing Haskell work, like the Copilot language [6] (also funded by NASA) and BNFC [7]. For more details, including videos of monitors being generated and flown in simulators, see: https://github.com/nasa/ogma * Releases Ogma is released as a collection of packages in Hackage. The entry point is https://hackage.haskell.org/package/ogma-cli. * Code The github repo is located at: https://github.com/nasa/ogma. * What's coming The next release is planned for May 21st, 2023. Ogma is currently undergoing the qualification process necessary for NASA Class D Software. Apart from the changes required by that process, we also have the following in our roadmap: - Extend ROS 2 monitors with further information about sources of violations. - Add tests to generated code. - Simplify NASA cFS monitor generation process. We hope that you are as excited as we are and that our work demonstrates that, with the right support, Haskell can reach farther than we ever thought possible. Happy Haskelling! Ivan [1] https://github.com/nasa/fprime [2] https://space.ros.org/ [3] https://www.ros.org/ [4] https://github.com/nasa/cFS [5] https://github.com/NASA-SW-VnV/fret [6] https://github.com/Copilot-Language/copilot [7] https://github.com/BNFC/bnfc

1 0

Re: [Haskell-cafe] Basic list exercise
by Anthony Clayden 24 Mar '23

24 Mar '23

On Thu, Mar 16, 2023, 20:33 Todd Wilson <twilson at csufresno.edu <http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe>> wrote: > ... > My question: can we do better than this? It seems that this solution is > constantly building and breaking apart pairs. (Or is it, when optimized?) I don't think we can do better (as others have commented). Laziness is a benefit for peeling off only the beginning(s) of possibly-infinite (sub-)lists. Possibly splitting off the head to call sub-function `run x xs` is also "breaking apart". If you don't like pairs, you can split the returned list itself to give the pairing. Using `l@(y:zs)` as did Viktor might help a little if the compiler is particularly dumb. (GHC isn't.) > runs :: Ord a => [a] -> [[a]] > > runs [] = [] > runs l@[x] = [l] > runs (x: l@(y:zs)) > | x <= y = let (ys:zs) = runs l in ((x:ys) : zs) > | otherwise = ([x]: runs l) This solution appears to achieve the same level of laziness as Viktor's. AntC

2 1

Intend to take over package filelock
by Andreas Abel 23 Mar '23

23 Mar '23

See https://discourse.haskell.org/t/take-over-filelock-package/6037?u=andreasab… : I intend to take over https://hackage.haskell.org/package/filelock. It is a dependency of crucial Haskell infrastructure such as `pantry` and `haskell-server` (via `acid-state`). I needs a fix to work with `unix-2.8` as released with GHC 9.6: - https://github.com/takano-akio/filelock/pull/13 I have been trying to communicate this on github to the maintainer Takano Akio since 2023-02-08. I have tried to contact the maintainer by email 2023-03-12, but have gotten no response. Preferably, the maintainer would come back, but I do not have much hope, their last public github activity was 2021-08-22. -- Andreas Abel <>< Du bist der geliebte Mensch. Department of Computer Science and Engineering Chalmers and Gothenburg University, Sweden andreas.abel(a)gu.se http://www.cse.chalmers.se/~abela/

1 0

Package takeover: OpenSCAD
by Brecht Serckx 22 Mar '23

22 Mar '23

Hi all, I would like to take over the OpenSCAD[1] package, of which I believe the maintainer is no longer active. The maintainer hasn't replied to my ticket[2] on the issue tracker or to an email to the listed email-address for over a year. On my fork[3] I have implemented multiple bugfixes and features already, and I have some ideas for future improvements. Best regards, Brecht [1] https://hackage.haskell.org/package/OpenSCAD [2] https://chiselapp.com/user/mwm/repository/OpenSCAD/tktview?name=73c74f477b [3] https://github.com/BrechtSerckx/OpenSCAD

4 8

CfP: Haskell Symposium 2023
by Niki Vazou 21 Mar '23

21 Mar '23

=============================================================================== ACM SIGPLAN CALL FOR SUBMISSIONS Haskell Symposium 2023 Seattle, WA, USA Fri 8 -- Sat 9 September, 2023 http://www.haskell.org/haskell-symposium/2023/ ================================================================================ The ACM SIGPLAN Haskell Symposium 2023 will be co-located with the 2023 International Conference on Functional Programming (ICFP). As with last year, Haskell'23 will use a single-track submission process. That is, we will only have the regular track and no early track. 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. 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 (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. Functional pearls, experience reports, tutorials and demo proposals should be labelled clearly as such. Lightweight Double-blind Reviewing ---------------------------------- Haskell Symposium 2023 will use a lightweight double-blind reviewing process. To facilitate this, submitted papers must adhere to two rules: 1. Author names and institutions must be omitted, and 2. 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 judgement 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 anonymised). 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 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 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: 1 June 2023 (Thu) Notification: 4 July 2023 (Tue) Camera ready: 18 July 2023 (Tue) Deadlines are anywhere on Earth. Submission ---------- Submissions must adhere to SIGPLAN's republication policy (http://sigplan.org/Resources/Policies/Republication/) and authors should be aware of ACM's policies on plagiarism (https://www.acm.org/publications/policies/plagiarism) Program Committee members are allowed to submit papers, but their papers will be held to a higher standard. The paper submission deadline and length limitations are firm. There will be no extensions, and papers violating the length limitations will be summarily rejected. Papers should be submitted through HotCRP at: https://haskell23.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 anonymised and non-anonymised supplementary material. Anonymised supplementary material will be visible to reviewers immediately; non-anonymised supplementary material will be revealed to reviewers only after they have submitted their review of the paper and learned the identity of the author(s). Resubmitted Papers: authors who submit a revised version of a paper that has previously been rejected by another conference have the option to attach an annotated copy of the reviews of their previous submission(s), explaining how they have addressed these previous reviews in the present submission. If a reviewer identifies him/herself as a reviewer of this previous submission and wishes to see how his/her comments have been addressed, the conference chair will communicate to this reviewer the annotated copy of his/her previous review. Otherwise, no reviewer will read the annotated copies of the previous reviews. Proceedings =========== Accepted papers will be included in the ACM Digital Library. Their authors will be required to choose one of the following options: - Author retains copyright of the work and grants ACM a non-exclusive permission-to-publish license (and, optionally, licenses the work with a Creative Commons license); - Author retains copyright of the work and grants ACM an exclusive permission-to-publish license; - Author transfers copyright of the work to ACM. For more information, please see ACM Copyright Policy (http://www.acm.org/publications/policies/copyright-policy) and ACM Author Rights (http://authors.acm.org/main.html) Accepted proposals for system demonstrations will be posted on the symposium website but not formally published in the proceedings. Publication date: The official publication date of accepted papers is the date the proceedings are made available in the ACM Digital Library. This date may be up to two weeks prior to the first day of the conference. The official publication date affects the deadline for any patent filings related to published work. Artefacts ========= Authors are encouraged to make auxiliary material (artefacts like source code, test data, etc.) available with their paper. Authors can opt to have these artefacts published alongside their paper in the ACM Digital Library (copyright of artefacts remains with the authors). Artefacts must be included as part of their submission to HotCRP and should consist of a .zip file containing the artefact materials, a README explaining the contents of the artefact and how it should be used, and a LICENSE file. If an accepted paper's artefacts are made permanently available for retrieval in a publicly accessible archival repository like the ACM Digital Library, that paper qualifies for an Artefact badge (https://www.acm.org/publications/policies/artifact-review-badging) Program Committee ================= Alexander Green Standard Chartered, UK David Thrane Christiansen The Haskell Foundation, Denmark Edsko de Vries Well-Typed LLP, Netherlands Exequiel Rivas Tallinn University of Technology Facundo DomÃnguez Tweag Florian Zuleger TU Vienna, Austria Graham Hutton University of Nottingham, UK Jasper Van der Jeugt Snyk, Switzerland Jennifer Paykin Intel, USA Jesper Cockx Delft University of Technology, Netherlands Jose Nuno Oliveira University of Minho & INESC TEC, Portugal Michael Sperber Active Group GmbH, Germany Michel Steuwer University of Edinburgh, UK Niki Vazou (chair) IMDEA Software Institute, Spain Rumyana Neykova Brunel University London, UK Trevor L. McDonell (co-chair) Utrecht University, Netherlands Ugo Dal Lago University of Bologna, Italy & INRIA, France Wen Kokke University of Edinburgh, UK Leonidas Lampropoulos University of Maryland, College Park, USA If you have questions, please contact the chairs at niki.vazou(a)imdea.org andt.l.mcdonell(a)uu.nl. ================================================================================

1 0

Presentaion on Haskell by Emily Pillmore
by Jonathan Drews 20 Mar '23

20 Mar '23

Hello Folks: On 03/21/23, at 7:00 PM EDT, Emily Pillmore, former CTO of the Haskell Foundation, will give a presentation on Haskell. She will cover the rudiments of functional programming and an overview of CABAL (Common Architecture for Building Applications and Libraries). The link is: https://meet.jit.si/SEMI-BUGHaskellTalk Ms. Pillmore is a profesional programmer and has a degree in Mathematics. She is a member of the Haskell Core Libraries team. She is also a member of the Haskell.org committee This is a great opportunity to get an overview of a pure functional programming language. -- Kind regards, Jonathan http://www.semibug.org/

1 0

Emily Pillmore to talk about Haskell
by Jonathan Drews 17 Mar '23

17 Mar '23

Folks: On March 21st, at 7:00 Pm EDT, Emily Pillmore, The CTO of the Haskell Foundation, will give a presentation on Haskell. The presentation is online and hosted by http://www.semibug.org/. This online event will be conducted through Jitsi. The Jitsi link will be posted here on Monday, March 20th. Please do tell your friends about this event as this is going to be a great presentation on Haskel by one of its most consummate practioners. -- Kind regards, Jonathan

1 0

Utrecht Summer School on Advanced Functional Programming 2023
by Swierstra, W.S. (Wouter) 16 Mar '23

16 Mar '23

# Call for Participation SUMMER SCHOOL ON ADVANCED FUNCTIONAL PROGRAMMING Utrecht, the Netherlands, 03 July – 07 July 2023 http://www.afp.school **Please register before June 15th ** ## 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 15th, 2023** School: 03 July – 07 July 2023 ## COSTS 750 euro - Profession registration fee 250 euro - Student registration fee 200 euro - Housing fee We will charge a registration fee of 750 euros (or 250 euros for students) to cover our expenses. If this is problematic for you for any reason at all, please email the organisers and we can try to offer you a discounted rate or a fee waiver. We have a limited number of scholarships or discounts available for students that would not be able to attend otherwise, especially for women and under-represented minorities. ## FURTHER INFORMATION Further information, including instructions on how to register, is available on our website: http://www.afp.school

1 0

Call for Papers, Functional Software Architecture - FP in the Large
by Graham Hutton 16 Mar '23

16 Mar '23

Dear all, We're delighted to announce that the first ACM SIGPLAN Workshop on "Functional Software Architecture - FP in the Large" will be held in Seattle, USA in September 2023, co-located with the ICFP conference. Please share, and submit your best papers, experience reports, and architectural pearls on large-scale functional programming! Best wishes, Mike Sperber and Graham Hutton Program Chairs, FUNARCH 2023 ====================================================================== *** FUNARCH 2023 -- CALL FOR PAPERS *** The First ACM SIGPLAN Workshop on Functional Software Architecture - FP in the Large 8th September 2023, Seattle, Washington, USA Co-located with ICFP 2023 https://tinyurl.com/FUNARCH23 ====================================================================== TIMELINE: Paper submission 1st June 2023 Author notification 28th June 2023 Camera ready copy 18th July 2023 Workshop 8th Sept 2023 (date to be confirmed) 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. 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 <funarch2023(a)easychair.org>. SUBMISSION: Papers must be submitted by 1st June 2023 using EasyChair, via the following link: https://tinyurl.com/FUNARCH23-submit 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, as this enables line numbers for easy reference in reviews. For further details, see: https://tinyurl.com/sigplan-acmart 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 2023 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 proceedings are made available in the ACM Digital Library. This date may be up to two weeks prior to the first day of the workshop. PROGRAM CHAIRS: Mike Sperber Active Group, Germany Graham Hutton University of Nottingham, UK PROGRAM COMMITTEE: Joachim Breitner Germany Manuel Chakravarty Tweak & IOG, The Netherlands Ron Garcia University of British Columbia, Canada Debasish Ghosh LeadIQ, India Lars Hupel Giesecke+Devrient, Germany Andy Keep Meta, USA Shriram Krishnamurthi Brown University, USA Andres Löh Well-Typed, Germany Anil Madhavapeddy University of Cambridge, UK José Pedro Magalhães Standard Chartered, UK Simon Marlow Meta, UK Hannes Mehnert Robur, Germany Erik Meijer USA Ivan Perez KBR / NASA Ames Research Center, USA Stefanie Schirmer DuckDuckGo, Germany Perdita Stevens University of Edinburgh, UK Stefan Wehr Hochschule Offenburg, Germany Scott Wlaschin FPbridge, UK WORKSHOP VENUE: The workshop will be co-located with the ICFP 2023 conference at The Westin Seattle Hotel, Seattle, Washington, United States. ====================================================================== This message and any attachment are intended solely for the addressee and may contain confidential information. If you have received this message in error, please contact the sender and delete the email and attachment. Any views or opinions expressed by the author of this email do not necessarily reflect the views of the University of Nottingham. Email communications with the University of Nottingham may be monitored where permitted by law.

1 0

Re: [Haskell-cafe] dynamic web form generation for algebraic data types
by Olaf Klinke 15 Mar '23

15 Mar '23

> > From briefly reading the wiki page > https://wiki.haskell.org/Tangible_Value, it looks like it relies on > Applicative functors for combining values. > So maybe the missing piece for sum-types was Selective functors > https://hackage.haskell.org/package/selective? > > Gustavo Bicalho > Well spotted! I did not know selective applicative functors (SAFs), thanks for mentioning! Indeed `branch` seems to be all that is necessary to get forms for sum types going. In the talk [1] Andrey mentions that SAFs have a bind, but only for enumerable inputs. The papers state that "all effects are declared statically". If we equate "effect" with "form input" then for recursive types like lists this would mean to pre-define an infinite number of fields and have the user select a finite number of them. I wonder whether that is feasible with html forms. Maybe forms (in the html sense) are a red herring for what I am after. Both the Grace and tangible values demos immediately process changes to inputs, there is no distinction between inputting the data and having the data processed: they are event-driven systems. As is JavaScript with its `oninput` and `onchange` functions. So there are two sub-problems here: The first problem is to programmatically generate html elements by JavaScript functions that can build all finite values of a given Generic Haskell type, and nothing else. The second problem is to scrape the thusly generated elements and re-assemble them into a Haskell value on the server side. The second problem is usually solved by html forms, but there may be other means. Olaf [1] https://dl.acm.org/doi/abs/10.1145/3341694#

1 0

Just released: cabal 3.10.1.0
by Mikolaj Konarski 13 Mar '23

13 Mar '23

Dear cabal users and contributors, The cabal team is proud to announce the release of cabal 3.10.1.0. This is mainly a bugfix release, but it has some new features and enhancements as well. The thread about the release, including troubleshooting and porting discussions, is at https://discourse.haskell.org/t/just-released-cabal-3-10-1-0/5978 The changelogs and release notes are at https://github.com/haskell/cabal/blob/master/release-notes/cabal-install-3.… and, if your code depends on the Cabal library, at https://github.com/haskell/cabal/blob/master/release-notes/Cabal-3.10.1.0.md Two backward (in)compatibility notes may be of particular interest: the XDG Base Directory Specification (conditionally) replacing ~/.cabal and the `--enable-documentation` option by default added to all `cabal haddock` invocations. Please look them up at the links above. Let me finish by thanking our esteemed benefactors, past and present, contributing code, devops, testing, feedback, comments. Representing these are the authors of all PRs included in the 3.10.1.0 release, honourably mentioned in the list of fame below. Abastro Alexander Biehl Alexey Radkov amigalemming Andrea Bedini Andreas Abel Andreas Klebinger Artem Pelenitsyn Ben Gamari Bodigrim Brandon Chinn Bryan Richter Byron Johnson Cheng Shao chowells79 Cmdv Colton Clemmer cydparser Daniel Gröber deltaspace0 Evgenii Akentev fendor Francesco Ariis Francesco Gazzetta Gautier DI FOLCO Georgi Lyubenov Gershom Bazerman Guillaume Genestier Hécate Moonlight Ikko Ashimine instinctive Jade Lovelace James Hobson Jan Synáček Jappie Klooster Javier Neira John Ericson Kobayashi Marcin Szamotulski Martijn Bastiaan Matthew Pickering Max Amanshauser Miezhiko Mike Pilgrem Musab Guma'a Patrick Dougherty Paweł Dybiec Pierre Le Marre Robert Vollmert Ross Paterson Saad Ahmed Sergey Vinokurov sheaf Sören Tempel Sylvain Henry Tom McLaughlin Troels Henriksen Vilius Panevėžys Vladislav Zavialov Wismill

1 0

[ANNOUNCE] GHC 9.6.1 is now available
by Ben Gamari 13 Mar '23

13 Mar '23

The GHC team is very pleased to announce the availability of GHC 9.6.1. As usual, binaries and source distributions are available at downloads.haskell.org: https://downloads.haskell.org/ghc/9.6.1/ Beginning with GHC 9.6.1, GHC can be built as a cross-compiler to WebAssembly and JavaScript. This is an important step towards robust support for compiling Haskell to the Web, but there are a few caveats to be aware of in the 9.6 series: - Both the Javascript and WebAssembly backends are still at an early stage of development and are present in this release as a technology preview - Using GHC as a cross-compiler is not as easy as we would like it to be; in particular, there are challenges related to Template Haskell - GHC is not yet run-time retargetable; a given GHC binary targets exactly one platform, and both WebAssembly and JavaScript are considered platforms for this purpose. Cross-compilers must be built from source by their users We hope to lift all of these limitations in future releases. Additionally, 9.6.1 includes: - Significant latency improvements in the non-moving garbage collector - Efficient runtime support for delimited continuations - Improvements in compiler error messages - Numerous improvements in the compiler's memory usage See the [release notes] for a comprehensive accounting of changes in this release. As always, one can find a migration guide to aid in transitioning from older releases on the [GHC Wiki][migration-guide]. We have also recently started extending our release process to cover a wider set of Linux distributions. In particular, we now offer Rocky 8 and Ubuntu 20.04 binary distributions which cover RedHat-derivative and distributions using older glibc releases (namely 2.27), respectively. Thanks to everyone who has contributed code, documentation, testing, and tickets to this release process. As this release represents upstream GHC's first step towards supporting web targets, we are very excited to have this release out the door! Cheers, - Ben [ticket]: https://gitlab.haskell.org/ghc/ghc/issues/ [migration-guide]: https://gitlab.haskell.org/ghc/ghc/-/wikis/migration/9.6 [release notes]: https://downloads.haskell.org/ghc/9.6.1/docs/users_guide/9.6.1-notes.html

2 1

ANN: hledger-1.29
by Simon Michael 12 Mar '23

12 Mar '23

I'm pleased to announce hledger 1.29 ! https://github.com/simonmichael/hledger/releases/1.29 https://hledger.org/install https://hledger.org/release-notes.html#hledger-1-29 Highlights: Tag checking, flexible multi-period start dates, flexible cost/conversion posting combining, new commands list, hledger manual reorg, easier close command, 10% more Ledger file compatible. Thank you to release contributors Chris Lemaire, Caleb Maclennan, Jonathan Dowland, J. B. Rainsberger, Michael Grünewald, Robert Nielsen, and Yann Büchau. What is hledger ? - Fast, reliable, free, multicurrency, double-entry, plain text accounting[1] software that runs on unix, mac, windows, and the web - Built around human-readable, version-controllable plain text files - Inspired by and largely compatible with Ledger CLI[2]; convertible to and from Beancount[3] - Written in Haskell for correctness and longevity. For help getting started, or more info, see https://hledger.org and join our chat via Matrix or IRC: https://hledger.org/support Newcomers, experts, contributors, sponsors, feedback are welcome! Aloha, -Simon [1] https://plaintextaccounting.org [2] https://ledger-cli.org [3] https://beancount.github.io

1 0

ANN: Haskell Tiny Game Jam 2023 Results
by Simon Michael 11 Mar '23

11 Mar '23

We are very pleased to announce.. the results of Haskell Tiny Game Jam 2023 ! Congratulations and thanks to all participants! - 55 entries in 4 categories from 28 entrants in 3 weeks - 109 reviews, 5 winners and 6 honourable mentions from 2 judges - Shell script to browse and play the games on all major platforms (single binary coming later maybe) - Readable source versions, useful development tips, informative blog posts This was the first Haskell game dev contest. The prize.. glory! Also fun, learning, and advancing Haskell's suitability for game dev and programming in the small. We invite you to come and play, read, and get inspired for the next one! https://github.com/haskell-game/tiny-games-hs

1 0

ANN: atomic-modify-general
by David Feuer 10 Mar '23

10 Mar '23

I just put together a new package, atomic-modify-general, for generalizations of the `atomicModifyIORef` operation. In particular: 1. Versions that allow a result of an arbitrary type (not necessarily a pair), where the caller passes in an extraction function. These work with `Array` and `SmallArray` from `primitive` as well as `IORef`. 2. A version that works with record types (not just pairs) whose first field is the new value to install in the `IORef`. This uses implementation details of the `atomicModifyMutVar#` primop as well as GHC's heap object layout to achieve better performance. Please try it out and let me know how it goes, and what extras you may want! Hackage: https://hackage.haskell.org/package/atomic-modify-general-0.1.0.0

3 7

Nearly lens examples
by Geraldus 10 Mar '23

10 Mar '23

Dear all! Do you have good usage examples of *nearly* lens, especially in composition with other lenses / prisms? Sincerely yours, Arthur.

1 0

PhD or Postdoc Position at LMU Munich about Verified Modal Logics
by Andrei Popescu 10 Mar '23

10 Mar '23

We are looking for a PhD student (4 years) or postdoctoral researcher (3 years) to work on the Isabelle formalization of modal model theory. The work will take place within the Chair of Theoretical Computer Science at LMU Munich under Jasmin Blanchette's supervision with the participation of two external experts: Cláudia Nalon (University of Brasília) and Sophie Tourret (Inria Nancy). Modal logics are extensions of classical logics with operators that allow for the qualification of truth. Model theory for modal logics is concerned with the interplay between the language (syntax, i.e., the set of its formulas) and its meaning (semantics, i.e., the structures over which the language is interpreted). There are, however, different ways of characterizing meaning for modal sentences and also several (well-established) results that allow for restriction on the sets of structures being considered. This project concerns the formalization in Isabelle of those results for general Kripke structures for generalized modal operators (i.e., of any arity). The goal is to produce a library that could then be used (and possibly extended) for specific applications, in particular those related to proof theory. The position is categorized as TV-L E13 according to the German salary scale. It includes some teaching obligations. The starting date is flexible. Please contact Jasmin Blanchette (jasmin.blanchette(a)ifi.lmu.de) for more information or if you want to apply. The application deadline is 15 April 2023.

1 0

Alpha Release of Keelung, the New Haskell DSL Designed for Secure and Fast Application Development
by Ting Wang 09 Mar '23

09 Mar '23

Hello developers, I'm Ting with BTQ. We are thrilled to announce the alpha release of Keelung, a new domain-specific language (DSL) designed to make fast, private, and secure application development easy for developers.Both Keelung and its compiler have been implemented in Haskell, enabling you to produce high-level zero-knowledge proofs protected by Haskell's cutting-edge type system while leveraging Haskell's extensive ecosystem and tooling. What's more, Keelung will be 100% open-source, aligning with our values of transparency, collaboration, and community-driven development.Check out our blog post <https://www.btq.com/en/blog/keelung-alpha-release> of Keelung alpha release for more detail. If you're interested in using Keelung to build privacy-preserving applications, please visit our GitHub repository <https://github.com/btq-ag/keelung> and Hackage <https://hackage.haskell.org/package/keelung>. Our documentation <https://btq.gitbook.io/keelung/> also provides detailed information on how to use Keelung, including installation instructions, examples, and tutorials.If you have any questions about Keelung or would like to contribute to the project, please start a thread on our GitHub discussions <https://github.com/btq-ag/keelung/discussions> page or reach out to us via email at desk(a)btq.li. We're always happy to help and would love to hear from you!Thank you and we can't wait to see what you build with it! Ting Wang (Ms.) Product Manager ty.wang(a)btq.li www.btq.com [image: twitter] <https://twitter.com/btq_ag> [image: linkedin] <https://www.linkedin.com/company/btqag/about/>

1 0

[ANN] Copilot 3.14
by Ivan Perez 09 Mar '23

09 Mar '23

(Apologies if you see this through multiple channels.) Hi everyone, I’m very excited to announce Copilot 3.14. 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 has been 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 the requirements elicitation tool FRET [4], and can target NASA’s Core Flight System and the Robot Operating System (ROS2) applications. This new version provides up-to-date compiler support, simplifies the API, and improves the documentation. For details, see [2]. As always, we’re releasing exactly 2 months since the last release. Our next release is scheduled for May 7th, 2023. We have almost completed the C99 unit tests, and plan to include those in the next version. Copilot is currently undergoing the qualification process necessary for NASA Class D Software. Current emphasis is on increasing test coverage, removing unnecessary dependencies, hiding internal definitions, and formatting the code to meet our new coding standards. Users are encouraged to participate by opening issues and asking questions via our github repo [3] There’s been many more updates on the Copilot front in the last few months. We’ll be able to announce more soon. Stay tuned. Happy Haskelling! Ivan [1] https://github.com/nasa/ogma [2] https://github.com/Copilot-Language/copilot/releases/tag/v3.14 [3] https://github.com/Copilot-Language/copilot [4] https://github.com/NASA-SW-VnV/fret

1 0

Call for Talks: Haskell Implementors' Workshop 2023
by Ryan Scott 08 Mar '23

08 Mar '23

ACM SIGPLAN Haskell Implementors' Workshop https://icfp23.sigplan.org/home/hiw-2023 Seattle, Washington, United States, September 4, 2023 Co-located with ICFP 2023 https://icfp23.sigplan.org/ Important dates --------------- Deadline: July 4, 2023 (AoE) Notification: August 4, 2023 Workshop: September 4, 2023 The 15th Haskell Implementors' Workshop is to be held alongside ICFP 2023 this year in Seattle. It is a forum for people involved in the design and development of Haskell implementations, tools, libraries, and supporting infrastructure to share their work and to discuss future directions and collaborations with others. Talks and/or demos are proposed by submitting an abstract, and selected by a small program committee. There will be no published proceedings. The workshop will be informal and interactive, with open spaces in the timetable and room for ad-hoc discussion, demos, and short lightning talks. Scope and target audience ------------------------- It is important to distinguish the Haskell Implementors' Workshop from the Haskell Symposium which is also co-located with ICFP 2023. The Haskell Symposium is for the publication of Haskell-related research. In contrast, the Haskell Implementors' Workshop will have no proceedings -- although we will aim to make talk videos, slides, and presented data available with the consent of the speakers. The Implementors' Workshop is an ideal place to describe a Haskell extension, describe works-in-progress, demo a new Haskell-related tool, or even propose future lines of Haskell development. Members of the wider Haskell community are encouraged to attend the workshop -- we need your feedback to keep the Haskell ecosystem thriving. Students working with Haskell are especially encouraged to share their work. The scope covers any of the following topics. There may be some topics that people feel we've missed, so by all means submit a proposal even if it doesn't fit exactly into one of these buckets: * Compilation techniques * Language features and extensions * Type system implementation * Concurrency and parallelism: language design and implementation * Performance, optimisation and benchmarking * Virtual machines and run-time systems * Libraries and tools for development or deployment Talks ----- We invite proposals from potential speakers for talks and demonstrations. We are aiming for 20-minute talks with 5 minutes for questions and changeovers. We want to hear from people writing compilers, tools, or libraries, people with cool ideas for directions in which we should take the platform, proposals for new features to be implemented, and half-baked crazy ideas. Please submit a talk title and abstract of no more than 300 words. Submissions can be made via HotCRP at https://icfphiw23.hotcrp.com until July 4 (anywhere on earth). We will also have a lightning talks session. These have been very well received in recent years, and we aim to increase the time available to them. Lightning talks should be ~7mins and are scheduled on the day of the workshop. Suggested topics for lightning talks are to present a single idea, a work-in-progress project, a problem to intrigue and perplex Haskell implementors, or simply to ask for feedback and collaborators. Program Committee ----------------- * Gergő Érdi (Standard Chartered Bank) * Sebastian Graf (Karlsruhe Institute of Technology) * Wen Kokke (University of Strathclyde) * Ryan Scott (Galois, Inc.) * Rebecca Skinner (Mercury) * Li-yao Xia (University of Edinburgh) Contact ------- * Ryan Scott <ryan.gl.scott at gmail.com>

1 0

Takeover request: unix-compat
by Mitchell Rosen 07 Mar '23

07 Mar '23

Hi all, I'd like to take over maintenance responsibility for the `unix-compat` package. Unfortunately, I've been unable to get in touch with the maintainer. I intend to make a release compatible with `unix-2.8`, and will be around to make subsequent bounds bumps and whatnot. You can find me on GitHub: https://github.com/mitchellwrosen Or Hackage: https://hackage.haskell.org/user/mitchellwrosen Thanks, Mitchell

4 6

[ANN] dunai-0.10.1 and bearriver-0.14.1
by Ivan Perez 07 Mar '23

07 Mar '23

Dear all, I'm happy to announce the release of Dunai 0.10.1 and Bearriver 0.14.1! Dunai is a reactive programming library structured around a notion of Monadic Stream Functions. Dunai can be used to implement other reactive and FRP frameworks on top, including Classic FRP and Arrowized FRP variants. Dunai comes with: - bearriver: API-compatible implementation of Yampa. (The Bear River is a tributary to the Yampa river.) - dunai-test: QuickCheck-based temporal testing library that can be connected with the testing system haskell-titan. See https://github.com/ivanperez-keera/dunai#features for details on Dunai's features. This new release introduces a breaking change in Monadic Stream Functions' instance of VectorSpaces. Most code using that instance should work without changes but, in some cases, the use of 'constantly' is now necessary. (This case is described in the discussion thread of issue #298.) * Summary of Version 0.10.1: - Implement dot in MSF's instance of VectorSpace (#298). - Enable FlexibleContexts in VectorSpace instance module (#344). As always, dunai, dunai-test and bearriver are released in sync. For details, see: - https://github.com/ivanperez-keera/dunai/releases/tag/v0.10.1 * Releases You can explore the current versions at: - https://hackage.haskell.org/package/dunai - https://hackage.haskell.org/package/dunai-test - https://hackage.haskell.org/package/bearriver * Code The github repo is located at: https://github.com/ivanperez-keera/dunai * What's coming This release comes exactly 2 months after the last release. The next release is planned for Apr 21, 2023. There are several issues open that you can contribute to: https://github.com/ivanperez-keera/dunai/issues Following our roadmap, the pending changes remain as follows: - Full conformance to style guide. - Benchmarks: Facilitate making sound, evidence-based decisions about suggested improvements to the implementation, by completing a series of benchmarks. * Donations Our project is now seeking donations to help continue developing dunai, create new open source libraries, new material, and give talks. Special thanks go to @johannes-riecken for sponsoring my work on the dunai project with a regular contribution. Github will match the first 5K donated, so if you donate $1/month, github will donate the same amount. No donation is too small. Any contribution will absolutely help. See https://github.com/sponsors/ivanperez-keera for details. If you can help, please come forward. All the best, Ivan

1 0

Take-over request for: snappy
by Andrey Prokopenko 06 Mar '23

06 Mar '23

Hello, - Few months ago Andrew Martin opened PR in `snappy`: https://github.com/bos/snappy/pull/10 <https://github.com/bos/snappy/pull/10> - The package is either direct or transient dependency for `tensorflow`, `kafka-client` and few more packages. - While forks maintenance is a well-known practice it creates burden on maintainers. - Moreover, I cannot easily fix cabal build for tensorflow for different GHC versions. Note for Bryan: I haven’t forked `snappy` so there will be no name clashes during the transfer. I would like to become a maintainer for `snappy` package and keep it up-to-date at least for a next few years. I have already followed that procedure a few years ago for `blaze-textual` package. (Recently I discovered a flaw in my maintenance setup and fixed it.) So my intent is to resolve recent PRs and to keep supporting for newer compiler versions and build tools. Please consider this message as a step 2 in take-over procedure: https://wiki.haskell.org/Taking_over_a_package <https://wiki.haskell.org/Taking_over_a_package> Kind Regards, Andrey Prokopenko

1 0

[ANNOUNCE] GHC 9.6.1-rc1 is now available
by Ben Gamari 04 Mar '23

04 Mar '23

The GHC team is very pleased to announce the availability of the first (and likely final) release candidate of GHC 9.6.1. As usual, binaries and source distributions are available at [downloads.haskell.org](https://downloads.haskell.org/ghc/9.6.1-rc1/). Beginning with GHC 9.6.1, GHC can be built as a cross-compiler to WebAssembly and JavaScript. This is an important step towards robust support for compiling Haskell to the Web, but there are a few caveats to be aware of in the 9.6 series: - Both the Javascript and WebAssembly backends are still at an early stage of development and are present in this release as a technology preview - Using GHC as a cross-compiler is not as easy as we would like it to be; in particular, there are challenges related to Template Haskell - GHC is not yet run-time retargetable; a given GHC binary targets exactly one platform, and both WebAssembly and JavaScript are considered platforms for this purpose. Cross-compilers must be built from source by their users We hope to lift all of these limitations in future releases. Additionally, 9.6.1 will include: - Significant latency improvements in the non-moving garbage collector - Efficient runtime support for delimited continuations - Improvements in compiler error messages - Numerous improvements in the compiler's memory usage See the [release notes][] for a comprehensive accounting of changes in this release. As always, one can find a migration guide to aid in transitioning from older releases on the [GHC Wiki][migration-guide]. We have also recently started extending our release process to cover a wider set of Linux distributions. In particular, we now offer Rocky 8 and Ubuntu 20.04 binary distributions which cover RedHat-derivative and distributions using older `glibc` releases (namely 2.27), respectively. Please do give this release a try and open a [ticket][] if you see anything amiss. If all goes well we expect the final release should be available by late next week. Happy Haskelling, ~ Ben [ticket]: https://gitlab.haskell.org/ghc/ghc/issues/ [migration-guide]: https://gitlab.haskell.org/ghc/ghc/-/wikis/migration/9.6 [release notes]: https://downloads.haskell.org/ghc/9.6.1-rc1/docs/users_guide/9.6.1-notes.ht…

1 0

dynamic web form generation for algebraic data types
by Olaf Klinke 03 Mar '23

03 Mar '23

Dear Cafe, has anyone ever attempted (and maybe succeeded) in building dynamic forms using one of the Haskell web frameworks (Yesod,Servant,...)? By "dynamic" form I mean a form that changes the number of fields based on selections the user makes in other fields of the form. For example, say one has an algebraic data type data T = Number Int | Check Bool T A form for such a type would initially consist of radio buttons or a drop-down list with options "Number" and "Check" that lets the user select the constructor. When "Number" is selected, an <input type="number"> field is shown. When "Check" is selected, an <input type="checkbox"> is displayed next to another form of this kind. In the end, one would use the GHC.Generics machinery to generate forms for a wide range of algebraic data types. I've seen this in the Clean language's iTask library [1] and it's very convenient. Of course this would involve a lot of JavaScript like document.createElement() as well as book-keeping how to re-asseble the fields into a T value upon submission. At least the latter is already handled by libraries such as yesod-form. Olaf [1] https://cloogle.org/src/#itasks/iTasks/UI/Editor/Generic [2] https://github.com/haskell-servant/servant-swagger/issues/80

5 8

Re: [Haskell-cafe] dynamic web form generation for algebraic data types
by Gustavo Bicalho 03 Mar '23

03 Mar '23

>From briefly reading the wiki page https://wiki.haskell.org/Tangible_Value, it looks like it relies on Applicative functors for combining values. So maybe the missing piece for sum-types was Selective functors https://hackage.haskell.org/package/selective? Gustavo Bicalho > ---------- Forwarded message ---------- > From: Olaf Klinke <olf(a)aatal-apotheke.de> > To: Ivan Perez <ivanperezdominguez(a)gmail.com> > Cc: "Haskell Café" <haskell-cafe(a)haskell.org> > Bcc: > Date: Thu, 02 Mar 2023 17:40:18 +0100 > Subject: Re: [Haskell-cafe] dynamic web form generation for algebraic data types > On Thu, 2023-03-02 at 07:34 -0800, Ivan Perez wrote: > > All of this reminds me of Conal Elliott's Tangible Values. > > > > http://conal.net/papers/Eros/ > > > > (Not for web but the idea still applies.) > > > > Ivan > > Yes, the concept has been re-invented multiple times, as is the case > with most good ideas. TVs are general enough to bolt a web interface on > top, I guess. > > Seems that Conal, too, has not solved the sum type problem. > The tangible value GADT > https://hackage.haskell.org/package/TV-0.5.0/docs/Interface-TV-Input.html > has a Pair constructor but not for Sum. I wonder whether there is a > deeper categorical reason for this. > > So I should re-phrase my question: > Has anyone extended tangible values to Generic types and given them a > modern html interface? > > Olaf

1 0

Re: [Haskell-cafe] Status of ghcup?
by Anthony Clayden 03 Mar '23

03 Mar '23

> Sigh. As a college educator who is trying to use Haskell in as many classes as possible, ... > you better fire up Notepad.exe. ... some decent syntax highlighting, Hi Todd, and Mig, I too feel your pain. And Windows seems to have always been a neglected child in distros -- even when SPJ was actually sponsored by MSoft. If you're only trying to give a flavour of Haskell for (say) a few weeks intro, I don't see that you even need all the drama of ghcup. Perhaps just ignore what it says on the GHC download pages, and grab the compiler plus minimal libraries. Then you can either defer a 'proper' install until students are motivated enough to go through the pain; or don't bother/they've gone on to other subjects. I agree syntax highlighting is very helpful for newbies: I use NotePad++ for editing and not even VSCode for compiling, but GHCi. I suspect these fully integrated dev environments are quite confusing for newbies. (Unless they've already experienced them with other languages.) Hard for me to be sure: they simply weren't a thing when I learned Haskell. These days I have installed VSCode; I seldom use it (just way too much clutter around the screen). AntC

9 16

[ANN] landlock 0.2.1.0
by Nicolas Trangez 27 Feb '23

27 Feb '23

I’m happy to announce the latest version of `landlock`, a Haskell library to access the Linux Landlock LSM API. This version updates the library to expose all Landlock features up to Linux 6.2 (Landlock ABI 3). It also introduces `landlocked`[1], a utility to spawn some process in a landlocked environment, and serves as a demo of how to use the API (next to the library documentation[2] and README.md[3]). It’s available on Hackage[4] and GitHub[5]. The Linux kernel Landlock API provides unprivileged access control. The goal of Landlock is to enable to restrict ambient rights (e.g. global filesystem access) for a set of processes. Because Landlock is a stackable LSM, it makes possible to create safe security sandboxes as new security layers in addition to the existing system-wide access- controls. This kind of sandbox is expected to help mitigate the security impact of bugs or unexpected/malicious behaviors in user space applications. Landlock empowers any process, including unprivileged ones, to securely restrict themselves. For more information, see the Landlock homepage[6] and its kernel documentation[7]. [1] https://github.com/NicolasT/landlock-hs/blob/27d2d95478f8c85cfbf4025bb41d57… [2] https://hackage.haskell.org/package/landlock-0.2.1.0/docs/System-Landlock.h… [3] https://github.com/NicolasT/landlock-hs/tree/main/landlock#readme [4] https://hackage.haskell.org/package/landlock-0.2.1.0 [5] https://github.com/NicolasT/landlock-hs [6] https://landlock.io/ [7] https://docs.kernel.org/userspace-api/landlock.html

1 0

[Haskell] [ANNOUNCE] GHC 9.2.7 released
by Zubin Duggal 27 Feb '23

27 Feb '23

The GHC developers are happy to announce the availability of GHC 9.2.7. Binary distributions, source distributions, and documentation are available at [downloads.haskell.org](https://downloads.haskell.org/ghc/9.2.7). Download Page: https://www.haskell.org/ghc/download_ghc_9_2_7.html Blog Post: https://www.haskell.org/ghc/blog/20230227-ghc-9.2.7-released.html This release is primarily a bugfix release addressing a few issues found in 9.2.6. These include: * A fix for a bug with the RTS linker being unable to resolve the `setKeepCafs` symbol which started being used by the GHC library in 9.2.6, resulting in code depending on this symbol failing to load in GHCi or via a compile time splice when using a statically linked GHC, such as on Windows (#22961). * A fix a bug with the alignment of RTS data structures that could result in segfaults when compiled with high optimisation settings on certain platforms (#22975 , #22965). * A fix for a bug in the simplifier related to placeholder values (rubbish literals) emitted by the worker/wrapper optimisation leading to -dcore-lint errors and compiler panics in certain cases (#19882, #22914, #23000). * Easier installation of binary distribution on MacOS platforms by changing the installation Makefile to remove the quarantine attribute when installing. * ... and a few more. See the [release notes] for a full accounting. As some of the fixed issues do affect correctness users are encouraged to upgrade promptly. We would like to thank Microsoft Azure, GitHub, IOG, the Zw3rk stake pool, Well-Typed, Tweag I/O, Serokell, Equinix, SimSpace, Haskell Foundation, and other anonymous contributors whose on-going financial and in-kind support has facilitated GHC maintenance and release management over the years. Finally, this release would not have been possible without the hundreds of open-source contributors whose work comprise this release. As always, do give this release a try and open a [ticket][] if you see anything amiss. Happy compiling, - Zubin [ticket]: https://gitlab.haskell.org/ghc/ghc/-/issues/new [release notes]: https://downloads.haskell.org/~ghc/9.2.7/docs/html/users_guide/9.2.7-notes.…

1 0

Munich Haskell Meeting, 2023-02-28 @ 19:30
by Leah Neukirchen 27 Feb '23

27 Feb '23

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

1 1

[ANN] NASA's Ogma 1.0.7
by Ivan Perez 25 Feb '23

25 Feb '23

Hi everyone! I'm really excited to announce the release of Ogma 1.0.7! Ogma is a NASA tool that facilitates integrating runtime monitors or runtime verification applications into other systems. Ogma extends Copilot [1], a high-level runtime verification framework that generates hard real-time code. In spite of the small increase in the version number, the feature included in this version is big: we now generate monitors for Robot Operating System (ROS 2) applications. Use cases supported by Ogma also include generating monitors directly from requirements specified using a structure natural language framework, and producing NASA Core Flight System (cFS) monitoring applications. For more details, including videos of monitors being generated and flown in simulators, see: https://github.com/nasa/ogma * Releases Ogma is released as a collection of packages in Hackage. The entry point is https://hackage.haskell.org/package/ogma-cli. * Code The github repo is located at: https://github.com/nasa/ogma. * What's coming The next release is planned for March 21st, 2023. Ogma is currently undergoing the qualification process necessary for NASA Class D Software. Apart from the changes required by that process, we also have the following in our roadmap: - Extend ROS 2 monitors with further information about sources of violations. - Add tests to generated code. - Simplify NASA cFS monitor generation process. Happy Haskelling! Ivan [1] https://github.com/Copilot-Language/copilot/

1 0

KSF Media Ab hiring Senior Developer in Helsinki, Finland (repost)
by Kari Pahula 24 Feb '23

24 Feb '23

This was posted already once in November: https://mail.haskell.org/pipermail/haskell-cafe/2022-November/135687.html We got a second open position. KSF Media is Finland’s largest Swedish language news media group. Our products include Hufvudstadsbladet, Västra Nyland, Östnyland and HBL Junior. KSF Media’s digital products are growing fast and our focus is in digital subscription sales and product development. We are now looking for a new member to join our digital development team to create outstanding news media products for our readers. We are a small but capable team with a lean way of working and passion to learn new things every day. Our way of working • Kanban • Pair Programming, Code Reviews • Git, CI/CD (multiple deployments a day), Trunk Based Development • Working in the open. Our whole frontend is open source: https://github.com/KSF-Media/affresco and https://github.com/KSF-Media/mosaico Our stack • Most new developments happen in Haskell, PureScript and Javascript • Cloud Infrastructure as Code (Google Cloud, Kubernetes, Terraform) • Microservices environment with REST APIs What we expect from you is some relevant work experience and • English language. Swedish or Finnish knowledge is a plus • Knowledge of the principles behind the modern Web stack: things like MVC, Relational Databases and Testing • High motivation, self-steering, willingness to learn and dive into things, good social skills and good sense of humour • Interest in functional programming, news media and making the world a better place • Awareness of some UX principles, API design (and optionally UI design) and empathy for the users of your code • This job opportunity requires the successful candidate to relocate to Finland and offers a hybrid work arrangement, combining remote work and on-site presence. What we can offer • Competitive salary and benefits • The best co-workers • Office in the most central location in Helsinki • Flexible terms, with possibility to remote working Interested? Please apply via LinkedIn <https://www.linkedin.com/jobs/view/3498430755> or drop a line at antti.haarala(a)ksfmedia.fi no later than on the 10th of March.

1 0

Status of ghcup?
by Dominick Samperi 23 Feb '23

23 Feb '23

I watched an interesting YouTube video explaining how to install and use the Haskell extension in VS code, but the information appears to be obsolete, because there is no mention of ghcup, and ghcup is now required, along with a new version of the Haskell extension (the old one is labeled "legacy"). Unfortunately, I could not install ghcup on Windows due to obscure PowerShell security issues, or missing libraries in MSYS. While wrestling with this problem I discovered that Unix tools from Rtools must not be in PATH while working with Stack, probably due to incompatible MSYS versions. But removing Rtools from PATH does not resolve the ghcup installation problems. Any tips on ghcup installation under Windows would be appreciated. Thanks, Dominick

7 8

CfP - HLPP'2023 High-Level Parallel Programming and Applications
by VIRGINIA NICULESCU 23 Feb '23

23 Feb '23

[Apologies if you receive multiple copies of this CFP] CALL FOR PAPERS >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> HLPP 2023 16th International Symposium on International Symposium on High-Level Parallel Programming and Applications Cluj-Napoca, Romania June 29-30, 2023 https://www.cs.ubbcluj.ro/hlpp2023 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Important Dates * Abstract submission: April 3, 2023 * Paper submission: April 7, 2023 * Notification: May 15, 2023 * Draft proceedings version: June 9, 2023 * Conference: June 29-30, 2023 * Journal paper submission: September 2023 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Aims and Scope As processor and system manufacturers adjust their roadmaps towards increasing levels of both inter and intra-chip parallelism, so the urgency of reorienting the mainstream software industry towards these architectures grows. At present, popular parallel and distributed programming methodologies are dominated by low-level techniques such as send/receive message passing, or equivalently unstructured shared memory mechanisms. Higher-level, structured approaches offer many possible advantages and have a key role to play in the scalable exploitation of ubiquitous parallelism. HLPP symposia provide a forum for discussion and research about such high-level approaches to parallel and distributed programming. Topics HLPP 2023 invites papers on all topics in high-level parallel programming, its tools and applications including, but not limited to, the following aspects: * High-level parallel programming and performance models (e.g. BSP, CGM, LogP, MPM, etc.) and tools * Declarative parallel and distributed programming methodologies based on functional, logical, data-flow, actor, and other paradigms * Algorithmic skeletons, patterns, etc. and constructive methods * High-level parallelism in programming languages and libraries (e.g, OCaml, Haskell, Scala, C++, etc.): semantics and implementation * Verification of declarative parallel and distributed programs * Efficient code generation, auto-tuning, and optimization for parallel and distributed programs * Model-driven software engineering for parallel and distributed systems * Domain-specific languages: design, implementation, and applications * High-level programming models for heterogeneous/hierarchical platforms with accelerators, e.g., GPU, Many-core, DSP, VPU, FPGA, etc. * High-level parallel methods for large structured and semi-structured datasets * Applications of parallel and distributed systems using high-level languages and tools * Teaching experience with high-level tools and methods for parallel and distributed computing Past HLPP Symposia: https://hlpp.eu<https://hlpp.eu/> Submission Papers submitted to HLPP 2023 must describe original research results and must not have been published or simultaneously submitted anywhere else. As it is traditional for HLPP symposia, the accepted papers will be distributed at the symposium in draft proceedings, and then the papers will be published in the special issue of an international journal (the name of the journal is to be confirmed). In the past years, the journals were the International Journal of Parallel Programming and The Journal of Supercomputing. Each paper will receive a minimum of three reviews by members of the international technical program committee. Papers will be selected based on their originality, relevance, technical clarity, and quality of presentation. Manuscripts must be prepared with the Springer IJSS latex macro package using the single column option (\documentclass[smallextended]{svjour3}) and submitted via the EasyChair Conference Management System as one pdf file. The strict page limit for initial submission and camera-ready version is 20 pages in the aforementioned format. At least one author of each accepted paper must register for the HLPP 2023 symposium and present the paper. After the symposium the authors of the papers will have ample time to revise their papers and to incorporate both reviewer feedback and presentation feedback from the whole audience during the symposium. Organization * Virginia Niculescu, “Babeş-Bolyai” University of Cluj-Napoca, Romania * Adrian Sterca, “Babeş-Bolyai” University of Cluj-Napoca, Romania * Darius Bufnea, “Babeş-Bolyai” University of Cluj-Napoca, Romania Steering Committee * Gaétan Hains (Université Paris-Est Créteil, France) * Clemens Grelck (Universiteit van Amsterdam, Netherlands) * Kiminori Matsuzaki (Kochi University of Technology, Japan) * Christoph W. Kessler (Linköping University, Sweden) * Herbert Kuchen (University of Münster, Germany) * Marco Danelutto (University of Pisa, Italy) * Ines Dutra (University of Porto, Portugal) * Arturo Gonzalez-Escribano (Universidad de Valladolid, Spain) * Frédéric Dabrowski, Université d'Orléans, France) * Virginia Niculescu (“Babes-Bolyai” University, Romania) We are looking forward to your submissions and to seeing you in Cluj-Napoca, Romania in June 2022. Best regards, Virginia Niculescu ---------------------------------------------- Dr. Virginia Niculescu Faculty of Mathematics and Computer Science "Babes-Bolyai" University E-mail: virginia.niculescu(a)ubbcluj.ro, vniculescu(a)cs.ubbcluj.ro<mailto:vniculescu@cs.ubbcluj.ro> Web: http://www.cs.ubbcluj.ro/~vniculescu DISCLAIMER Prezentul mesaj ?i orice documente ata?ate pot con?ine informa?ii confiden?iale sau sensibile care apar?in Universită?ii Babe?-Bolyai din Cluj-Napoca. Con?inutul mesajului nu poate fi dezvăluit sau utilizat de către altcineva decât destinatarul, persoană fizică sau juridică. Dacă a?i primit acest mesaj dintr-o eroare, vă rugăm să ne anun?ati imediat, ca răspuns la mesajul de fa?ă, ?i să ?terge?i apoi din sistemul dvs. mesajul fără a-l copia sau deschide. Prin prezenta vi se notifică faptul că orice dezvaluire, copiere, distribuire sau ini?ierea/omiterea unor ac?iuni pe baza prezentelor informa?ii sunt strict interzise ?i atrag răspunderea civilă ?i/sau penală (art. 302 Noul Cod Penal). UBB nu este răspunzătoare pentru modificările care pot fi aduse prezentului mesaj ?i nici pentru întârzierile care pot surveni în recep?ionarea acestuia. De asemenea, nu putem garanta integritatea mesajului ?i nici că acesta este lipsit de viru?i, interceptări sau interferen?e de orice natură. ================= The contents of this email message and any attachments may contain confidential and/or privileged information belonging to Babe?-Bolyai University of Cluj-Napoca. This information is intended solely for the addressee, natural or legal person, and is legally protected from disclosure and may not be used by anyone other than the intended recipient. If you are not the intended recipient of this message, or if this message has been addressed to you in error, please immediately alert the sender by reply email and then delete this message and any attachments. You are hereby notified that any use, dissemination, copying, or storage of this message or its attachments as well as taking any action in reliance on the contents of this information is strictly prohibited and entails civil and/or criminal liability (under Art. 302 of the New Criminal Code). UBB accepts no liability for any errors or omissions in the contents of this message. Email transmission cannot be guaranteed to be secure or error-free, as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. UBBCLUJ <https://www.ubbcluj.ro/ro/politici/>

1 0

Attoparsec.ByteString.Char8 or Attoparsec.ByteString for diff output?
by Pedro B. 21 Feb '23

21 Feb '23

Dear Listers, I am developing a program to parse dif output taken from stdin (as in diff file1 file2 | myApp) or from a file. I am reading the input as ByteString in either case and I am parsing it Attoparsec. My question is, Should I use Data.Attoparsec.ByteString.Char8 or Data.Attoparsec.ByteString? So far, I've been using Data.Attoparsec.ByteString.Char8 and it works for my sample files, which are in utf8 or, latin1, or the default Windows encoding. What do you suggest? Note: I sent this question previously to the beginners list, but someone suggested to me privately to send it to this list. Regards, Pedro Borges

3 8

Re: [Haskell-cafe] Takeover request: Haskell CSS Syntax
by Olaf Klinke 18 Feb '23

18 Feb '23

Adrian, you probably know this, but: (1) Instead of a takeover, you could ask Tomas Carnecky to become merely a co-maintainer on hackage which would put you in power to sync the github and hackage versions. (2) At least with stack you can specify a github fork as dependency of your project. It is not nice, but I was forced to do the same when a repo owner ignored my pull request. For example # cabal file. # Note: xls-0.1.3 is the latest hackage version build-depends: xls >= 0.1.4 # stack.yaml extra-deps: - git: https://github.com/olafklinke/xls.git commit: 4e7a2ba639cc72678e4e40a06afd3c481d63f2e3 In your case, though, 0.1.0.0 is the package number on hackage as well as in the more up-to-date githup repo, so I don't know how the resolver would figure out which to use. Safer would be to fork and increment the cabal package version number, then proceed as above. You can later simply delete the entry in stack.yaml when your fork has been merged into hackage. Olaf > Hi, > > I'd like to request to take over the css-syntax hackage! The lead > developer of which seems to be barely active. They did accept someone > else's year-old pull request to fix an issue I was having regarding > upgrading to Text v2 upon being prodded, but hasn't responded to > communications since regarding publishing this update to Hackage. > > I am developing my own (NLnet-funded) noJS browser engine in Haskell, > and have released several modular components of it to Hackage in the > hopes they will be useful to others for other purposes. I've > benefited > tremendously from Haskell CSS Syntax & would like to see the project > continue, I can manage it as one of those subcomponents. I do not see > much further development being required, especially considering how > stable the W3C strives to keep part of the spec extremely stable. > > My communications to Haskell CSS Syntax: > https://github.com/wereHamster/haskell-css-syntax/issues/5 > https://github.com/wereHamster/haskell-css-syntax/pull/4 > > Thoughts? > > Adrian Cochrane > OpenWork Ltd

5 6

Re: [Haskell-cafe] [ANNOUNCE] GHC 9.6.1-alpha3 is now available
by Ben Gamari 15 Feb '23

15 Feb '23

George Colpitts <george.colpitts(a)gmail.com> writes: > Hi > > I get a strange warning on MacOS when I do ./configure: > > checking Xcode version... xcode-select: error: tool 'xcodebuild' requires > Xcode, but active developer directory '/Library/Developer/CommandLineTools' > is a command line tools instance > not found (too old?) > > > I also get a related strange warning when I do a compile: > > ghc hello.hs > [1 of 2] Compiling Main ( hello.hs, hello.o ) [Missing object > file] > [2 of 2] Linking hello [Objects changed] > ld: warning: directory not found for option > '-L/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX12.1.sdk/usr/lib' > Hmm, that is indeed odd. It sounds like you Xcode installation may be broken. Did you upgrade your operating system recently? Do you have Xcode, the CLT package, or both installed? Cheers, - Ben

1 0

Takeover request: Haskell CSS Syntax
by Adrian Lyall Cochrane 15 Feb '23

15 Feb '23

Hi, I'd like to request to take over the css-syntax hackage! The lead developer of which seems to be barely active. They did accept someone else's year-old pull request to fix an issue I was having regarding upgrading to Text v2 upon being prodded, but hasn't responded to communications since regarding publishing this update to Hackage. I am developing my own (NLnet-funded) noJS browser engine in Haskell, and have released several modular components of it to Hackage in the hopes they will be useful to others for other purposes. I've benefited tremendously from Haskell CSS Syntax & would like to see the project continue, I can manage it as one of those subcomponents. I do not see much further development being required, especially considering how stable the W3C strives to keep part of the spec extremely stable. My communications to Haskell CSS Syntax: https://github.com/wereHamster/haskell-css-syntax/issues/5 https://github.com/wereHamster/haskell-css-syntax/pull/4 Thoughts? Adrian Cochrane OpenWork Ltd Lead developer of: libdggs geospatial analysis Rhapsode & Haphaestus web browsers

1 0

[ANNOUNCE] GHC 9.6.1-alpha3 is now available
by Ben Gamari 14 Feb '23

14 Feb '23

The GHC team is very pleased to announce the availability of GHC 9.6.1-alpha3. As usual, binaries and source distributions are available at downloads.haskell.org: https://downloads.haskell.org/ghc/9.6.1-alpha3/ Beginning with GHC 9.6.1, GHC can be built as a cross-compiler to WebAssembly and JavaScript. This is an important step towards robust support for compiling Haskell to the Web, but there are a few caveats to be aware of in the 9.6 series: - Both the Javascript and WebAssembly backends are still at an early stage of development and are present in this release as a technology preview - Using GHC as a cross-compiler is not as easy as we would like it to be; in particular, there are challenges related to Template Haskell - GHC is not yet run-time retargetable; a given GHC binary targets exactly one platform, and both WebAssembly and JavaScript are considered platforms for this purpose. Cross-compilers must be built from source by their users We hope to lift all of these limitations in future releases. Additionally, 9.6.1 will include: - Significant latency improvements in the non-moving garbage collector - Efficient runtime support for delimited continuations - Improvements in compiler error messages - Numerous improvements in the compiler's memory usage See the [release notes] for a comprehensive accounting of changes in this release. As always, one can find a [migration guide] to aid in transitioning from older releases on the GHC Wiki. We have also recently started extending our release process to cover a wider set of Linux distributions. In particular, we now offer Rocky 8 and Ubuntu 20.04 binary distributions which cover RedHat-derivative and distributions using older `glibc` releases (namely 2.27), respectively. Please do give this release a try and open a [ticket] if you see anything amiss. Cheers, - Ben [ticket]: https://gitlab.haskell.org/ghc/ghc/issues/ [migration guide]: https://gitlab.haskell.org/ghc/ghc/-/wikis/migration/9.6 [release notes]: https://downloads.haskell.org/ghc/9.6.1-alpha3/docs/users_guide/9.6.1-notes…

1 0

ICFP 2023: Last Call for Papers
by ICFP Publicity 14 Feb '23

14 Feb '23

PACMPL Volume 7, Issue ICFP 2023 Call for Papers Accepted papers to be invited for presentation at The 28th ACM SIGPLAN International Conference on Functional Programming Seattle, USA http://icfp23.sigplan.org/ ### Important dates (All dates are in 2023 at 11.59pm anywhere on earth.) Submission deadline: 1 March 2023 (Wednesday) (https://icfp23.hotcrp.com) Author response: 1 May (Monday)--4 May (Thursday) Round 1 notification: 18 May (Thursday) Round 2 notification: 29 June (Thursday) Camera-ready deadline: 20 July (Thursday) Conference: 4 September (Monday)--9 September (Saturday) ### About PACMPL Proceedings of the ACM on Programming Languages (PACMPL <https://pacmpl.acm.org/>) is a Gold Open Access journal publishing research on all aspects of programming languages, from design to implementation and from mathematical formalisms to empirical studies. Each issue of the journal is devoted to a particular subject area within programming languages and will be announced through publicised Calls for Papers, like this one. ### Scope [PACMPL](https://pacmpl.acm.org/) issue ICFP 2023 seeks original papers on the art and science of functional programming. Submissions are invited on all topics from principles to practice, from foundations to features, and from abstraction to application. The scope includes all languages that encourage functional programming, including both purely applicative and imperative languages, as well as languages with objects, concurrency, or parallelism. Topics of interest include (but are not limited to): * Language Design: concurrency, parallelism, and distribution; modularity; components and composition; metaprogramming; macros; pattern matching; type systems; type inference; dependent types; effect types; gradual types; refinement types; session types; interoperability; domain-specific languages; imperative programming; object-oriented programming; logic programming; probabilistic programming; reactive programming; generic programming; bidirectional programming. * Implementation: abstract machines; virtual machines; interpretation; compilation; compile-time and run-time optimisation; garbage collection and memory management; runtime systems; multi-threading; exploiting parallel hardware; interfaces to foreign functions, services, components, or low-level machine resources. * Software-Development Techniques: algorithms and data structures; design patterns; specification; verification; validation; proof assistants; debugging; testing; tracing; profiling; build systems; program synthesis. * Foundations: formal semantics; lambda calculus; program equivalence; rewriting; type theory; logic; category theory; computational effects; continuations; control; state; names and binding; program verification. * Analysis and Transformation: control flow; data flow; abstract interpretation; partial evaluation; program calculation. * Applications: symbolic computing; formal-methods tools; artificial intelligence; systems programming; distributed systems and web programming; hardware design; databases; scientific and numerical computing; graphical user interfaces; graphics and multimedia; GPU programming; scripting; system administration; security. * Education: teaching introductory programming; mathematical proof; algebra. Submissions will be evaluated according to their relevance, correctness, significance, originality, and clarity. Each submission should explain its contributions in both general and technical terms, clearly identifying what has been accomplished, explaining why it is significant, and comparing it with previous work. The technical content should be accessible to a broad audience. PACMPL issue ICFP 2023 also welcomes submissions in two separate categories — Functional Pearls and Experience Reports — that must be marked as such when submitted and that need not report original research results. Detailed guidelines on both categories are given at the end of this call. Submissions from underrepresented groups are encouraged. Authors who require financial support to attend the conference can apply for PAC funding (http://www.sigplan.org/PAC/) The General Chair and PC Chair may not submit papers. PC members (other than the PC Chair) may submit papers. However, SIGPLAN guidelines dictate that they be held to a higher standard: a PC paper can be accepted if after the discussion it has at least one strongly-supportive review and no detractors. Each PC member may be listed as a coauthor on a maximum of three submissions. Please contact the Programme Chair if you have questions or are concerned about the appropriateness of a topic. ### Preparation of submissions *Deadline*: The deadline for submissions is **Wednesday, March 1, 2023**, Anywhere on Earth (<https://www.timeanddate.com/time/zones/aoe>). This deadline will be strictly enforced. *Formatting*: Submissions must be in PDF format, printable in black and white on US Letter sized paper and interpretable by common PDF tools. All submissions must adhere to the "ACM Small" template that is available (in both LaTeX and Word formats) from <https://www.acm.org/publications/authors/submissions>. There is a limit of **25 pages for a full paper or Functional Pearl** and **12 pages for an Experience Report**; in either case, the bibliography and an optional clearly marked appendix will not be counted against these limits. Submissions that exceed the page limits or, for other reasons, do not meet the requirements for formatting, will be summarily rejected. See also PACMPL's Information and Guidelines for Authors at <https://pacmpl.acm.org/authors.cfm>. *Submission*: Submissions will be accepted at <https://icfp23.hotcrp.com/> Improved versions of a paper may be submitted at any point before the submission deadline using the same web interface. *Author Response Period*: Authors will have a 72-hour period, starting at 12pm UTC on *Monday, May 1, 2023*, to read reviews and respond to them. *Appendix and Supplementary Material*: Authors have the option to include a clearly marked appendix and/or to attach supplementary material to a submission, on the understanding that reviewers may choose not to look at such an appendix or supplementary material. Supplementary material may be uploaded as a separate PDF document or tarball. Any supplementary material **must** be uploaded **at submission time**, not by providing a URL in the paper that points to an external repository. Authors are free to upload both anonymised and non-anonymised supplementary material. Anonymised supplementary material will be visible to reviewers immediately; non-anonymised supplementary material (which must be submitted separately) will be revealed to reviewers only after they have submitted their review of the paper and learned the identity of the author(s). *Authorship Policies*: All submissions are expected to comply with the ACM Policies for Authorship that are detailed at <https://www.acm.org/publications/authors/information-for-authors>. *Republication Policies*: Each submission must adhere to SIGPLAN's republication policy, as explained on the web at <http://www.sigplan.org/Resources/Policies/Republication>. *ORCID*: ORCID provides a persistent digital identifier (an ORCID iD) that you own and control, and that distinguishes you from every other researcher: https://orcid.org/. ACM now require an ORCID iD for every author of a paper, not just the corresponding author. So, the author who is filling out the permission form should make sure they have the ORCID iDs for all of their coauthors before filling out the form. Any authors who do not yet have an ORCID iD can go to https://orcid.org/register to have one assigned. ### Review Process This section outlines the two-stage process with lightweight double-blind reviewing that will be used to select papers for PACMPL issue ICFP 2023. **New this year**: ICFP 2023 will have an Associate Chair who will help the PC Chair monitor reviews, solicit external expert reviews for submissions when there is not enough expertise on the committee, and facilitate reviewer discussions. *PACMPL issue ICFP 2023 will employ a two-stage review process.* The first stage in the review process will assess submitted papers using the criteria stated above and will allow for feedback and input on initial reviews through the author response period mentioned previously. As a result of the review process, a set of papers will be conditionally accepted and all other papers will be rejected. Authors will be notified of these decisions on **May 18, 2023**. Authors of conditionally accepted papers will be provided with committee reviews along with a set of mandatory revisions. By June 15, 2023, the authors may provide a second submission. The second and final reviewing phase assesses whether the mandatory revisions have been adequately addressed by the authors and thereby determines the final accept/reject status of the paper. The intent and expectation is that the mandatory revisions can feasibly be addressed within three weeks. The second submission should clearly identify how the mandatory revisions were addressed. To that end, the second submission must be accompanied by a cover letter mapping each mandatory revision request to specific parts of the paper. The cover letter will facilitate a quick second review, allowing for confirmation of final acceptance within two weeks. Conversely, the absence of a cover letter will be grounds for the paper's rejection. *PACMPL issue ICFP 2023 will employ a lightweight double-blind reviewing process.* To facilitate this, submitted papers must adhere to two rules: 1. **author names and institutions must be omitted**, and 2. **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 judgement 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 anonymised). In addition, authors should feel free to disseminate their ideas or draft versions of their papers as they normally would. For instance, authors may post drafts of their papers on the web or give talks on their research ideas. ### Information for Authors of Accepted Papers * As a condition of acceptance, final versions of all papers must adhere to the ACM Small format. The page limit for the final versions of papers will be increased by two pages to help authors respond to reviewer comments and mandatory revisions: **27 pages plus bibliography for a regular paper or Functional Pearl, 14 pages plus bibliography for an Experience Report**. * Authors of accepted submissions will be required to agree to one of the three ACM licensing options, one of which is Creative Commons CC-BY publication; this is the option recommended by the PACMPL editorial board. A reasoned argument in favour of this option can be found in the article [Why CC-BY?](https://oaspa.org/why-cc-by/) published by OASPA, the Open Access Scholarly Publishers Association. The other options are copyright transfer to ACM or retaining copyright but granting ACM exclusive publication rights. * PACMPL is a Gold Open Access journal, and authors are encouraged to publish their work under a CC-BY license. Gold Open Access guarantees permanent free online access to the definitive version in the ACM Digital Library, and the recommended CC-BY option also allows anyone to copy and distribute the work with attribution. Gold Open Access has been made possible by generous funding through ACM SIGPLAN, which will cover all open access costs in the event authors cannot. Authors who can cover the costs may do so by paying an Article Processing Charge (APC). PACMPL, SIGPLAN, and ACM Headquarters are committed to exploring routes to making Gold Open Access publication both affordable and sustainable. * ACM Author-Izer is a unique service that enables ACM authors to generate and post links on either their home page or institutional repository for visitors to download the definitive version of their articles from the ACM Digital Library at no charge. Downloads through Author-Izer links are captured in official ACM statistics, improving the accuracy of usage and impact measurements. Consistently linking to the definitive version of an ACM article should reduce user confusion over article versioning. After an article has been published and assigned to the appropriate ACM Author Profile pages, authors should visit <http://www.acm.org/publications/acm-author-izer-service> to learn how to create links for free downloads from the ACM DL. * 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. * Authors of each accepted submission are invited to attend and be available for the presentation of that paper at the conference. The schedule for presentations will be determined and shared with authors after the full program has been selected. ### Artifact Evaluation Authors of papers that are conditionally accepted in the first phase of the review process will be encouraged (but not required) to submit supporting materials for Artifact Evaluation. These items will then be reviewed by an Artifact Evaluation Committee, separate from the paper Review Committee, whose task is to assess how the artifacts support the work described in the associated paper. Papers that go through the Artifact Evaluation process successfully will receive a seal of approval printed on the papers themselves. Authors of accepted papers will be encouraged to make the supporting materials publicly available upon publication of the papers, for example, by including them as "source materials" in the ACM Digital Library. An additional seal will mark papers whose artifacts are made available, as outlined in the ACM guidelines for artifact badging. Participation in Artifact Evaluation is voluntary and will not influence the final decision regarding paper acceptance. ### Special categories of papers In addition to research papers, PACMPL issue ICFP solicits two kinds of papers that do not require original research contributions: Functional Pearls, which are full papers, and Experience Reports, which are limited to half the length of a full paper. Authors submitting such papers should consider the following guidelines. #### Functional Pearls A Functional Pearl is an elegant essay about something related to functional programming. Examples include, but are not limited to: * a new and thought-provoking way of looking at an old idea * an instructive example of program calculation or proof * a nifty presentation of an old or new data structure * an interesting application of functional programming techniques * a novel use or exposition of functional programming in the classroom While pearls often demonstrate an idea through the development of a short program, there is no requirement or expectation that they do so. Thus, they encompass the notions of theoretical and educational pearls. Functional Pearls are valued as highly and judged as rigorously as ordinary papers, but using somewhat different criteria. In particular, a pearl is not required to report original research, but, it should be concise, instructive, and entertaining. A pearl is likely to be rejected if its readers get bored, if the material gets too complicated, if too much-specialised knowledge is needed, or if the writing is inelegant. The key to writing a good pearl is polishing. A submission that is intended to be treated as a pearl must be marked as such on the submission web page and should contain the words "Functional Pearl" somewhere in its title or subtitle. These steps will alert reviewers to use the appropriate evaluation criteria. Pearls will be combined with ordinary papers, however, for the purpose of computing the conference's acceptance rate. #### Experience Reports The purpose of an Experience Report is to describe the experience of using functional programming in practice, whether in industrial application, tool development, programming education, or any other area. Possible topics for an Experience Report include, but are not limited to: * insights gained from real-world projects using functional programming * comparison of functional programming with conventional programming in the context of an industrial project or a university curriculum * project-management, business, or legal issues encountered when using functional programming in a real-world project * curricular issues encountered when using functional programming in education * real-world constraints that created special challenges for an implementation of a functional language or for functional programming in general An Experience Report is distinguished from a normal PACMPL issue ICFP paper by its title, by its length, and by the criteria used to evaluate it. * Both in the papers and in any citations, the title of each accepted Experience Report must end with the words "(Experience Report)" in parentheses. The acceptance rate for Experience Reports will be computed and reported separately from the rate for ordinary papers. * Experience Report submissions can be at most 12 pages long, excluding bibliography. * Each accepted Experience Report will be presented at the conference, but depending on the number of Experience Reports and regular papers accepted, authors of Experience Reports may be asked to give shorter talks. * Because the purpose of Experience Reports is to enable our community to understand the application of functional programming, an acceptable Experience Report need not add to the body of knowledge of the functional-programming community by presenting novel results or conclusions. It is sufficient if the Report describes an illuminating experience with functional programming, or provide evidence for a clear thesis about the use of functional programming. The experience or thesis must be relevant to ICFP, but it need not be novel. The review committee will accept or reject Experience Reports based on whether they judge the paper to illuminate some aspect of the use of functional programming. Anecdotal evidence will be acceptable provided it is well-argued and the author explains what efforts were made to gather as much evidence as possible. Typically, papers that show how functional programming was used are more convincing than papers that say only that functional programming was used. It can be especially effective to present comparisons of the situations before and after the experience described in the paper, but other kinds of evidence would also make sense, depending on context. Experience drawn from a single person's experience may be sufficient, but more weight will be given to evidence drawn from the experience of groups of people. An Experience Report should be short and to the point. For an industrial project, it should make a claim about how well functional programming worked and why; for a pedagogy paper, it might make a claim about the suitability of a particular teaching style or educational exercise. Either way, it should produce evidence to substantiate the claim. If functional programming worked in this case in the same ways it has worked for others, the paper need only summarise the results — the main part of the paper should discuss how well it worked and in what context. Most readers will not want to know all the details of the experience and its implementation, but the paper should characterise it and its context well enough so that readers can judge to what degree this experience is relevant to their own circumstances. The paper should take care to highlight any unusual aspects; specifics about the experience are more valuable than generalities about functional programming. If the paper not only describes experience but also presents new technical results, or if the experience refutes cherished beliefs of the functional-programming community, it may be better to submit it as a full paper, which will be judged by the usual criteria of novelty, originality, and relevance. The Program Chair will be happy to advise on any concerns about which category to submit to. ### ICFP Organisers General Chair: Nikhil Swamy (Microsoft Research, USA) Programme Chair: Sam Lindley (The University of Edinburgh, Scotland) Publicity Chair: Ilya Sergey (National University of Singapore, Singapore) Accessibility Co-Chairs: Vadim Zaliva (University of Cambridge, UK) and Calvin Beck (University of Pennsylvania, USA) Artifact Evaluation Chair: Jannis Limpberg (Vrije Universiteit Amsterdam, Netherlands) Diversity Chair: Daan Leijen (Microsoft Research, USA) Industrial Relations Co-Chairs: Atze Dijkstra (Standard Chartered Bank, England) and Mathieu Bosepflug (Tweag I/O, France) Programming Contest Co-Organisers: Alperen Keles (University of Maryland, USA) and Aymeric Fromherz (Inria, France) Student Research Competition Chair: Daniel Hillerström (The University of Edinburgh, Scotland) Video Chair: Apoorv Ingle (Iowa, USA) Workshops Co-Chairs: Arther Azevedo de Amorim (Boston University, USA) and Yannick Forster (Inria, France) ### PACMPL Volume 7, Issue ICFP 2023 Associate Editor: Sam Lindley (The University of Edinburgh, Scotland) Review Committee: Aggelos Biboudis, Oracle, Switzerland Alan Jeffrey, Roblox, USA Amos Robinson, Unaffiliated, Australia Andreea Costea, National University of Singapore, Singapore Andrew Hirsch, University of Buffalo, USA Andy Gill, Cerebrus Systems, USA Armando Solar-Lezama, MIT, USA Arnaud Spiwack, Tweag, France Benjamin C. Pierce, University of Pennsylvania, USA Beta Ziliani, FAMAF, UNC and Manas.Tech, Argentina Chung-Kil Hur, Seoul National University, South Korea Delia Kesner, Université de Paris, France Dylan McDermott, Reykjavik University, Iceland Éric Tanter, University of Chile, Chile Gabriel Radanne, Inria, France Gerwin Klein, Proofcraft & UNSW Sydney, Australia Hannah Gommerstadt, Vasser College, USA James Chapman, Input Output, Scotland James McKinna, Heriot-Watt, Scotland Jan Midtgaard, Tarides, Denmark Jeremy Gibbons, University of Oxford, England Jonathan Brachthäuser, University of Tübingen, Germany Jonathan Sterling, Aarhus University, Denmark José Pedro Magalhães, Standard Chartered Bank, England Josh Berdine, Meta UK, England Kathrin Stark, Heriot-Watt, Scotland Laura Bocchi, Kent, England Lennart Augustsson, Epic Games, Sweden Liang-Ting Chen, Academia Sinica, Taiwan, Taiwan Lionel Parreaux, HKUST, Hong Kong Marcos Viera, Universidad de la República, Uruguay Matthew Flatt, University of Utah, USA Michael D. Adams, National University of Singapore, Singapore Michael Greenberg, Stevens Institute of Technology, USA Niki Vazou, IMDEA, Spain Oliver Bračevac, Purdue University, USA Patrik Jansson, CSE, Chalmers and UGOT, Sweden, Sweden Paul Downen, UMass Lowell, USA Peter Thiemann, University of Freiburg, Germany Sam Tobin-Hochstadt, Indiana University, USA Satnam Singh, Groq, USA Sean Moss, Oxford, England Sebastian Erdweg, JGU Mainz, Germany Shin-ya Katsumata, National Institute of Informatics, Japan Simon Gay, University of Glasgow, Scotland Sonia Marin, University of Birmingham, England Stephen Dolan, Jane Street, England Susmit Sarkar, University of St Andrews, Scotland Tahina Ramananandro, Microsoft, USA Takeshi Tsukada, Chiba University, Japan Talia Ringer, University of Illinois at Urbana-Champaign, USA Yukiyoshi Kameyama, University of Tsukuba, Japan Zhenjiang Hu, Peking University, China

1 0

Midlands Graduate School, 2-6 April 2023, Birmingham , UK
by Graham Hutton 14 Feb '23

14 Feb '23

Dear all, Registration is now open for this years Midlands Graduate School, which takes place 2-6 April 2023 at the University of Birmingham, UK: http://www.tinyurl.com/MGS2023 MGS provides an intensive course of lectures on the Mathematical Foundations of Computing. It has been running for approaching 25 years, and attracts around 100 participants per year from both academia and industry. This year's courses: - Domain theory and denotational semantics (Tom de Jong) - Type theory (Thorsten Altenkirch) - Category theory (Nicolai Kraus) - Computational models of higher categories (Jamie Vicary) - Homotopy type theory (Eric Finster) - String diagrams (Dan Marsden) - Algebraic semantics and verification (Georg Struth) - Effects and call-by-push-value (Paul Levy) Spaces are limited, so early registration is recommended. Please share! Best wishes, Graham -- Professor Graham Hutton School of Computer Science University of Nottingham, UK http://www.cs.nott.ac.uk/~pszgmh This message and any attachment are intended solely for the addressee and may contain confidential information. If you have received this message in error, please contact the sender and delete the email and attachment. Any views or opinions expressed by the author of this email do not necessarily reflect the views of the University of Nottingham. Email communications with the University of Nottingham may be monitored where permitted by law.

1 0

Generic use of queries postgresql-simple
by Pietro Grandinetti 12 Feb '23

12 Feb '23

Hello-- I use postgresql-simple and for selecting rows from one table I have the following function. runMyQuery :: Connection -> String -- query with '?' params to bind -> Int -- first param -> Int -- second param -> IO [MyTable1] runMyQuery conn dbQuery param1 param2 = query conn dbQuery $ (param2, param2) data MyTable1 = MyTable1 {col1 :: Int, col2 :: Int, col3 :: String} instance FromRow MyTable1 where fromRow = MyTable1 <$> field <*> field <*> field There are some things I'd like to improve: 1. I will have to write "MyTable1", "MyTable2", ... datatypes, one for each table, but would like to have only one function runMyQuery where the return type is a generic IO [MyModel]. My problem is that I don't know how to write it for tables with different number of columns and different SQL types. 2. The 2nd to the penultimate arguments of runMyQuery are the arguments to bind into the SQL string query. This means that I should write several different version of "runMyQuery" each with a different number of arguments, but would like to have only one. Can you recommend some approaches? Thanks.

2 1

Paillier package maintainership
by Abhiroop Sarkar 12 Feb '23

12 Feb '23

Hello, The package Paillier (https://hackage.haskell.org/package/Paillier<https://hackage.haskell.org/package/Paillier)> ) that provides a basic Paillier partial homomorphic encryption scheme hasn't seen any updates since 2016. The package, as of now, is very simple and cannot handle very common payloads in Machine Learning examples such as real numbers or even negative Integers. If the original maintainer Mr Li-Ting Tsai is no longer actively maintaining the package, I can take over, add support for real numbers (that is a non-trivial task) and add documentation to the package. I am not aware of any contact information for the author. Kindly let me know if there is any way to contact the author to transfer the maintainership. Best wishes, Abhiroop

2 3

[Haskell] [ANNOUNCE] GHC 9.2.6 released
by Zubin Duggal 10 Feb '23

10 Feb '23

The GHC developers are happy to announce the availability of GHC 9.2.6. Binary distributions, source distributions, and documentation are available at [downloads.haskell.org](https://downloads.haskell.org/ghc/9.2.6). Download Page: https://www.haskell.org/ghc/download_ghc_9_2_6.html Blog Post: https://www.haskell.org/ghc/blog/20230210-ghc-9.2.6-released.html This release is primarily a bugfix release addressing a few issues found in 9.2.5. These include: * Fixes for a number of simplifier issues typically resulting in compiler panics (#22491, #22482, #19824, #22718, #22662, #22039). * Fix for a simplifier regression in 9.2.5 that could impact runtime performance when compiling with optimisations due to duplication of expensive work (#22425). * Various stability improvments and bug fixes for the non moving and parallel GCs (#22528, #20221, #22264, #22327, #22929, #22927, #22929, #22930). * Allow certain keywords which can be used as variable names with `-XOverloadedRecordDot` (#20723). * Improvements to typechecker performance for modules with holes in type signatures (#14766) * Bump `gmp-tarballs` to a version which doesn't use the reserved `x18` register on AArch64/Darwin systems, and also has fixes for CVE-2021-43618 (#22497, #22789). * ... and a few more. See the [release notes] for a full accounting. As some of the fixed issues do affect correctness users are encouraged to upgrade promptly. We would like to thank Microsoft Azure, GitHub, IOG, the Zw3rk stake pool, Well-Typed, Tweag I/O, Serokell, Equinix, SimSpace, Haskell Foundation, and other anonymous contributors whose on-going financial and in-kind support has facilitated GHC maintenance and release management over the years. Finally, this release would not have been possible without the hundreds of open-source contributors whose work comprise this release. As always, do give this release a try and open a [ticket][] if you see anything amiss. Happy compiling, - Zubin [ticket]: https://gitlab.haskell.org/ghc/ghc/-/issues/new [release notes]: https://downloads.haskell.org/~ghc/9.2.6/docs/html/users_guide/9.2.6-notes.…

1 0

HKD and Generic
by PICCA Frederic-Emmanuel 09 Feb '23

09 Feb '23

Hello, I have this class DataSource data family DataSourcePath a :: Type data family DataSourceAcq a :: Type class DataSource a where withDataSourceP :: (Location l, MonadSafe m) => l -> DataSourcePath a -> (DataSourceAcq a -> m r) -> m r The purpose is to acquire a ressources from a data source path (for example, in a hdf5 file, "hdf5://path/to/my/dataset" I need to obtain a C struct which point on the Dataset) and then do something with this ressources Here an example of an instance in order to extract an Angstrom from a file or provide directly the constant value. -- Angstrom data instance DataSourcePath Angstrom = DataSourcePath'Angstrom (Hdf5Path Z Double) | DataSourcePath'Angstrom'Const Angstrom deriving (Eq, Generic, Show, FromJSON, ToJSON) data instance DataSourceAcq Angstrom = DataSourceAcq'Angstrom Dataset | DataSourceAcq'Angstrom'Const Angstrom instance DataSource Angstrom where withDataSourceP f (DataSourcePath'Angstrom p) g = withHdf5PathP f p $ \ds -> g (DataSourceAcq'Angstrom ds) withDataSourceP _ (DataSourcePath'Angstrom'Const a) g = g (DataSourceAcq'Angstrom'Const a) next, I build a bunch of DataFrame which contain all these ressources. data DataFrameQCustom = DataFrameQCustom Attenuation -- attenuation Geometry -- geometry Image -- image Index -- timestamp in double deriving Show data instance DataSourcePath DataFrameQCustom = DataSourcePath'DataFrameQCustom (DataSourcePath Attenuation) (DataSourcePath Geometry) (DataSourcePath Image) (DataSourcePath Index) deriving (Eq, Generic, Show, FromJSON, ToJSON) data instance DataSourceAcq DataFrameQCustom = DataSourceAcq'DataFrameQCustom (DataSourceAcq Attenuation) (DataSourceAcq Geometry) (DataSourceAcq Image) (DataSourceAcq Index) Indded I now need to write the withDataSource instance by hand instance DataSource DataFrameQCustom where withDataSourceP f (DataSourcePath'DataFrameQCustom a g i idx) gg = withDataSourceP f a $ \a' -> withDataSourceP f g $ \g' -> withDataSourceP f i $ \i' -> withDataSourceP f idx $ \idx' -> gg (DataSourceAcq'DataFrameQCustom a' g' i' idx') this seems so mechanical that I am wondring if this should not be automatize via Generic. Another point would be to avoiding mistake when writting the DatasourcePath instance and Generate the from an uniq structure using HKD Something like -- "Higher-Kinded Data" type family HKD f a where HKD Identity a = a HKD f a = f a data DataFrameHkl' f = DataFrameHkl (HKD f DataFrameQCustom) (HKD f Sample) deriving (Generic) type DataFrameHkl = DataFrameHkl' Identity type DataFrameHklPath = DataFrameHkl' DataSourcePath so I would like your help in order to write first a Generic version of withDataSourceP I read this https://reasonablypolymorphic.com/blog/higher-kinded-data/ but I am not completly sure how to convert my withDataSourceP :: (Location l, MonadSafe m) => l -> DataSourcePath a -> (DataSourceAcq a -> m r) -> m r signature into something Generic Thanks for considering Fred

1 0

Volunteers wanted to administer a security advisory DB for Hackage
by David Christiansen 09 Feb '23

09 Feb '23

Hello fellow Haskellers, The HF is in the process of getting a security advisory database up and running for Haskell libraries, to enable both automated and manual audit workflows. We're looking for volunteers to help administer the database. If you have a background in security and would like to make a high-impact positive contribution to the Haskell ecosystem, please consider volunteering! More details are available at https://discourse.haskell.org/t/call-for-nominations-haskell-security-respo… . Thanks in advance! All the best, David Thrane Christiansen Executive Director The Haskell Foundation

1 0

Haskell Tiny Game Jam!
by Simon Michael 08 Feb '23

08 Feb '23

The first Haskell Tiny Game Jam is now open! All welcome! Your mission: make Haskell games in 10 lines. https://github.com/haskell-game/tiny-games-hs and the #haskell-game chat room await your entries. Best, -Simon

2 1