- Haskell-Cafe - Haskell.org

[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

Limitations of generalization of type constructors
by Tom Ellis 18 Sep '23

18 Sep '23

Hello Cafe, Generalization of types in type constructors behaves strangely compared to the same behaviour at the term level. I was wondering whether this is expected, whether it's a known issue that's due to be resolved, or is a known issue that can't be resolved for some technical reason. This mail is a literate Haskell file. > {-# LANGUAGE DataKinds #-} > {-# LANGUAGE PolyKinds #-} > {-# LANGUAGE RankNTypes #-} > {-# LANGUAGE StandaloneKindSignatures #-} > {-# LANGUAGE TypeFamilies #-} > > {-# OPTIONS_GHC -Wall #-} > {-# OPTIONS_GHC -Wno-unticked-promoted-constructors #-} > > import Prelude hiding (const) > import Data.Kind (Type) `f` takes an argument of polymorphic type > f :: (forall (z :: Type). Maybe z -> Int) -> Int > f k = k (Just True) `c1` is an argument that will fit there. Its type matches exactly. > c1 :: forall (z :: Type). Maybe z -> Int > c1 _ = 0 > > fc1 :: Int > fc1 = f c1 `c2` will fit there but its type doesn't match exactly. `z` will have to be substituted with `Maybe z`, obtaining the type forall (z :: Type). Maybe z -> Int which does fit exactly. > c2 :: forall (z :: Type). z -> Int > c2 _ = 0 > > fc2 :: Int > fc2 = f c2 `const` will fit there, once `z` is substituted with `Maybe z`, the `Int` argument applied and the quantifer moved, obtaining the type forall (z :: Type). Maybe z -> Int which does fit exactly. > const :: forall (z :: Type). Int -> z -> Int > const x _ = x > > fc3 :: Int > fc3 = f (const 0) The story for type constructors is not so pleasant. I can define an analogue of `f` on the type level: > type F :: (forall (z :: Type). Maybe z -> Type) -> Type > newtype F k = F (k (Just Bool)) and the analogue of `c1` fits exactly: > type C1 :: forall (z :: Type). Maybe z -> Type > data C1 m = C1 > > type FC1 :: Type > type FC1 = F C1 but the analogue of `c2` does not: > type C2 :: forall (z :: Type). z -> Type > data C2 m = C2 > > -- Occurs check: cannot construct the infinite kind: z ~ Maybe z > -- type FC2 :: Type > -- type FC2 = F C2 nor does the analogue of `const`: > type Const :: forall (z :: Type). Type -> Maybe z -> Type > newtype Const z a = Const z > > -- • Expected kind ‘forall z. Maybe z -> *’, > -- but ‘Const ()’ has kind ‘Maybe a0 -> *’ > -- type FC3 :: Type > -- type FC3 = F (Const ()) To get the analogue of `const` we have to be much more specific: > type OtherConst :: Type -> forall (z :: Type). Maybe z -> Type > newtype OtherConst z b = OtherConst z > > type FC4 :: Type > type FC4 = F (OtherConst ()) This is rather unfortunate because it limits generic programming at the type level!

1 0

Why can't I promote data family constructors, and what to do instead?
by Tom Ellis 16 Sep '23

16 Sep '23

Hello Cafe, I'm confused why I can't promote data family constructors, and what I should do instead. This message is a literate Haskell file. > {-# LANGUAGE DataKinds #-} > {-# LANGUAGE StandaloneKindSignatures #-} > {-# LANGUAGE TypeFamilies #-} I can promote constructors of normal data types nicely, here CT1 is promoted > data T = CT1 Char > type PT1 = CT1 'x' Suppose I want to promote constructors of a "non uniform" data definition, that is one where the structure of the type depends on a type argument, In Haskell that means a GADT, type family or data family. For my purposes a type family is unsuitable. I need to be able to reference it unsaturated. A GADT is also unsuitable because it introduces extra runtime tags that I don't want. But nor do data families work because their constructors can't be promoted. > data family DF a > newtype instance DF Int = CDFInt1 Char > data instance DF Bool = CDFBool1 | CDFBool2 > > -- • Data constructor ‘CDFInt1’ cannot be used here > -- (it comes from a data family instance) > -- type PDF = CDFInt1 'x' The GHC users guide says Data family instance constructors cannot be promoted at the moment. GHC’s type theory just isn’t up to the task of promoting data families, which requires full dependent types. https://downloads.haskell.org/ghc/9.6.2/docs/users_guide/exts/data_kinds.ht… I'm puzzled about why I can't do that. I can do this > newtype DFInt = CDFInt1' Char > data DFBool = CDFBool1' | CDFBool2' > type family TF a > type instance TF Int = DFInt > type instance TF Bool = DFBool > type PNF1 :: TF Int > type PNF1 = CDFInt1' 'x' which I said above is unsuitable because I can't refer to `TF` unsaturated. But I can apply a standard trick of wrapping a type family in a newtype: > newtype NF a = CNF (TF a) > type PNF :: NF Int > type PNF = CNF (CDFInt1' 'x') Problem solved! But this goes all round the houses. What a mess! The data family version would be much neater if it worked. I have two questions: 1. Is this restriction *really* necessary? I'm surprised that GHC can't cope with promoting constructors of data families given that it is straightforward to simulate the desired behaviour with type families and a newtype. 2. Is my encoding the simplest that I can achieve? Note that the following GADT does *not* work because `GDFInt` has an unnecessary tag. > data GF a where > GDFInt :: Char -> GF Int > GDFBool1 :: GF Bool > GDFBool2 :: GF Bool

1 0