January 2022 - Glasgow-haskell-users

[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