- Glasgow-haskell-users

GHC 9.4.1-alpha2 now available
by Ben Gamari 24 May '22

24 May '22

The GHC developers are happy to announce the availability of the second alpha release of the GHC 9.4 series. Binary distributions, source distributions, and documentation are available at downloads.haskell.org: https://downloads.haskell.org/ghc/9.4.1-alpha2 This major release will include: - A new profiling mode, `-fprof-late`, which adds automatic cost-center annotations to all top-level functions *after* Core optimisation has run. This incurs significantly less performance cost while still providing informative profiles. - A variety of plugin improvements including the introduction of a new plugin type, *defaulting plugins*, and the ability for typechecking plugins to rewrite type-families. - An improved constructed product result analysis, allowing unboxing of nested structures, and a new boxity analysis, leading to less reboxing. - Introduction of a tag-check elision optimisation, bringing significant performance improvements in strict programs. - Generalisation of a variety of primitive types to be levity polymorphic. Consequently, the `ArrayArray#` type can at long last be retired, replaced by standard `Array#`. - Introduction of the `\cases` syntax from [GHC proposal 0302] - A complete overhaul of GHC's Windows support. This includes a migration to a fully Clang-based C toolchain, a deep refactoring of the linker, and many fixes in WinIO. - Support for multiple home packages, significantly improving support in IDEs and other tools for multi-package projects. - A refactoring of GHC's error message infrastructure, allowing GHC to provide diagnostic information to downstream consumers as structured data, greatly easing IDE support. - Significant compile-time improvements to runtime and memory consumption. - On overhaul of our packaging infrastructure, allowing full traceability of release artifacts and more reliable binary distributions. - ... and much more. See the [release notes] for a full accounting. Note that, as 9.4.1 is the first release for which the released artifacts will all be generated by Hadrian, it's 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]. We would like to thank Microsoft Azure, 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. 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 testing, - Ben [GHC proposal 0302]: https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0302-c… [ticket]: https://gitlab.haskell.org/ghc/ghc/-/issues/new [bootstrap script]: https://gitlab.haskell.org/ghc/ghc/-/blob/e2520df3fffa0cf22fb19c5fb872832d1… [release notes]: https://downloads.haskell.org/~ghc/9.4.1-alpha2/docs/users_guide/9.4.1-note…

1 0

Why aren't classes like "Num" levity polymorphic?
by Clinton Mead 09 May '22

09 May '22

Hi All It seems to me to be a free win just to replace: `class Num a where` with `class Num (a :: (r :: RuntimeRep)) where` And then one could define `Num` instances for unlifted types. This would make it possible to avoid using the ugly `+#` etc syntax for operations on unlifted types. `Int#` and `Word#` could have `Num` instances defined just as `Int` and `Word` already have. I presume there's a reason why this hasn't been done, but I was wondering why? Thanks, Clinton

2 3

[ANNOUNCE] GHC 9.2.2 is not available
by Ben Gamari 05 May '22

05 May '22

The GHC developers are very happy to at announce the availability of GHC 9.2.2. Binary distributions, source distributions, and documentation are available at downloads.haskell.org: https://downloads.haskell.org/ghc/9.2.2 This release includes many bug-fixes and other improvements to 9.2.1 including: * A number of bug-fixes in the new AArch64 native code generator * Fixes ensuring that the `indexWord8ArrayAs*#` family of primops is handled correctly on platforms lacking support for unaligned memory accesses (#21015, #20987). * Improvements to the compatibility story in GHC's migration to the XDG Base Directory Specification (#20684, #20669, #20660) * Restored compatibility with Windows 7 * A new `-fcompact-unwind` flag, improving compatibility with C++ libraries on Apple Darwin (#11829) * Introduction of a new flag, `-fcheck-prim-bounds`, enabling runtime bounds checking of array primops (#20769) * Unboxing of unlifted types (#20663) * Numerous improvements in compiler performance. * Many, many others. See the [release notes] for a full list. As some of the fixed issues do affect correctness users are encouraged to upgrade promptly. 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 open a [ticket][] if you see anything amiss. Happy compiling, - Ben [ticket]: https://gitlab.haskell.org/ghc/ghc/-/issues/new [release notes]: https://downloads.haskell.org/ghc/9.2.2/docs/html/users_guide/9.2.2-notes.h…

