- Haskell-Cafe - Haskell.org

[ANN] faster-megaparsec
by Olaf Klinke 15 Nov '22

15 Nov '22

Dear Haskellers, megaparsec [1] is a parsing library with excellent error reporting. Being able to emit decent parse error messages is traded off against speed, however. Wouldn't it be nice to have a faster parser for your daily parsing needs, but obtain megaparsec's informative error messages for the rare cases when things go wrong? Thanks to megaparsec's parser type class, MonadParsec, you can have both: I wrote a MonadParsec instance for StateT s Maybe (s being the input stream type such as Text or ByteString) which does not do all the bookkeeping ParsecT needs to do. If you manage to write your parser only using the type class primitives, then you can specialize your parser to StateT s Maybe. Only if that returns Nothing specialize again to ParsecT Void s and parse the input again, thus obtaining a decent error message. The package faster-megaparsec [1,2] provides a convenient function to do just that. Of course StateT s Maybe can not provide all the features ParsecT has: * StateT s Maybe is always backtracking. * It does not know the offset in the stream. * It must hold the entire input stream in memory for a second pass, so no garbage collecting the consumed input while parsing. So if your parsing relies on non-backtracking choice, stream offset or garbage-collecting input while parsing, you can not use faster- megaparsec as a drop-in replacement. Happy parsing! Olaf [1] https://hackage.haskell.org/package/megaparsec [2] https://hackage.haskell.org/package/faster-megaparsec [3] https://hub.darcs.net/olf/faster-megaparsec

3 3

[TFP 2023 2nd Call for Papers] 24th International Symposium on Trends in Functional Programming
by Peter Achten 15 Nov '22

15 Nov '22

