- Haskell-Cafe - Haskell.org

[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 08 Nov '22

08 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

CIS 194 not compiling under new GHC
by Borys Kopeć 07 Nov '22

07 Nov '22

Hi all, I've been working through the CIS 194 <https://www.cis.upenn.edu/~cis1940/spring13/lectures.html> course recently and unfortunately from lecture 7 onwards the code is not compliant with current compiler. I can still follow the lectures but I'd like to do every homework exercise. Unfortunately most homework exercises provide you with a code framework to work with and this code does not compile. Do any of you know about updated versions or corrections to this course? I believe there could be a repo where someone is keeping the course's homework up to date because this course is still quite popular. Regards Borys

5 7

[Haskell] [ANNOUNCE] GHC 9.2.5 released
by Zubin Duggal 07 Nov '22

07 Nov '22

The GHC developers are very happy to at announce the availability of GHC 9.2.5. Binary distributions, source distributions, and documentation are available at [`downloads.haskell.org`](https://downloads.haskell.org/ghc/9.2.5). Download Page: https://www.haskell.org/ghc/download_ghc_9_2_5.html Blog Post: https://www.haskell.org/ghc/blog/20221107-ghc-9.2.5-released.html This release is primarily a bugfix release addressing a few issues found in 9.2.4. These include: * Code generation issues in the AArch64 native code generator backend resulting in incorrect runtime results in some circumstances (#22282, #21964) * Fixes for a number of issues with the simplifier leading to core lint errors and suboptimal performance (#21694, #21755, #22114) * A long-standing interface-file determinism issue where full paths would leak into the interface file (#22162) * A runtime system bug where creating empty mutable arrays resulted in a crash (#21962) - ... 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.5/docs/html/users_guide/9.2.5-notes.…

1 0

Help with TH trick
by David Feuer 06 Nov '22

06 Nov '22

I remember seeing a package that offered a function used something like this: $(deriveThingy [d| instance Foo a => Thingy a |]) to allow the user to specify the constraint(s) for a generated instance. I'd love to borrow the code for that, but I can't remember what package it was in, what class it derived, etc. Can anyone help?

3 10

Haskell survey 2022
by Henning Thielemann 03 Nov '22

03 Nov '22

It seems there is a survey on Haskell Weekly but I have not seen an announcement on the mailing lists: https://haskellweekly.news/survey/2022.html

1 0

[ANN] mtl-2.3.1
by Emily Pillmore 31 Oct '22

31 Oct '22

Hello Ghosts and Ghouls, After a period of spooky deliberation and well-received release candidate, Koz and I are pleased to announce `mtl-2.3.1`, which features the following hellish changelog: * Add `modifyError` to `Control.Monad.Error.Class`, and re-export from `Control.Monad.Except`. * Make the `MonadCont` instance for `ContT` more polykinded; now, `r` is allowed to be of an arbitrary kind `k`, rather than only `Type`. * Add a generic `liftCallCC` for use with any `MonadTrans`. * Add `modifyError` to `Control.Monad.Error.Class` * Return re-export of `ExceptT` and related functions to `Control.Monad.Except`. * Add `label` function to `MonadCont` If you wish to migrate to `mtl-2.3.x` and have not yet done so, please refer the migration guide in the repo: https://github.com/haskell/mtl/blob/master/docs/Mtl-2.3.x-Migration.md A release has been published on the github repository under the tag v2.3.1. Happy Halloween! Emily + Koz

1 0

Journal of Functional Programming - Call for PhD Abstracts
by Graham Hutton 31 Oct '22

31 Oct '22

Dear all, If you or one of your students recently completed a PhD (or Habilitation) in the area of functional programming, please submit the dissertation abstract for publication in JFP: simple process, no refereeing, open access, 200+ published to date, deadline 30th November 2022. Please share! Best wishes, Graham Hutton ============================================================ CALL FOR PHD ABSTRACTS Journal of Functional Programming Deadline: 30th November 2022 http://tinyurl.com/jfp-phd-abstracts ============================================================ PREAMBLE: Many students complete PhDs in functional programming each year. As a service to the community, twice per year the Journal of Functional Programming publishes the abstracts from PhD dissertations completed during the previous year. The abstracts are made freely available on the JFP website, i.e. not behind any paywall. They do not require any transfer of copyright, merely a license from the author. A dissertation is eligible for inclusion if parts of it have or could have appeared in JFP, that is, if it is in the general area of functional programming. The abstracts are not reviewed. Please submit dissertation abstracts according to the instructions below. We welcome submissions from both the student and the advisor/supervisor although we encourage them to coordinate. Habilitation dissertations are also eligible for inclusion. ============================================================ SUBMISSION: Please submit the following information to Graham Hutton <graham.hutton(a)nottingham.ac.uk> by 30th November 2022. o Dissertation title: (including any subtitle) o Student: (full name) o Awarding institution: (full name and country) o Date of award: (month and year; depending on the institution, this may be the date of the viva, corrections being approved, graduation ceremony, or otherwise) o Advisor/supervisor: (full names) o Dissertation URL: (please provide a permanently accessible link to the dissertation if you have one, such as to an institutional repository or other public archive; links to personal web pages should be considered a last resort) o Dissertation abstract: (plain text, maximum 350 words; you may use \emph{...} for emphasis, but we prefer no other markup or formatting; if your original abstract exceeds the word limit, please submit an abridged version within the limit) Please do not submit a copy of the dissertation itself, as this is not required. JFP reserves the right to decline to publish abstracts that are not deemed appropriate. ============================================================ PHD ABSTRACT EDITOR: Graham Hutton School of Computer Science University of Nottingham Nottingham NG8 1BB United Kingdom ============================================================ 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