2023-09-18.md

SWG 2023-09-18

Meeting URL: https://meet.jit.si/StableHaskellMeetBiWeekly

Previous meeting notes

Agenda & Notes

• Thank you David all you have done!

New items to discuss

Non-exhaustive datatypes

From Ben (haskell/cabal#9258)

While working with the Cabal maintainers on the GHC 9.8 release we noticed that the Language.Haskell.Extension module poses a rather annoying problem for compatibility. Specifically, any constructors added to the KnownExtension type constitute a breaking change. This means that, to be PVP compliant, any GHC release which introduces new language extensions must be accompanied by a major Cabal version bump.

This is quite unfortunate as it has long been our goal to decouple the release processes of Cabal and GHC. However, it seems likely that there is a solution close-to-hand: non-exhaustive annotations a la Rust. By explicitly forbidding matches without a wildcard alternative we can avoid such additions being breaking.

Within a package (crate in Rust) the non-exhaustiveness pragma has no effect: only in other packages.

Naturally, the design space here isn't entirely obvious. One question that sticks out to me is how a match author knows whether they have missed any constructors when they are forced to add a wildcard match. Regardless, it seems like there is the kernel of a good idea here. I think it would be worth discussing in our next meeting if possible.

Other alternative approaches:

• Define a package ghc-extension-flags that exports the data type; but make cabal not export it. Now changes to the extensions data type will not make a major bump in cabal, only in ghc-extension-flags.
• Make the extensions data type be a newtype wrapper around String.
• Export lots of pattern synonyms instead of exporting the data constructors themselves.

Given three alternatives that do not require a language extension, do we need a language extension?

Short-Term Action Items From Previous

• None

In progress projects

Updates

• Extension lifecycle framework proposal

  • After deprecation/removal of extensions, have a nice error message.
  • This is analogous to the REMOVED pragma for top level declarations.
  • https://gitlab.haskell.org/ghc/ghc/-/wikis/language-pragma-history
  • David is doing a major revision. Three main critiques:
    • Problem doesn't exist
    • Please solve this other problem
    • The house in burning down and this won't really help.
  • Decouple "legacy" from other aspects.
  • Adam Gundry is now contributing to the working group
  • Target audience: semi-informed companies using Haskell and wanting guidance about what extensions are ... not "blessed" but... "stable" maybe?
  • Many extensions are useful and harmless (LambdaCase, MultiWayIf).
  • One answer: GHC2021. Why not just instead make the case for GHC2023?
  • Possible answer: many extensions are harmless, but too numerous/superficial (?) to be in GHC2023.
    • GHC2023: "suitable" for non-experts.
    • "stable" extensions that are not "suitable" but are unlikely to change (e.g. UndecidableInstances)
    • Or "GHC2023 = good; XXX = non-problematic"
    • Can't have too many axes on which to rate each extension, or it'll just fall under its own weight.
  • "Deprecated" extensions should actually be deleted! Difference between "deprecated" and "legacy".
  • Deprecated extensions are not warned about, apparently.

• GHC API discussed previously

  • HF to look at funding for this.
  • Previously holding the token: David

• Bulletin discussed previously

  • Previously holding the token: Chris

• GHC warning policy document as discussed previously

  • Previously holding the token: Chris

• Creating and maintaining a set of hlint rules to promote stability

  • Previously holding the token: Trevis
  • Opened issue asking if we can write rules for typeclasses.

Parked Action Items/Projects due to expected absence of token holder

New for next week

Action items

Discussion items