# TFP 2023 -- Call for Papers (trendsfp.github.io) ## Important Dates Submission deadline: pre-symposium, full papers, Wednesday 23rd November, 2022 Submission deadline: pre-symposium, draft papers, Friday 16th December, 2022 Notification: pre-symposium submissions, Friday 23rd December, 2022 Registration: Friday 6th January, 2023 TFPIE Workshop: Thursday 12th January, 2023 TFP Symposium: Friday 13th - Sunday 15th January, 2023 Submission deadline: post-symposium review, Friday 17th February, 2023 Notification: post-symposium submissions, Friday 31st March, 2023 The Symposium on Trends in Functional Programming (TFP) is an international forum for researchers with interests in all aspects of functional programming, taking a broad view of current and future trends in the area. It aspires to be a lively environment for presenting the latest research results, and other contributions. This year, TFP will take place in-person at UMass Boston, Massachusetts in the United States. It is co-located with the Trends in Functional Programming in Education (TFPIE) workshop, which will take on the day before the main symposium. Please be aware that TFP has several submission deadlines. The first, November 23, is for authors that wish to have their full paper reviewed prior to the symposium. Papers that are accepted in this way must also be presented at the symposium. The second, December 16, is for authors that wish to present their work or work-in progress at the symposium first without submitting to the full review process for publication. These authors can then take into account feedback received at the symposium and submit a full article for review by the third deadline, February 17. ## Scope The symposium recognizes that new trends may arise through various routes. As part of the Symposium's focus on trends we therefore identify the following five article categories. High-quality articles are solicited in any of these categories: * Research Articles: Leading-edge, previously unpublished research work * Position Articles: On what new trends should or should not be * Project Articles: Descriptions of recently started new projects * Evaluation Articles: What lessons can be drawn from a finished project * Overview Articles: Summarizing work with respect to a trendy subject Articles must be original and not simultaneously submitted for publication to any other forum. They may consider any aspect of functional programming: theoretical, implementation-oriented, or experience-oriented. Applications of functional programming techniques to other languages are also within the scope of the symposium. Topics suitable for the symposium include, but are not limited to: * Functional programming and multicore/manycore computing * Functional programming in the cloud * High performance functional computing * Extra-functional (behavioural) properties of functional programs * Dependently typed functional programming * Validation and verification of functional programs * Debugging and profiling for functional languages * Functional programming in different application areas: security, mobility, telecommunications applications, embedded systems, global computing, grids, etc. * Interoperability with imperative programming languages * Novel memory management techniques * Program analysis and transformation techniques * Empirical performance studies * Abstract/virtual machines and compilers for functional languages * (Embedded) domain specific languages * New implementation strategies * Any new emerging trend in the functional programming area If you are in doubt on whether your article is within the scope of TFP, please contact the TFP 2023 program chair, Stephen Chang. ## Best Paper Awards TFP awards two prizes for the best papers each year. First, to reward excellent contributions, TFP awards a prize for the best overall paper accepted for the post-conference formal proceedings. Second, a prize for the best student paper is awarded each year. TFP traditionally pays special attention to research students, acknowledging that students are almost by definition part of new subject trends. A student paper is one for which the authors state that the paper is mainly the work of students, the students are listed as first authors, and a student would present the paper. In both cases, it is the PC of TFP that awards the prize. In case the best paper happens to be a student paper, then that paper will receive both prizes. ## Instructions to Authors Papers must be submitted at: <https://easychair.org/conferences/?conf=tfp23> Authors of papers have the choice of having their contributions formally reviewed either before or after the Symposium. Further, pre-symposium submissions may either be full (earlier deadline) or draft papers (later deadline). ## Pre-symposium formal review Papers to be formally reviewed before the symposium should be submitted before the early deadline and will receive their reviews and notification of acceptance for both presentation and publication before the symposium. A paper that has been rejected for publication but accepted for presentation may be resubmitted for the post-symposium formal review. ## Post-symposium formal review Draft papers will receive minimal reviews and notification of acceptance for presentation at the symposium. Authors of draft papers will be invited to submit revised papers based on the feedback receive at the symposium. A post-symposium refereeing process will then select a subset of these articles for formal publication. ## Paper categories Draft papers and papers submitted for formal review are submitted as extended abstracts (4 to 10 pages in length) or full papers (20 pages). The submission must clearly indicate which category it belongs to: research, position, project, evaluation, or overview paper. It should also indicate which authors are research students, and whether the main author(s) are students. A draft paper for which all authors are students will receive additional feedback by one of the PC members shortly after the symposium has taken place. ## Format Papers must be written in English, and written using the LNCS style. For more information about formatting please consult the Springer LNCS web site. ## Program Committee Peter Achten, Radboud University Nijmegen, Netherlands Nada Amin, Harvard University, USA Ambrose Bonnaire-Sergeant, Untypable LLC, USA Laura M. Castro, University of A Coruña, Spain Stephen Chang (Chair), University of Massachusetts Boston, US John Clements, Cal Poly, USA Youyou Cong, Tokyo Institute of Technology, Japan Paul Downen, University of Massachusetts Lowell, USA Kathy Gray, Meta Platforms, Inc., UK Ben Greenman, University of Utah, USA Jason Hemann, Seton Hall University, USA Patricia Johann, Appalachian State University, USA Alexis King, Tweag, USA Julia Lawall, Inria-Paris, France Barak Pearlmutter, Maynooth University, Ireland Norman Ramsey, Tufts University, USA Ilya Sergey, National University of Singapore, Singapore Melinda Tóth, Eötvös Loránd University, Hungary Ningning Xie, University of Toronto, Canada

1 0

[ANN] Copilot 3.12
by Ivan Perez 14 Nov '22

14 Nov '22

