November 2022 - Haskell-Cafe

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