4 6

GHC 9.4.1-alpha1 now available
by Ben Gamari 01 May '22

01 May '22

The GHC developers are happy to announce the availability of the first alpha release of the GHC 9.4 series. Binary distributions, source distributions, and documentation are available at downloads.haskell.org: https://downloads.haskell.org/ghc/9.4.1-alpha1 This major release will include: - A new profiling mode, `-fprof-late`, which adds automatic cost-center annotations to all top-level functions *after* Core optimisation has run. This incurs significantly less performance cost while still providing informative profiles. - A variety of plugin improvements including the introduction of a new plugin type, *defaulting plugins*, and the ability for typechecking plugins to rewrite type-families. - An improved constructed product result analysis, allowing unboxing of nested structures, and a new boxity analysis, leading to less reboxing. - Introduction of a tag-check elision optimisation, bringing significant performance improvements in strict programs. - Generalisation of a variety of primitive types to be levity polymorphic. Consequently, the `ArrayArray#` type can at long last be retired, replaced by standard `Array#`. - Introduction of the `\cases` syntax from [GHC proposal 0302] - A complete overhaul of GHC's Windows support. This includes a migration to a fully Clang-based C toolchain, a deep refactoring of the linker, and many fixes in WinIO. - Support for multiple home packages, significantly improving support in IDEs and other tools for multi-package projects. - A refactoring of GHC's error message infrastructure, allowing GHC to provide diagnostic information to downstream consumers as structured data, greatly easing IDE support. - Significant compile-time improvements to runtime and memory consumption. - ... and much more We would like to thank Microsoft Azure, 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. 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 testing, - Ben [GHC proposal 0302]: https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0302-c… [ticket]: https://gitlab.haskell.org/ghc/ghc/-/issues/new

1 0

Haskell.org outage
by Ben Gamari 18 Apr '22

18 Apr '22

Hello everyone, Unfortunately Haskell.org, downloads.haskell.org, and hoogle.haskell.org are currently down. We are currently investigating the cause. Updates will be posted as they are available. Cheers, - Ben

1 1

Types differ, but they look the same
by Joachim Breitner 08 Apr '22

08 Apr '22

Hi, sorry for not providing a mwe, but while I dig deeper, maybe someone has a “this is typically a problem with X” idea… This is in the context of a Core plugin (Conal’s Compiling to Categories), and I observe an oddity: I have two 'Types' that _should_ be equal, that ppr’int equal, but where eqType says False. The type looks like this: (SymRAD1 windowFunctor_a3e0Q kernelFunctor_a3e0R channelsFunctor_a3e0S numType_a3e0T, SymRAD2 paddedWindowFunctor_a3e0P windowFunctor_a3e0Q kernelFunctor_a3e0R channelsFunctor_a3e0S numType_a3e0T) what might make eqType go False that is _not_ visible in the pretty- printed view? Cheers, Joachim -- Joachim Breitner mail(a)joachim-breitner.de http://www.joachim-breitner.de/

1 1

Are constructors matched against using "switch" or chained if-else
by Clinton Mead 23 Feb '22

23 Feb '22