Dear all, I'm very excited to announce Copilot 3.12. Copilot is a stream-based DSL 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. Among others, Copilot has been used at the Safety Critical Avionics Systems Branch of NASA Langley Research Center for monitoring test flights of drones. It also serves as a runtime monitoring backend for the requirements elicitation tool FRET (https://github.com/NASA-SW-VnV/fret/) via Ogma ( https://github.com/nasa/ogma) The main changes in this release are as follows: - A new library copilot-prettyprinter exposes functions related to the Copilot Core pretty-printing backend. Pre-existing functions included as part of copilot-core are now deprecated. - The C99 backend now produces an additional header file with struct declarations. This file is used by the C implementation file generated by Copilot to define structs before the declarations of the handlers, avoiding potential forward declarations that the C compiler cannot resolve. Users of Copilot can choose to import the same new type declaration header file before the standard Copilot header file in their hand-written code, or use external definitions that declare compatible structs. Note that, in the former case, the header file that declares the structs must be included before the header file that declares the externs, handlers and step function. - The custom type equality module in copilot-core is now deprecated in favour of the definition of type equality in base. - copilot-theorem now includes support for proofs by bisimulation necessary for future extensions to Copilot. - copilot-core now complies with the coding rules established as part of the process of compliance with higher NASA's requirements for software with higher assurance classifications. Current emphasis is on improving the codebase in terms of stability and test coverage, removing unnecessary dependencies, hiding internal definitions, and formatting the code to meet our new coding standards. Users are encouraged to participate by opening issues and asking questions via our github repo (https://github.com/copilot-language/copilot) I'd also like to take this opportunity to announce that Copilot is now available on Debian. As a consequence of this effort, Copilot will also be available to Ubuntu users in the near future. We would like to publicly thank the Debian Haskell Group and, most especially, Scott Talbert, for continued effort making Copilot available on Debian-based distros. This will be extremely useful to a great portion of our users, who need to use Copilot as a runtime verification system targeting C, but do not need to become proficient in Haskell. We hope to continue this effort by making Copilot easily available on other distributions and OSs. Happy Haskelling, The Copilot team

1 0

Sam Staton giving this year's LMS/BCS-FACS Evening Seminar (online) -- registration open until this Wednesday at 5PM, UTC
by Andrei Popescu 14 Nov '22

14 Nov '22

EVENT: Annual LMS/BCS-FACS Evening Seminar SPEAKER: Sam Staton, University of Oxford TITLE: Programming-based foundations for statistics DATE: Thursday, 17 November 2022, Starting time: 18:00 UTC VENUE: Online via Zoom EVENT PAGE: https://www.lms.ac.uk/events/lectures/lms-bcs-facs-evening-seminars REGISTRATION LINK: https://www.lms.ac.uk/civicrm/event/register?id=88&reset=1 Prior registration is required for attendance -- the registration site will close on Wednesday, 16 November, at 17:00 SYNOPSIS Probabilistic programming is a popular tool for statistics and machine learning. The idea is to describe a statistical model as a program with random choices. The program might be a simulation of a system, such as a physics model, a model of viral spread, or a model of electoral behaviour. We can now carry out statistical inference over the system, for example, by running a Monte Carlo simulation – running the simulation 100,000’s of times. As I will discuss in this talk, the idea of treating statistical models as computer programs also has a foundational appeal. If we can understand statistical models as programs, then the foundations of probability and statistics can be discussed in terms of program semantics. There is a chance of new foundational perspectives on statistics, in terms of programming languages and their formal methods. As I will explain, this programming-based foundation for statistics is attractive because there are some intuitively simple scenarios, such as inference over function spaces, which have an easy programming implementation, but for which the traditional mathematical interpretation is complicated. SPEAKER BIOGRAPHY Sam Staton is a Professor of Computer Science and Royal Society University Research Fellow at the University of Oxford. There he currently runs an ERC grant "Better Languages for Statistics". Before arriving in Oxford in 2015, Sam spent time in Nijmegen, Paris, and Cambridge. His PhD was in Cambridge with Marcelo Fiore (2007). Sam's main research is in programming language theory, but he is also interested in logic and category theory. He has recent contributions in probabilistic programming languages, and quantum computing and programming languages. Webpage: https://www.cs.ox.ac.uk/people/samuel.staton/main.html

1 0

[ANN] updated vim's cabal syntax file
by coot＠coot.me 13 Nov '22

13 Nov '22

vim-9.0.0849 comes with an updated cabal syntax file which supports a few more fields. If you want to see the changes, check out the few recent commits: https://github.com/coot/haskell-vim-scripts/commits/master/syntax/cabal.vim… Cheers, Marcin

1 0

Numerical Recipes in Haskell?
by Jonathan Drews 12 Nov '22

12 Nov '22

Hi: New member here. I am looking for a book similar to "Numerical Recioes in C" but for Haskell. https://www.amazon.com/Numerical-Recipes-Scientific-Computing-Second/dp/052… Does such a book exist? I've looked and can't seem to find one. I am new to Haskell and don't have much programming experience. I am using the No Starch press book "Learn Physics with Functional Programming: A Hands-on Guide to Exploring Physics with Haskell". It's very well written. -- Kind regards, Jonathan

1 0

[CFP] FOSDEM Haskell Devroom, Sun 2023-02-05, Brussels
by Fraser Tweedale 12 Nov '22

12 Nov '22

I am thrilled to announce that Europe's largest free software conference, FOSDEM, will in 2023 and for the first time feature a Haskell devroom (specialist track). The Call for Participation is open now, until 2022-11-28. Read on for more info! FOSDEM 2023 will be held on 4 & 5 February 2023, in Brussels. For more information see the official site: https://fosdem.org/2023/. The Haskell devroom will take place on Sunday 5 February, from 13:10 to 17:00 UTC+1. Presentations will be also be streamed live and published afterwards. ## Key Dates 2022-11-28: Submission Deadline 2022-12-12: Announcement of selected talks 2023-02-04..2023-02-05: FOSDEM conference 2023-02-05: Haskell Devroom ## About the Haskell devroom Haskell is a statically typed functional programming language. Its vibrant community spans industry, academia and the hobbyist realm. The Haskell devroom welcomes people new to Haskell or functional programming, as well as intermediate or experienced Haskellers. The Haskell devroom will: - Advocate the Haskell programming language, and its community, to a wide audience of free software developers and users. - Promote and support participation in free software projects that use Haskell. - Teach Haskell (more broadly, functional) programming techniques, and introduce important libraries, frameworks or developer tools. ## Call for Participation We invite proposals for talks, tutorials and demos on topics including: - Introductory talks teaching functional programming concepts and Haskell programming - Practical advice for Haskell programming: developer tools, package ecosystem, Haskell in production. - "Show and tell" session for people to introduce Haskell projects they are involved with, and invite contributions. - Experience reports: share about problems you tackled using Haskell, and the outcomes. - What is going on in the Haskell community? Where and how you can get involved? Sessions will have a maximum duration of 30 minutes, including questions. You are welcome to propose shorter sessions (for example a demo, short talk or Q&A). This is an in-person event. Presenters must be able to attend to deliver their presentation. ## Code of conduct Speakers and attendees must abide by the FOSDEM Code of Conduct[1]. Also, because this is a Haskell community event we expect participants to follow the Haskell Foundation Guidelines for Respectful Communication[2]. [1] https://fosdem.org/2023/practical/conduct/ [2] https://haskell.foundation/guidelines-for-respectful-communication/ If you submit a proposal and it is accepted, you will be required to confirm that you accept the FOSDEM Code of Conduct. If you have any questions about the Code of Conduct or wish to have one of the devroom organizers review your presentation slides or any other content for compliance, please email us and we will do our best to assist you. ## How to submit Submit proposals through the FOSDEM Pentabarf submission tool[3]. If you do not already have an account, you need to create one. [3] https://penta.fosdem.org/submission/FOSDEM23 Go to "Create Event" and select the "Haskell devroom" track. Ensure you fill the following fields: - Event title - Track ("Haskell devroom") - Duration (including questions; <= 30 minutes) - Event type - Short abstract - Full abstract - Submission notes (if any) You can use the Submission notes to mention: - Any special requirements - Anything else you want the organisers/reviewers to know In the "Person" profile section please provide your: - Name, nickname (optional), image - Short Biography - Email address - Phone number (in case we need to contact you during the conference) Presentations will be live-streamed and recordings published under the CC-BY licence. By submitting you consent to having your presentation recorded and broadcast/published under the CC-BY licence. ## People and contacts The Haskell devroom organisers are: - Fraser Tweedale - Troels Henriksen Thanks to David Christiansen and the Haskell Foundation for supporting this event. If you need to reach the Haskell devroom organisers or program committee, email <haskell-devroom-manager(a)fosdem.org>.

1 0

Re: [Haskell-cafe] [ANN] faster-megaparsec
by Olaf Klinke 11 Nov '22

11 Nov '22

Emily wrote: > Do you provide reproducible benchmarks for these claims? I'd love to > see the outcome for various types of projects to make the choice for > myself. > > Unsubstantiated claims of "This is Faster™️" are the path to shame > and treachery. Version 0.1.2 now includes a CSV Benchmark. The benchmark generates random table layouts of up to 50 columns and decodes two named columns in 100000 lines. Speed-up on my machine is roughly 0.7x over ParsecT and 0.6x over Cassava when decoding only few columns of a broad table. In particular, a Text-based ParsecT is faster than (ByteString-based) Cassava in this scenario. This was also the initial reason why I got interested in improving performance of megaparsec parsers in the first place. Cheers, Olaf

1 0

Re: [Haskell-cafe] [ANN] faster-megaparsec
by Olaf Klinke 11 Nov '22

11 Nov '22

> Do you provide reproducible benchmarks for these claims? I'd love to > see the outcome for various types of projects to make the choice for > myself. > > Unsubstantiated claims of "This is Faster™️" are the path to shame > and treachery. > Dear Emily, version 0.1.1 [1] now contains a benchmark suite, where words of randomly generated languages are parsed with both parsers (ParsecT and StateT Text Maybe). For tiny to moderately sized languages, the speed- up is not huge but noticeable. (I need to work on improving test case generation.) I've been using this trick for a long time but only now decided to spin off a dedicated package. My experience with parsing large amounts of tabular data files shows there is a more substantial difference, although that might be due to my lack of understanding how to write optimized megaparsec parsers. Still your point is valid that this is merely anecdotal evidence. If time permits, I shall add a more realistic benchmark with randomly generated CSV data or Finn Bender's haskell-parsing-benchmarks [2]. Cheers, Olaf [1] https://hackage.haskell.org/package/faster-megaparsec-0.1.1.0 [2] https://gitlab.com/FinnBender/haskell-parsing-benchmarks > On Tue, Nov 08, 2022 at 1:31 PM, Olaf Klinke < olf at aatal- > apotheke.de > wrote: > > > > > > > > > Dear Haskellers, > > > > > > > > megaparsec [1] is a parsing library with excellent error reporting. > Being > > able to emit decent parse error messages is traded off against > speed, > > however. Wouldn't it be nice to have a faster parser for your daily > > parsing needs, but obtain megaparsec's informative error messages > for the > > rare cases when things go wrong? > > > > > > > > Thanks to megaparsec's parser type class, MonadParsec, you can have > both: > > I wrote a MonadParsec instance for StateT s Maybe (s being the > input > > stream type such as Text or ByteString) which does not do all the > > bookkeeping ParsecT needs to do. If you manage to write your parser > only > > using the type class primitives, then you can specialize your > parser to > > StateT s Maybe. Only if that returns Nothing specialize again to > ParsecT > > Void s and parse the input again, thus obtaining a decent error > message. > > The package faster-megaparsec [1,2] provides a convenient function > to do > > just that. > > > > > > > > Of course StateT s Maybe can not provide all the features ParsecT > has: > > * StateT s Maybe is always backtracking. > > * It does not know the offset in the stream. > > * It must hold the entire input stream in memory for a second pass, > so no > > garbage collecting the consumed input while parsing. So if your > parsing > > relies on non-backtracking choice, stream offset or garbage- > collecting > > input while parsing, you can not use faster- megaparsec as a drop- > in > > replacement. > > > > > > > > Happy parsing! > > Olaf > > > > > > > > [1] https:/ / hackage. haskell. org/ package/ megaparsec ( > > https://hackage.haskell.org/package/megaparsec ) > > [2] https:/ / hackage. haskell. org/ package/ faster-megaparsec ( > > https://hackage.haskell.org/package/faster-megaparsec ) > > [3] https://hub.darcs.net/olf/faster-megaparsec >

1 0

[ANNOUNCE] GHC 9.4.3 is now available
by Ben Gamari 09 Nov '22

09 Nov '22

The GHC developers are happy to announce the availability of GHC 9.4.3. Binary distributions, source distributions, and documentation are available at downloads.haskell.org: https://downloads.haskell.org/ghc/9.4.3 This release is primarily a bugfix release addressing a few issues found in 9.4.2. These include: * An issue where recursively calls could be speculatively evaluated, resulting in non-termination (#20836) * A code generation issue in the AArch64 native code generator backend resulting in incorrect runtime results in some circumstances (#22282) * A crash on Darwin when running executables compiled with IPE support (#22080) * A long-standing interface-file determinism issue where full paths would leak into the interface file (#22162) * A bug in the `process` library where file handles specified as `NoStream` would still be usable in the child (process#251) Note that, as GHC 9.4 is the first release series where the release artifacts are all generated by our new Hadrian build system, it is possible that there will be packaging issues. If you enounter trouble while using a binary distribution, please open a [ticket]. Likewise, if you are a downstream packager, do consider migrating to [Hadrian] to run your build; the Hadrian build system can be built using `cabal-install`, `stack`, or the in-tree [bootstrap script]. See the accompanying [blog post] for details on migrating packaging to Hadrian. We would also like to emphasize that GHC 9.4 must be used in conjunction with Cabal-3.8 or later. This is particularly important for Windows users due to changes in GHC's Windows toolchain. 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 Haskelling, - Ben [ticket]: https://gitlab.haskell.org/ghc/ghc/-/issues/new [bootstrap script]: https://gitlab.haskell.org/ghc/ghc/-/blob/e2520df3fffa0cf22fb19c5fb872832d1… [Hadrian]: https://gitlab.haskell.org/ghc/ghc/-/blob/e2520df3fffa0cf22fb19c5fb872832d1… [blog post]: https://www.haskell.org/ghc/blog/20220805-make-to-hadrian.html

2 1