- Haskell-Cafe - Haskell.org

Taking over maintainership of `fec`
by Jean-Paul Calderone 02 Oct '23

02 Oct '23

Hello all, I would like to take over maintainership of the `fec` package ( https://hackage.haskell.org/package/fec) fec is a wrapper around a C library for a certain forward erasure code scheme. Neither the C library nor the Haskell bindings have changed much since the package was last published on Hackage but recently I've fixed a multithreading bug that leads to corrupt results and an integer overflow bug that leads to memory corruption and typically a segfault. I would love to make these improvements available via Hackage. I don't think `fec` has much of a user base but I've recently published several cryptographic libraries on Hackage which depend on it and suffer from the two issues mentioned above. I'm also an upstream maintainer of the project (https://github.com/tahoe-lafs/zfec) I have emailed the current maintainer and original author of the Haskell bindings, Adam Langley (cced), about becoming a maintainer but I haven't yet heard back. Thanks, Jean-Paul

2 5

Using deriving with indexed data types
by Tom Ellis 30 Sep '23

30 Sep '23

How are Haskell folks using indexed types (indexed by types of DataKinds) whilst still being able to take advantage of GHC's deriving? I wrote up my approach into a small library: https://github.com/tomjaguarpaw/ad/blob/589926448865700fa616e8c6f6e4a011384… Here's an example of using my approach: https://github.com/tomjaguarpaw/ad/blob/master/indexed-types/src/IndexedTyp… and it shows you can still use deriving for all your instances: https://github.com/tomjaguarpaw/ad/blob/master/indexed-types/src/IndexedTyp… I'd be interested to know what other approaches people are using in practice. Thanks, Tom

1 1

[ANNOUNCE] GHC 9.8.1-rc1 is now available
by Ben Gamari 29 Sep '23

29 Sep '23

The GHC developers are very pleased to announce the availability of the release candidate of GHC 9.8.1. Binary distributions, source distributions, and documentation are available at https://downloads.haskell.org/ghc/9.8.1-rc1 GHC 9.8 will bring a number of new features and improvements, including: * Preliminary support the `TypeAbstractions` language extension, allowing types to be bound in type declarations [TypeAbstractions]. * Support for the `ExtendedLiterals` extension, providing syntax for non-word-sized numeric literals in the surface language [extended-literals] * Improved rewrite rule matching behavior, allowing limited matching of higher-order patterns * Better support for user-defined warnings by way of the `WARNING` pragma [warnings] * The introduction of the new `GHC.TypeError.Unsatisfiable` constraint, allowing more predictable user-defined type errors [unsatisfiable] * Implementation of the export deprecation proposal, allowing module exports to be marked with `DEPRECATE` pragmas [deprecated-exports] * The addition of build semaphore support for parallel compilation; with coming support in `cabal-install` this will allow better use of parallelism in multi-package builds [jsem] * More efficient representation of info table provenance information, reducing binary sizes by over 50% in some cases when `-finfo-table-map` is in use A full accounting of changes can be found in the [release notes]. This candidate includes roughly 20 new commits relative to alpha 4, including what we believe should be nearly the last changes to GHC's boot libraries. As always, GHC's release status can be found on the GHC Wiki [status]. We would like to thank GitHub, IOG, the Zw3rk stake pool, Well-Typed, Tweag I/O, Serokell, Equinix, SimSpace, the Haskell Foundation, and other anonymous contributors whose on-going financial and in-kind support has facilitated GHC maintenance and release management over the years. Finally, this release would not have been possible without the hundreds of open-source contributors whose work comprise this release. As always, do give this release a try and open a [ticket] if you see anything amiss. Happy compiling, ~ Ben [TypeAbstractions]: https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0425-d… [extended-literals]: https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0451-s… [unsatisfiable]: https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0433-u… [warnings]: https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0541-w… [deprecated-exports]: https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0134-d… [jsem]: https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0540-j… [release notes]: https://downloads.haskell.org/ghc/9.8.1-alpha4/docs/users_guide/9.8.1-notes… [status]: https://gitlab.haskell.org/ghc/ghc/-/wikis/GHC-status

1 0

[Haskell] [ANNOUNCE] Haskell Language Server 2.3.0.0 released
by Zubin Duggal 29 Sep '23

29 Sep '23

Binaries for this release are available at https://downloads.haskell.org/~hls/haskell-language-server-2.3.0.0/. These binaries can be installed using [GHCup](https://www.haskell.org/ghcup/) or the Haskell VSCode extension. All of these tarballs have associated GPG signatures. The signature should be from `Zubin Duggal <zubin(a)well-typed.com>` (key ID [588764FBE22D19C4](https://keys.openpgp.org/search?q=588764FBE22D19C4)) The prebuilt binaries in this release support the following GHC versions: - 9.0.2 - 9.2.8 - 9.4.6 - 9.6.2 - 9.6.3 ## Changelog * Binaries for GHC 9.6.3 * Drop support for GHC 8.10 * Remove `hls-haddock-comments-plugin`, `hls-stan-plugin`, and `hls-tactics-plugin` * Don't suggest bogus modules names in `hls-module-name-plugin` (#3784) * Add support for external Ormolu (#3771) * Improve refine imports behaviour for qualified imports (#3806) Happy editing! - Zubin

1 0

How can I get in touch with Stan maintainers?
by Tom Ellis 28 Sep '23

28 Sep '23

Hello, Does anyone know how I can get in touch with the Stan maintainers? Stan is a static analysis tool for Haskell. Its maintainers seem to have stopped supporting it after the GHC 8.x series because the GHC API changed too frequently for them to want to keep making adjustments. Last year I did quite a lot of work to bring Stan and its dependencies up to 9.4. I made a PR to the Stan Github repo last month: https://github.com/kowainik/stan/pull/506 I haven't heard anything from the maintainers. The only maintainer I know of is Veronika Romashkina. I've sent her a private email about this but had no response. Does anyone know how I can get in contact with Veronika or another Stan maintainer, if there is one? I would be willing to be a comaintainer for Stan and the rest of the Kowainik ecosystem (if only to make sure they continue to work with future GHCs). Thanks, Tom

1 0

[ANNOUNCE] GHC 9.6.3 is now available
by Bryan Richter 25 Sep '23

25 Sep '23

The GHC developers are happy to announce the availability of GHC 9.6.3. Binary distributions, source distributions, and documentation are available on the release page. https://www.haskell.org/ghc/download_ghc_9_6_3.html This release is primarily a bugfix release addressing a few issues found in the 9.6 series. These include: * Disable Polymorphic Specialisation (a performance optimisation) by default. It was discovered that Polymorphic Specialisation as currently implemented in GHC can lead to hard to diagnose bugs resulting in incorrect runtime results. Users wishing to use this optimisation despite the caveats will now have to explicitly enable the new `-fpolymorphic-specialisation` flag. For more details see #23469 as well as #23109, #21229, #23445. * Improve compile time and code generation performance when `-finfo-table-map` is enabled (#23103). * Make the recompilation check more robust when code generation flags are changed (#23369). * Addition of memory barriers that improve soundness on platforms with weak memory ordering. * And dozens of other fixes. A full accounting of changes can be found in the [release notes]. 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 [GHC ticket] if you see anything amiss. Enjoy! -Bryan [release notes]: https://downloads.haskell.org/~ghc/9.6.3/docs/users_guide/9.6.3-notes.html [GHC ticket]: https://gitlab.haskell.org/ghc/ghc/-/issues/new

1 0

[ANNOUNCE] GHC 9.8.1-alpha4 is now available
by Ben Gamari 23 Sep '23

23 Sep '23

The GHC developers are very pleased to announce the availability of the third alpha prerelease of GHC 9.8.1. Binary distributions, source distributions, and documentation are available at https://downloads.haskell.org/ghc/9.8.1-alpha4 GHC 9.8 will bring a number of new features and improvements, including: * Preliminary support the `TypeAbstractions` language extension, allowing types to be bound in type declarations [TypeAbstractions]. * Support for the `ExtendedLiterals` extension, providing syntax for non-word-sized numeric literals in the surface language [extended-literals] * Improved rewrite rule matching behavior, allowing limited matching of higher-order patterns * Better support for user-defined warnings by way of the `WARNING` pragma [warnings] * The introduction of the new `GHC.TypeError.Unsatisfiable` constraint, allowing more predictable user-defined type errors [unsatisfiable] * Implementation of the export deprecation proposal, allowing module exports to be marked with `DEPRECATE` pragmas [deprecated-exports] * The addition of build semaphore support for parallel compilation; with coming support in `cabal-install` this will allow better use of parallelism in multi-package builds [jsem] * More efficient representation of info table provenance information, reducing binary sizes by over 50% in some cases when `-finfo-table-map` is in use A full accounting of changes can be found in the [release notes]. This alpha includes roughly 40 new commits relative to alpha 3, including what we believe should be nearly the last changes to GHC's boot libraries. We would like to thank GitHub, IOG, the Zw3rk stake pool, Well-Typed, Tweag I/O, Serokell, Equinix, SimSpace, the Haskell Foundation, and other anonymous contributors whose on-going financial and in-kind support has facilitated GHC maintenance and release management over the years. Finally, this release would not have been possible without the hundreds of open-source contributors whose work comprise this release. As always, do give this release a try and open a [ticket] if you see anything amiss. Happy compiling, ~ Ben [TypeAbstractions]: https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0425-d… [extended-literals]: https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0451-s… [unsatisfiable]: https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0433-u… [warnings]: https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0541-w… [deprecated-exports]: https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0134-d… [jsem]: https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0540-j… [release notes]: https://downloads.haskell.org/ghc/9.8.1-alpha4/docs/users_guide/9.8.1-notes…

3 4

Munich Haskell Meeting, 2023-09-25 @ 19:30
by Leah Neukirchen 22 Sep '23

22 Sep '23

Dear all, Next week, our monthly Munich Haskell Meeting will take place again on Monday, September 26 at Augustiner-Gaststätte Rumpler 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 nuudel anonymously or pseudonymously. https://nuudel.digitalcourage.de/72lt3XWvVmWUt3Gl Everybody is welcome! cu, -- Leah Neukirchen <leah(a)vuxu.org> https://leahneukirchen.org/

1 0

Re: [Haskell-cafe] Limitations of generalization of type constructors
by Ryan Scott 18 Sep '23

18 Sep '23

Short answer: This is expected behavior, and it's unlikely that behavior will change any time soon. Long answer: The key phrase in your original post is "the quantifier moved". That is, in this definition: > fc3 :: Int > fc3 = f (const 0) GHC will turn it into something like this behind the scenes when compiling it to Core: > fc3 :: Int > fc3 = f (\ (@z). const @Int @(Maybe z) 0 :: forall (z :: Type). Maybe z -> Int) Note the presence of `\ (@z)`, which binds a type variable with a lambda. This process of moving quantifiers by using type variables in lambdas is called *regeneralization*. A somewhat surprising fact is that GHC can only perform regeneralization some of the time. GHC can regeneralize type-level `forall`s—that is, `forall`s in the types of terms, as is the case in the example above—but it cannot regeneralize *kind*-level `forall`s. In your post, the `forall`s in the kinds of C2 and Const are kind-level `forall`s. This restriction is documented here [1] in the GHC User's Guide. I've also written a slightly longer blog post [2] about the topic. The reason why this restriction exists is because there is no type-level counterpart to `\ (@z)` in Core, which would be required for regeneralization at the kind level. Adding type-level lambdas to Core would likely be a non-trivial effort. The UnsaturatedTypeFamilies proposal [3], which proposes to relax some restrictions about when types can appear partially applied, is the closest thing that I can think of, but it stops short of proposing full type-level lambdas. Best, Ryan ----- [1] https://downloads.haskell.org/ghc/9.6.2/docs/users_guide/exts/poly_kinds.ht… [2] https://ryanglscott.github.io/2019/07/10/the-surprising-rigidness-of-higher… [3] https://github.com/ghc-proposals/ghc-proposals/blob/7e380dcc4494de30f95bd15…

2 1

Re: [Haskell-cafe] Why can't I promote data family constructors, and what to do instead?
by Ryan Scott 18 Sep '23

18 Sep '23

Regarding the first question ("Is this restriction *really* necessary?"), I think the answer is likely "no", at least for most data family instances. This discussion [1] is the most up-to-date reference on the history and motivations behind the current restriction. In that discussion, it is hypothesized that data family instances whose data constructors do not use any constraints could be promoted without needing to rethink how Core works. (If I understand correctly, all of your data family instances fall into this simple subset.) This discussion could provide a template for a GHC proposal that proposes to allow this feature. Best, Ryan ----- [1] https://github.com/ghc-proposals/ghc-proposals/discussions/456

2 1