Hi All I'm developing an unbounded integer type, which I won't go into the details here but in some circumstances has better performance than the standard "Integer". Anyway, whilst there are complex cases, the most common case is a standard machine int multiplication. Hence I want the type to be optimised for that case. I'm going to have a few constructors, anyway, so I first considered something like this: `data MyInt = BasicZero | BasicPos Word | BasicNeg Word | ComplexPosA ... | ComplexNegA ... | ComplexPosB ... | ComplexNegB ...` I'd naturally make the "Word"s in "BasicPos" and "BasicNeg" strict/unpack, hopefully eliminating the indirection, or perhaps just making them primitive directly. This has 7 constructors, which quite nicely I believe fits into the three spare bits in a 64 bit pointer which GHC optimises I believe. However, this approach I thought of because I assumed that GHC would do a switch style statement on the constructors, so once I have more than one I might as well have as many as I want (well, up to 7, until I lose the optimisation). But if GHC compiles this to a "if ... else if..." chain, a better representation is the following: `data MyInt = BasicInt Int | ComplexPosA ... | ComplexNegA ... | ComplexPosB ... | ComplexNegB ...` That way I can match against BasicInt first, and knock that out of the way as my "hot" case. However, using "Int" instead of "Word" does make the logic a bit more complex, but it may be worth it if I'm reducing the number of patterns I have to check against for all arguments. I was just wondering if anyone could share some insight on what GHC does in these circumstances? For example, does the order I list my cases in a case statement matter if they're non-overlapping? Will GHC match them in the order I list, or will it just make them into a switch statement so it doesn't matter if I reorder them? I guess I could benchmark all this (and probably will) but some insights and general guidance would be good. Thanks, Clinton

2 5

[Haskell] [ANNOUNCE] GHC 9.0.2 released
by Zubin Duggal 23 Jan '22

23 Jan '22

