August 2021 - Glasgow-haskell-users

[Haskell] [ANNOUNCE] GHC 8.10.7 released
by Zubin Duggal 26 Aug '21

26 Aug '21

The GHC team is very pleased to announce the availability of GHC 8.10.7. Source and binary distributions are available at the [usual place](https://downloads.haskell.org/ghc/8.10.7/). Download Page: https://www.haskell.org/ghc/download_ghc_8_10_7.html Blog Post: https://www.haskell.org/ghc/blog/20210827-ghc-8.10.7-released.html This is a small bugfix release, fixing one linking portability issue (#19950) present in GHC 8.10.5 and GHC 8.10.6 on some x86_64 macOS toolchains, which resulted in undefined symbol errors for `___darwin_check_fd_set_overflow`. Issue #19950 is caused by a bug in newer Apple toolchains (specifically XCode 12) where programs compiled with affected versions of XCode are not backwards compatible with configurations running older version of XCode (certain versions of XCode 11). We claimed to have fixed this in GHC 8.10.6, but alas this wasn't the case. The fix was originally tested on the master branch, which uses a different build configuration from the 8.10 branch. We have now tested the fix on the GHC 8.10 branch and finally squashed the bug. We would like to thank Microsoft Research, GitHub, IOHK, the Zw3rk stake pool, Tweag I/O, Serokell, Equinix, SimSpace, and other anonymous contributors whose on-going financial and in-kind support has facilitated GHC maintenance and release management over the years. We would also like to thank the hundreds of open-source contributors whose work makes GHC possible. A complete list of bug fixes and improvements can be found in the [release notes](https://downloads.haskell.org/ghc/8.10.7/docs/html/users_guide/8. 10.7-notes.html). As always, feel free to report any issues you encounter via [gitlab.haskell.org](https://gitlab.haskell.org/ghc/ghc/-/issues/new).

1 0

[ANNOUNCE] GHC 9.2.1-rc1 now available
by Ben Gamari 22 Aug '21

22 Aug '21

Hi all, The GHC developers are very happy to announce the availability of the release cadidate of the 9.2.1 release. Binary distributions, source distributions, and documentation are available at https://downloads.haskell.org/ghc/9.2.1-rc1 GHC 9.2 will bring a number of exciting features including: * A native code generation backend for AArch64, significantly speeding compilation time on ARM platforms like the Apple M1. * Many changes in the area of records, including the new `RecordDotSyntax` and `NoFieldSelectors` language extensions, as well as Support for `DuplicateRecordFields` with `PatternSynonyms`. * Introduction of the new `GHC2021` language extension set, giving users convenient access to a larger set of language extensions which have been long considered stable. * Merge of `ghc-exactprint` into the GHC tree, providing infrastructure for source-to-source program rewriting out-of-the-box. * Introduction of a `BoxedRep` `RuntimeRep`, allowing for polymorphism over levity of boxed objects (#17526) * Implementation of the `UnliftedDataTypes` extension, allowing users to define types which do not admit lazy evaluation ([proposal]) * The new [-hi profiling] mechanism which provides significantly improved insight into thunk leaks. * Support for the `ghc-debug` out-of-process heap inspection library [ghc-debug] * Support for profiling of pinned objects with the cost-centre profiler (#7275) * Introduction of Haddock documentation support in TemplateHaskell (#5467) Finally, thank you to Microsoft Research, GitHub, IOHK, the Zw3rk stake pool, Tweag I/O, Serokell, Equinix, SimSpace, and other anonymous contributors whose on-going financial and in-kind support has facilitated GHC maintenance and release management over the years. Moreover, 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 testing, - Ben [apple-m1]: https://www.haskell.org/ghc/blog/20210309-apple-m1-story.html [proposal]: https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0265-u… [-hi profiling]: https://well-typed.com/blog/2021/01/first-look-at-hi-profiling-mode/ [ghc-debug]: http://ghc.gitlab.haskell.org/ghc-debug/ [ticket]: https://gitlab.haskell.org/ghc/ghc/-/issues/new

2 3

The State of GHC 8.10
by Zubin Duggal 21 Aug '21

21 Aug '21

Hi all, GHC 8.10.6 was released last week, with high hopes of finally putting an end to the long running saga of the GHC 8.10 series. Unfortunately, this was not to be the case as we soon discovered #19950, an issue that we claimed to have fixed in the 8.10.6 release, was still affecting the released compiler. #19950 is caused by a bug in newer Apple toolchains (specifically XCode 12) where programs compiled with affected versions of XCode are not backwards compatible with configurations running older version of XCode (certain versions of XCode 11). It surfaced in GHC 8.10.5 since we upgraded the toolchain on our Darwin builders to one of the affected versions. The original fix/workaround for #19950 was tested on the master and GHC-9.2 branches and found to be working, and so backported to the 8.10 branch. Unfortunately, Darwin releases for 8.10 are still done using the Make build system, which did not pick up the extra linker options needed to work around the issue. It places a heavy burden on developers to have so many active branches of the compiler to keep in mind, and the current situation with 4 active branches is simply not sustainable. As the oldest currently active branch, it is currently a priority to retire the 8.10 branch of GHC from active development as soon as possible. We have now fixed and verified the fix for #19950 on the 8.10 branch and prepared a GHC 8.10.7 release including it. As of now, the only change in GHC 8.10.7 is to link the x86_64 darwin release build with a few extra linker options to work around #19950. If you have any other critical issues that prevent you from using GHC 8.10(.6), please raise them soon by either pointing to existing tickets on the tracker or creating a new one. We are planning to cut the new release as soon as early next week, and we are really hoping that this would be the final release in the 8.10 series. Cheers, Zubin.

1 0

-dinline-check for symbolic names?
by Michael Sperber 19 Aug '21

19 Aug '21

I'm trying to figure out why this function from ConCat.AltCat is not getting inlined: (&&&) :: forall k a c d. (MProductCat k, Ok3 k a c d) => (a `k` c) -> (a `k` d) -> (a `k` Prod k c d) f &&& g = (f *** g) . dup <+ okProd @k @a @a <+ okProd @k @c @d {-# INLINE (&&&) #-} So I put {-# OPTIONS_GHC -dinline-check ConCat.AltCat.&&& #-} in the importing module. Alas, I'm getting no output on &&&. I can get output from lots of other functions - I'm guessing it might be because of the name. Could somebody help me enable the inline check? Would be much appreciated! -- Regards, Mike

3 6

Avoiding construction of dead dictionaries
by Michael Sperber 16 Aug '21

16 Aug '21

I have another optimization problem. ConCat includes this definition: (<+) :: Con a => (Con b => r) -> (a |- b) -> r r <+ Entail (Sub Dict) = r The right-hand argument of <+ leads to a dictionary construction that is a proof of a certain property, but the dictionary itself ends up being dead, like so: case $w$dOpCon_r2kGJ ... of { (# ww1_s27L3 #) -> ... } ^^^^^^^^^ never used Yet, ghc (8.10.4) never elides this code. (I'm naively assuming because of the unboxed tuple, but actually have no clue.) Is there any chance of convincing ghc of erasing the dictionary construction? Help would be much appreciated! -- Regards, Mike

5 11

[ANN] Cabal-3.6.0.0
by Emily Pillmore 15 Aug '21

15 Aug '21

Hello All, The Cabal team is excited to announce the release of Cabal-3.6.0.0! This is the fourth release of the 3.0 release series, and highlights include support for GHC 9.2, as well as many new code quality improvements + organization work on the repo itself. For future plans, we've announced a State of the Cabal post which describes where we want to take the library and executable over the next year or two here: https://discourse.haskell.org/t/state-of-the-cabal-q1-q2-2021/2548. If you'd like to get involved, feel free to contact anyone from the maintainer team directly, or drop by #hackage on libera.chat ( http://libera.chat/ ) to speak with us. Additionally, as we continue to modernize Cabal, I'd like to highlight and show appreciation for all of the help we've gotten from the community, including the developer hours coming from Well-Typed, Haskell Foundation/Haskell.org ( http://foundation/Haskell.org ) , Obsidian Systems, and the Haskell Language Server folks. I'm glad we could work together! For a full set of release notes, see https://github.com/haskell/cabal/blob/master/release-notes/Cabal-3.6.0.0.md. If you have issues, we'd love to hear about there here: https://github.com/haskell/cabal/issues. Happy hacking! Emily

5 10

[Haskell] [ANNOUNCE] GHC 8.10.6 released
by Zubin Duggal 14 Aug '21

14 Aug '21

The GHC team is very pleased to announce the availability of GHC 8.10.6. Source and binary distributions are available at the [usual place](https://downloads.haskell.org/ghc/8.10.6/). Download Page: https://www.haskell.org/ghc/download_ghc_8_10_6.html Blog Post: https://www.haskell.org/ghc/blog/20210814-ghc-8.10.6-released.html This is a bugfix release, fixing many issues present in GHC 8.10.5, including: - A fix for segmentation faults in GHCi on `aarch64-darwin` due to an incorrect foreign import in `haskeline`. See [this blog post](https://www.haskell.org/ghc/blog/20210709-capi-usage.html) by Ben Gamari for more details on how your library could be affected. - A fix for a critical bug affecting Haskell Language Server (HLS) among other applications caused by missing RTS symbols required for statically linked builds of the GHC library (#19763). - No longer emitting spurious warnings for LLVM versions (LLVM 9-12) that were actually supported (#19973, #19829, #19959). - Numerous bug fixes for the new LLVM based `aarch64-darwin` backend (#20132). - Fixes and stability improvements for the non-moving GC (#19715). - Many other bug fixes for the RTS (#18033, #20132, #20093, #19421). - Many packaging related fixes, including versioned `ghc-pkg` executables (#20087), and actually distributing GHC versions linked against the `integer-simple` big integer backend (#18967, #19953) on both Windows and Alpine Linux. Previous releases were still linked against the `GMP` library due to a misconfiguration of the builders. - A significant refactoring of `process` fixing numerous bugs mostly on Apple platforms (#19994, [process refactoring](https://github.com/haskell/process/pull/208)) - A FreeBSD release after fixing issues that caused GHC 8.10.5 to be unable to build (#19958, #19948). - Bug fixes for the linker on Darwin platforms (#20004, #19968, #19950). A complete list of bug fixes and improvements can be found in the [release notes](https://downloads.haskell.org/ghc/8.10.6/docs/html/users_guide/8.10.…. As always, feel free to report any issues you encounter via [gitlab.haskell.org](https://gitlab.haskell.org/ghc/ghc/-/issues/new).

1 0

InstanceSigs -- rationale for the "must be more polymorphic than"
by Anthony Clayden 10 Aug '21

10 Aug '21

I can't help but feel InstanceSigs are either superfluous or upside-down. It's this bit in the User Guide: > The type signature in the instance declaration must be > more polymorphic than (or the same as) the one in the class declaration, > instantiated with the instance type. Usually if you give a signature, it must be _less_ polymorphic (or the same as) the type inferred from the term: > lessPolyPlus :: Integral a => a -> a -> a > lessPolyPlus x y = x + y Or > lessPolyPlus (x :: a) y = x + y :: Integral a => a The examples in the User Guide aren't helping: you could just drop the InstanceSigs, and all is well-typed. (Even the example alleging to use -XScopedTypeVariables in a where sub-decl: you could just put random `xs :: [b]` without scoping `b`.) Dropping the Sigs altogether works because the type from the class decl, suitably instantiated, is less polymorphic than inferred from the term. IOW the suitably instantiated type restricts what would otherwise be inferred. Situation normal. I suppose it might be helpful to give an explicit InstanceSig as 'belt and braces' for the instantiated -- possibly because the instantiation is hard to figure out; possibly because you want to use -XScopedTypeVariables within a where-bound sub-decl, as an extra piece of string. I can see you mustn't make the InstanceSig _less_ polymorphic than the suitably instantiated. But the docos don't give any example where it's essential to provide an InstanceSig _and_ make it strictly more polymorphic. Here all the sigs and annotations are just superfluous: > maxPolyPlus :: Num a => a -> a -> a > maxPolyPlus = (+) > > class C a where foo :: a -> T a > instance Integral a => C a where > foo :: Num a => a -> T a > foo (x :: a) = MkT (maxPolyPlus x x :: Num a => a) Is there a persuasive example (to put in the User Guide)? AntC

3 6