The GHC developers are very happy to at long last announce the availability of GHC 9.0.2. Binary distributions, source distributions, and documentation are available at the [usual place](https://downloads.haskell.org/ghc/9.0.2/). Download Page: https://www.haskell.org/ghc/download_ghc_9_0_2.html Blog Post: https://www.haskell.org/ghc/blog/20211225-ghc-9.0.2-released.html GHC 9.0.2 adds first class AArch64/Darwin support using the LLVM backend, as well as fixing a number of critical correctness bugs with the 9.0.1 release, along with numerous improvements to compiler performance and memory usage: * First-class support for Apple M1 hardware using GHC's LLVM ARM backend. * Fix a number of incorrect rewrite rules for `fromInteger` (#19345, #20066). * Fix a number of runtime system and GC bugs which typically manifested in crashes (#19417, #19297, #19645, #19667, #18033, #20132, #19715, #20399, #20414, #20649, #19147, #20051, #20093) * Fixes for various compiler performance and memory usage issues (#20134, #13586, #20509, #19668, #19996, #19471) * Improvements and bug fixes for the code generator and optimiser (#18638, #19581, #19700, #19996, #19181, #19822) * Fixes for typechecker bugs (#19410 , #19191, #19522, #19400, #19849) * Bug fixes for the frontend and parser (#19397, #19838, #19518, #19777, #20242, #19786) * Emit warnings if Unicode Bidirectional Formatting characters are found in the source, possibly misleading code reviewers (#20263). * Many packaging related fixes, including versioned `ghc-pkg` executables (#20087), and actually distributing GHC versions linked against the `native` big integer backend (#18967, #19953) on both Windows and Alpine Linux. Some 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)) * 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/9.0.2/docs/html/users_guide/9.0.2-…. 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 open a [ticket][] if you see anything amiss. Happy Holidays and Happy Hacking! - Zubin

4 6

Typing of Pattern Synonyms: Required vs Provided constraints
by Anthony Clayden 06 Jan '22

06 Jan '22

There was an interesting exchange between the authors of Haskell compilers back in 1999 (i.e. when there were multiple compilers) http://web.archive.org/web/20151001142647/http://code.haskell.org/~dons/has… I was trying to simulate SPJ's point of view, using PatternSynonyms. > > {-# LANGUAGE DatatypeContexts, PatternSynonyms #-} > > data Ord a => TSPJ a = MkTSPJ a a > > pattern PatTSPJ :: (Ord a) => () => a -> a -> TSPJ a -- empty Provided > pattern PatTSPJ x y = MkTSPJ x y > > unPatTSPJ :: TSPJ a -> (a, a) -- no constraints > unPatTSPJ (PatTSPJ x y) = (x, y) > `unPatSPJ`'s binding rejected `No instance for (Ord a) arising from a pattern`. If I don't give a signature, inferred `unPatTSPJ :: Ord b => TSPJ b -> (b, b)`. Taking the DatatypeContext off the `data` decl doesn't make a difference. So Pattern syns seem to be giving exactly the 'stupid theta' behaviour. The User Guide https://downloads.haskell.org/~ghc/8.10.7/docs/html/users_guide/glasgow_ext… says - ⟨CProv⟩ are the constraints *made available (provided)* by a successful pattern match. But it doesn't mean that. It's more like "⟨CProv⟩ are the constraints made available *in addition to ⟨CReq⟩* (provided union required) by a successful pattern match." Or ... is there some way to simulate the up-to-1999 GHC behaviour? (I happen to agree with SPJ; Wadler wasn't thinking it through; consider for example constructor classes over type constructors with constraints: there's nothing in the instance head for the constraint to attach to. Now that we have GADTs -- which are appropriate for a different job -- that DT Contexts perhaps were being (ab-)used for -- I agree more strongly with SPJ.) With GADTs I could get a `unGSPJ` that doesn't expose/provide the constraint, but it does that by packing the constraint/dictionary (polluting) inside the data constructor. Not what I want. As SPJ says down-thread "when you take a constructor *apart*, the invariant must hold by construction: you couldn't have built the thing you are taking apart unless invariant held. So enforcing the invariant again is redundant; and in addition it pollutes the type of selectors." AntC

3 4

Fwd: Typing of Pattern Synonyms: Required vs Provided constraints
by Anthony Clayden 06 Jan '22

06 Jan '22

Thanks Gergö, I do find Richard's tendency to use ViewPattern examples distracts me from understanding the point. That arrow-to-nowhere or arrow-to-the-wrong-value syntax is nausea-inducing. Your "instructive" example is really nothing to do with PatSyns, just ordinary Haskell numeric patterns: the Language Report (section 3.17.2 point 7., same wording in 2010 and '98) says a numeric literal in a pattern gets desugared to an `(==)` test against `fromInteger <something>`. So that explains where the constraints come from. (Annoyingly, the <something> you can't express in legit Haskell source.) Avoiding distractions is why my o.p. used an `Ord` constraint, also to follow SPJ's 1999 example. And the canonical example in those old discussions (like Hughes' 1999 paper) is an `Ord` constraint for elements of a `Set` structured as a BST. With your "polymorphic literal" how do I follow the Language Report to desugar? I'd rather be able to write Richard's example using an as-Pattern like one of these: > pattern x@Is3 | x == fromInteger (#3#) = x -- where #3# is the inexpressible <something> > pattern x@3@Is3 = x (It's not that I'm "new to patsyn typing"; it's more that patsyn typing and design keeps falling short of what I hope from such a promising feature. So I always want to check I'm not mis-understanding. Specifically, the design for Pattern Synonyms was a lost opportunity to expunge ViewPatterns entirely.) AntC On Fri, 7 Jan 2022 at 09:43, Gergő Érdi <gergo(a)erdi.hu> wrote: > Fwiw, a less contrived, and much more relatable, version of Richard's > example would be > > > pattern Is3 :: (Num a, Eq a) => a -- only a Required constraint > pattern Is3 = 3 -- a polymorphic literal! > > I think it can be quite instructive for people new to patsyn typing to > work out why this is exactly the same as the one in Richard's email! > > > On Thu, Jan 6, 2022, 21:11 Richard Eisenberg <lists(a)richarde.dev> wrote: > >> >> >> ... >> >>

1 0