From ben at well-typed.com Sun May 1 23:17:01 2022 From: ben at well-typed.com (Ben Gamari) Date: Sun, 01 May 2022 19:17:01 -0400 Subject: GHC 9.4.1-alpha1 now available Message-ID: <87h768alnr.fsf@smart-cactus.org> 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-cases.rst [ticket]: https://gitlab.haskell.org/ghc/ghc/-/issues/new -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From george.colpitts at gmail.com Mon May 2 10:59:00 2022 From: george.colpitts at gmail.com (George Colpitts) Date: Mon, 2 May 2022 07:59:00 -0300 Subject: macos install issue: ghc-pkg-9.2.2 cannot be opened because the developer cannot be verified In-Reply-To: <20220307.152740.1433207400109063719.kazu@iij.ad.jp> References: <87r17ewuxe.fsf@smart-cactus.org> <20220307.152740.1433207400109063719.kazu@iij.ad.jp> Message-ID: Hi Did this get fixed? Is it fixed in 9.4.1-alpha1? Thanks George On Mon, Mar 7, 2022 at 2:27 AM Kazu Yamamoto wrote: > Hi George, > > FYI: > > https://twitter.com/kazu_yamamoto/status/1500643489985761282 > > --Kazu > > > Thanks Ben > > > > When I do an install on macos Monterey 12.2.1 (Intel) I get > > > > ghc-pkg-9.2.2 cannot be opened because the developer cannot be verified > > > > > > On Sun, Mar 6, 2022 at 7:02 PM Ben Gamari wrote: > > > >> > >> 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.html > >> > >> _______________________________________________ > >> Glasgow-haskell-users mailing list > >> Glasgow-haskell-users at haskell.org > >> http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users > >> > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From george.colpitts at gmail.com Thu May 5 15:56:19 2022 From: george.colpitts at gmail.com (George Colpitts) Date: Thu, 5 May 2022 12:56:19 -0300 Subject: macos install issue: ghc-pkg-9.2.2 cannot be opened because the developer cannot be verified In-Reply-To: References: <87r17ewuxe.fsf@smart-cactus.org> <20220307.152740.1433207400109063719.kazu@iij.ad.jp> Message-ID: It's not fixed for me so I filed https://gitlab.haskell.org/ghc/ghc/-/issues/21506 On Mon, May 2, 2022 at 7:59 AM George Colpitts wrote: > Hi > > Did this get fixed? Is it fixed in 9.4.1-alpha1? > > Thanks > George > > On Mon, Mar 7, 2022 at 2:27 AM Kazu Yamamoto wrote: > >> Hi George, >> >> FYI: >> >> https://twitter.com/kazu_yamamoto/status/1500643489985761282 >> >> --Kazu >> >> > Thanks Ben >> > >> > When I do an install on macos Monterey 12.2.1 (Intel) I get >> > >> > ghc-pkg-9.2.2 cannot be opened because the developer cannot be verified >> > >> > >> > On Sun, Mar 6, 2022 at 7:02 PM Ben Gamari wrote: >> > >> >> >> >> 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.html >> >> >> >> _______________________________________________ >> >> Glasgow-haskell-users mailing list >> >> Glasgow-haskell-users at haskell.org >> >> http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users >> >> >> >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From clintonmead at gmail.com Mon May 9 15:26:52 2022 From: clintonmead at gmail.com (Clinton Mead) Date: Tue, 10 May 2022 01:26:52 +1000 Subject: Why aren't classes like "Num" levity polymorphic? Message-ID: 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From ekmett at gmail.com Mon May 9 16:24:28 2022 From: ekmett at gmail.com (Edward Kmett) Date: Mon, 9 May 2022 12:24:28 -0400 Subject: Why aren't classes like "Num" levity polymorphic? In-Reply-To: References: Message-ID: It is rather shockingly difficult to get it to work out because of the default definitions in each class. Consider just class Eq (a :: TYPE r) where (==), (/=) :: a -> a -> Bool That looks good until you remember that x == y = not (x /= y) x /= y = not (x == y) are also included in the class, and cannot be written in a RuntimeRep polymorphic form! The problem is that x has unknown rep and is an argument. We can only be levity polymorphic in results. So you then have to do something like default (==) :: EqRep r => a -> a -> Bool (==) = eqDef default (/=) :: EqRep r => a -> a -> Bool (/=) = neDef class EqRep (r :: RuntimeRep) where eqDef, neDef :: forall (a :: TYPE r). Eq a => a -> a -> Bool and then bury them in a class that actually knows about the RuntimeRep. We can lift the Prelude.Eq into the modified Eq above pointwise inside kind Type. instance Prelude.Eq a => Eq (a :: Type) where (==) = (Prelude.==) (/=) = (Prelude./=) and/or we can instantiate EqRep at _all_ the RuntimeReps. That is where we run into a problem. You could use a compiler plugin to discharge the constraint (which is something I'm actively looking into) or you can do something like write out a few hand-written instances that are all completely syntactically equal: instance EqRep LiftedRep where eqDef x y = not (x /= y) neDef x y = not (x == y) instance EqRep ... where ... The approach I'm taking today is to use backpack to generate these EqRep instances in a canonical location. It unfortunately breaks GHC when used in sufficient anger to handle TupleRep's of degree 2 in full generality, because command line lengths for each GHC invocation starts crossing 2 megabytes(!) and we break operating system limits on command line lengths, because we don't have full support for passing arguments in files from cabal to ghc. The approach I'd like to take in the future is to discharge those obligations via plugin. There are more tricks that you wind up needing when you go to progress to handle things like Functor in a polymorphic enough way. type Lev (a :: TYPE r) = () => a is another very useful tool in this toolbox, because it is needed when you want to delay a computation on an argument in a runtime-rep polymorphic way. Why? Even though a has kind TYPE r. Lev a always has kind Type! So I can pass it in argument position independent of RuntimeRep. ifThenElse :: forall r (a :: TYPE r). Bool -> Lev a -> Lev a -> a ifThenElse True x _ = x ifThenElse False _ y = y Note this function didn't need any fancy FooRep machinery and it has the right semantics in that it doesn't evaluate the arguments prematurely! This trick is needed when you want to go convert some kind of RuntimeRep polymorphic Maybe or List for one RuntimeRep to one for another RuntimeRep unless you want to deal with an explosive number of instances parameterized on pairs of RuntimeReps. https://github.com/ekmett/unboxed is a repo of me experimenting with this from last year some time. I'm also giving a talk at Yow! LambdaJam in a week or so on this! -Edward On Mon, May 9, 2022 at 11:27 AM Clinton Mead wrote: > 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 > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ekmett at gmail.com Mon May 9 16:30:35 2022 From: ekmett at gmail.com (Edward Kmett) Date: Mon, 9 May 2022 12:30:35 -0400 Subject: Why aren't classes like "Num" levity polymorphic? In-Reply-To: References:

Message-ID: Also, if you do want to experiment with this in ghci you need to set some flags in .ghci: -- ghci binds 'it' to the last expression by default, but it assumes it lives in Type. this blocks overloaded printing :set -fno-it -- replace System.IO.print with whatever 'print' is in scope. You'll need a RuntimeRep polymorphic 'print' function, though. :set -interactive-print print -- we don't want standard Prelude definitions. The above Lev trick for ifThenElse was required because turning on RebindableSyntax broke if. :set -XRebindableSyntax -XNoImplicitPrelude etc. With that you can get surprisingly far. It is rather nice being able to use (+) and a Show and the like on primitive Int#s and what have you. For me the main win is that I can do things like install Eq on (MutableByteArray# s) and the like and stop having to use random function names to access that functionality. You can also use the new UnliftedDataTypes and/or UnliftedNewtypes to do things like pass around a Natural# that is stored in a couple of registers and then build support for it. This is also included in that repo above. -Edward On Mon, May 9, 2022 at 12:24 PM Edward Kmett wrote: > It is rather shockingly difficult to get it to work out because of the > default definitions in each class. > > Consider just > > class Eq (a :: TYPE r) where > (==), (/=) :: a -> a -> Bool > > That looks good until you remember that > > x == y = not (x /= y) > x /= y = not (x == y) > > are also included in the class, and cannot be written in a RuntimeRep > polymorphic form! > > The problem is that x has unknown rep and is an argument. We can only be > levity polymorphic in results. > > So you then have to do something like > > default (==) :: EqRep r => a -> a -> Bool > (==) = eqDef > default (/=) :: EqRep r => a -> a -> Bool > (/=) = neDef > > > class EqRep (r :: RuntimeRep) where > eqDef, neDef :: forall (a :: TYPE r). Eq a => a -> a -> Bool > > and then bury them in a class that actually knows about the RuntimeRep. > > We can lift the Prelude.Eq into the modified Eq above pointwise inside > kind Type. > > instance Prelude.Eq a => Eq (a :: Type) where > (==) = (Prelude.==) > (/=) = (Prelude./=) > > and/or we can instantiate EqRep at _all_ the RuntimeReps. > > That is where we run into a problem. You could use a compiler plugin to > discharge the constraint (which is something I'm actively looking into) or > you can do something like write out a few hand-written instances that are > all completely syntactically equal: > > instance EqRep LiftedRep where > eqDef x y = not (x /= y) > neDef x y = not (x == y) > > instance EqRep ... where > ... > > The approach I'm taking today is to use backpack to generate these EqRep > instances in a canonical location. It unfortunately breaks GHC when used in > sufficient anger to handle TupleRep's of degree 2 in full generality, > because command line lengths for each GHC invocation starts crossing 2 > megabytes(!) and we break operating system limits on command line lengths, > because we don't have full support for passing arguments in files from > cabal to ghc. > > The approach I'd like to take in the future is to discharge those > obligations via plugin. > > > There are more tricks that you wind up needing when you go to progress to > handle things like Functor in a polymorphic enough way. > > type Lev (a :: TYPE r) = () => a > > is another very useful tool in this toolbox, because it is needed when you > want to delay a computation on an argument in a runtime-rep polymorphic way. > > Why? Even though a has kind TYPE r. Lev a always has kind Type! > > So I can pass it in argument position independent of RuntimeRep. > > ifThenElse :: forall r (a :: TYPE r). Bool -> Lev a -> Lev a -> a > ifThenElse True x _ = x > ifThenElse False _ y = y > > Note this function didn't need any fancy FooRep machinery and it has the > right semantics in that it doesn't evaluate the arguments prematurely! This > trick is needed when you want to go convert some kind of RuntimeRep > polymorphic Maybe or List for one RuntimeRep to one for another RuntimeRep > unless you want to deal with an explosive number of instances parameterized > on pairs of RuntimeReps. > > https://github.com/ekmett/unboxed is a repo of me experimenting with this > from last year some time. > > I'm also giving a talk at Yow! LambdaJam in a week or so on this! > > -Edward > > > On Mon, May 9, 2022 at 11:27 AM Clinton Mead > wrote: > >> 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 >> _______________________________________________ >> Glasgow-haskell-users mailing list >> Glasgow-haskell-users at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ekmett at gmail.com Mon May 9 16:32:53 2022 From: ekmett at gmail.com (Edward Kmett) Date: Mon, 9 May 2022 12:32:53 -0400 Subject: Why aren't classes like "Num" levity polymorphic? In-Reply-To: References:

Message-ID: Another, weaker version of this is to just require default signatures that assume r has type LiftedRep for each of the defaults, but then instantiating things at obscure kinds becomes _much_ harder. -Edward On Mon, May 9, 2022 at 12:30 PM Edward Kmett wrote: > Also, if you do want to experiment with this in ghci you need to set some > flags in .ghci: > > -- ghci binds 'it' to the last expression by default, but it assumes it > lives in Type. this blocks overloaded printing > :set -fno-it > > -- replace System.IO.print with whatever 'print' is in scope. You'll need > a RuntimeRep polymorphic 'print' function, though. > :set -interactive-print print > > -- we don't want standard Prelude definitions. The above Lev trick for > ifThenElse was required because turning on RebindableSyntax broke if. > :set -XRebindableSyntax -XNoImplicitPrelude > > etc. > > With that you can get surprisingly far. It is rather nice being able to > use (+) and a Show and the like on primitive Int#s and what have you. > > For me the main win is that I can do things like install Eq on > (MutableByteArray# s) and the like and stop having to use random function > names to access that functionality. > > You can also use the new UnliftedDataTypes and/or UnliftedNewtypes to do > things like pass around a Natural# that is stored in a couple of registers > and then build support for it. This is also included in that repo above. > > > -Edward > > On Mon, May 9, 2022 at 12:24 PM Edward Kmett wrote: > >> It is rather shockingly difficult to get it to work out because of the >> default definitions in each class. >> >> Consider just >> >> class Eq (a :: TYPE r) where >> (==), (/=) :: a -> a -> Bool >> >> That looks good until you remember that >> >> x == y = not (x /= y) >> x /= y = not (x == y) >> >> are also included in the class, and cannot be written in a RuntimeRep >> polymorphic form! >> >> The problem is that x has unknown rep and is an argument. We can only be >> levity polymorphic in results. >> >> So you then have to do something like >> >> default (==) :: EqRep r => a -> a -> Bool >> (==) = eqDef >> default (/=) :: EqRep r => a -> a -> Bool >> (/=) = neDef >> >> >> class EqRep (r :: RuntimeRep) where >> eqDef, neDef :: forall (a :: TYPE r). Eq a => a -> a -> Bool >> >> and then bury them in a class that actually knows about the RuntimeRep. >> >> We can lift the Prelude.Eq into the modified Eq above pointwise inside >> kind Type. >> >> instance Prelude.Eq a => Eq (a :: Type) where >> (==) = (Prelude.==) >> (/=) = (Prelude./=) >> >> and/or we can instantiate EqRep at _all_ the RuntimeReps. >> >> That is where we run into a problem. You could use a compiler plugin to >> discharge the constraint (which is something I'm actively looking into) or >> you can do something like write out a few hand-written instances that are >> all completely syntactically equal: >> >> instance EqRep LiftedRep where >> eqDef x y = not (x /= y) >> neDef x y = not (x == y) >> >> instance EqRep ... where >> ... >> >> The approach I'm taking today is to use backpack to generate these EqRep >> instances in a canonical location. It unfortunately breaks GHC when used in >> sufficient anger to handle TupleRep's of degree 2 in full generality, >> because command line lengths for each GHC invocation starts crossing 2 >> megabytes(!) and we break operating system limits on command line lengths, >> because we don't have full support for passing arguments in files from >> cabal to ghc. >> >> The approach I'd like to take in the future is to discharge those >> obligations via plugin. >> >> >> There are more tricks that you wind up needing when you go to progress to >> handle things like Functor in a polymorphic enough way. >> >> type Lev (a :: TYPE r) = () => a >> >> is another very useful tool in this toolbox, because it is needed when >> you want to delay a computation on an argument in a runtime-rep polymorphic >> way. >> >> Why? Even though a has kind TYPE r. Lev a always has kind Type! >> >> So I can pass it in argument position independent of RuntimeRep. >> >> ifThenElse :: forall r (a :: TYPE r). Bool -> Lev a -> Lev a -> a >> ifThenElse True x _ = x >> ifThenElse False _ y = y >> >> Note this function didn't need any fancy FooRep machinery and it has the >> right semantics in that it doesn't evaluate the arguments prematurely! This >> trick is needed when you want to go convert some kind of RuntimeRep >> polymorphic Maybe or List for one RuntimeRep to one for another RuntimeRep >> unless you want to deal with an explosive number of instances parameterized >> on pairs of RuntimeReps. >> >> https://github.com/ekmett/unboxed is a repo of me experimenting with >> this from last year some time. >> >> I'm also giving a talk at Yow! LambdaJam in a week or so on this! >> >> -Edward >> >> >> On Mon, May 9, 2022 at 11:27 AM Clinton Mead >> wrote: >> >>> 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 >>> _______________________________________________ >>> Glasgow-haskell-users mailing list >>> Glasgow-haskell-users at haskell.org >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users >>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben at well-typed.com Tue May 24 16:44:53 2022 From: ben at well-typed.com (Ben Gamari) Date: Tue, 24 May 2022 12:44:53 -0400 Subject: GHC 9.4.1-alpha2 now available Message-ID: <8735gy98yb.fsf@smart-cactus.org> 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-cases.rst [ticket]: https://gitlab.haskell.org/ghc/ghc/-/issues/new [bootstrap script]: https://gitlab.haskell.org/ghc/ghc/-/blob/e2520df3fffa0cf22fb19c5fb872832d11c07d35/hadrian/bootstrap/README.md [release notes]: https://downloads.haskell.org/~ghc/9.4.1-alpha2/docs/users_guide/9.4.1-notes.html -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From ben at well-typed.com Fri May 27 17:01:16 2022 From: ben at well-typed.com (Ben Gamari) Date: Fri, 27 May 2022 13:01:16 -0400 Subject: GHC.X.Hackage and GHC's release cycle Message-ID: <87v8tq7vwz.fsf@smart-cactus.org> Hello all, Recently in the Haskell Foundation's stability working group we have been discussing various practical issues that Haskell users and prospective adopters encounter around the ecosystem. During these discussions the topic of GHC's release schedule and the ecosystem's process migration to new GHC releases has come up repeatedly. To address some of these issues, I have opened a pair of somewhat-related HF Tech Proposals: * the GHC.X.Hackage proposal ([ghc.x.hackage]) seeks to extend the [head.hackage] infrastructure used to test GHC to enable use by library maintainers in porting and testing their libraries on new GHC releases. * the [tick-tock] release proposal seeks to provide better guidance to users needing long release lifecycles by designating every other release as a "long-term support" release, with 18-month backport window. Given the wide applicability of these proposals we hope to gather feedback from a broad swath of the community. If you have questions, opinions, or concerns on either, please leave your feedback on the respective proposal. We look forward to hearing from you. Thanks! - Ben [ghc.x.hackage]: https://github.com/haskellfoundation/tech-proposals/pull/27 [head.hackage]: https://ghc.gitlab.haskell.org/head.hackage/ [tick-tock]: https://github.com/haskellfoundation/tech-proposals/pull/34 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From zubin at well-typed.com Fri May 27 19:31:48 2022 From: zubin at well-typed.com (Zubin Duggal) Date: Sat, 28 May 2022 01:01:48 +0530 Subject: [Haskell] [ANNOUNCE] GHC 9.2.3 released Message-ID: <20220527193148.xaj72eelctawugcm@zubin-msi> The GHC developers are very happy to at announce the availability of GHC 9.2.3. Binary distributions, source distributions, and documentation are available at [`downloads.haskell.org`](https://downloads.haskell.org/ghc/9.2.3). Download Page: https://www.haskell.org/ghc/download_ghc_9_2_3.html Blog Post: https://www.haskell.org/ghc/blog/20220527-ghc-9.2.3-released.html This release includes many bug-fixes and other improvements to 9.2.2 including: * A fix to a critical linking bug on Windows causing the 9.2.2 release to be unusable (#21196). * Numerous bug fixes for regressions and other issues in the typechecker (#2147, #21515, #20582, #20820, #21130, #21479). * Correctness bugs in the code generator and compiler backends (#21396, #20959, #21465). * Packaging fixes on many platforms (#20760, #21487, #21402). * 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. We would like to thank Microsoft Azure, GitHub, IOG, 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 compiling, - Zubin [ticket]: https://gitlab.haskell.org/ghc/ghc/-/issues/new [release notes]: https://downloads.haskell.org/ghc/9.2.3/docs/html/users_guide/9.2.3-notes.html -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: not available URL: From steve.t.smith at gmail.com Fri May 27 22:14:04 2022 From: steve.t.smith at gmail.com (Steven Smith) Date: Fri, 27 May 2022 18:14:04 -0400 Subject: [Haskell] [ANNOUNCE] GHC 9.2.3 released In-Reply-To: <20220527193148.xaj72eelctawugcm@zubin-msi> References: <20220527193148.xaj72eelctawugcm@zubin-msi> Message-ID: FYI, gpg documentation is incorrect, should be your public key: http://pgp.mit.edu/pks/lookup?op=get&search=0x88b57fcf7db53b4db3bfa4b1588764fbe22d19c4 Thanks for the release! > $ gpg --import /opt/local/ports/lang/ghc/files/keyid-ffeb7ce81e16a36b3e2ded6f2de04d4e97db64ad.txt > gpg: key 2DE04D4E97DB64AD: 3 signatures not checked due to missing keys > gpg: key 2DE04D4E97DB64AD: public key "Benjamin Gamari " imported > gpg: Total number processed: 1 > gpg: imported: 1 > gpg: no ultimately trusted keys found > $ gpg --verify /opt/local/var/macports/distfiles/ghc/ghc-9.2.3-x86_64-apple-darwin.tar.xz.sig /opt/local/var/macports/distfiles/ghc/ghc-9.2.3-x86_64-apple-darwin.tar.xz > gpg: Signature made Fri May 27 12:03:10 2022 EDT > gpg: using RSA key 88B57FCF7DB53B4DB3BFA4B1588764FBE22D19C4 > gpg: Can't check signature: No public key > On May 27, 2022, at 3:31 PM, Zubin Duggal wrote: > > https://www.haskell.org/ghc/download_ghc_9_2_3.html -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3898 bytes Desc: not available URL: From george.colpitts at gmail.com Fri May 27 23:07:10 2022 From: george.colpitts at gmail.com (George Colpitts) Date: Fri, 27 May 2022 20:07:10 -0300 Subject: [Haskell] [ANNOUNCE] GHC 9.2.3 released In-Reply-To: <20220527193148.xaj72eelctawugcm@zubin-msi> References: <20220527193148.xaj72eelctawugcm@zubin-msi> Message-ID: Hi https://gitlab.haskell.org/ghc/ghc/-/issues/21506, ghc-9.4.1-alpha1 does not install on macos, exists on 9.2.3 also. The workaround given in 21506 works. Do you want a ticket for this? Thanks George On Fri, May 27, 2022 at 4:41 PM Zubin Duggal wrote: > > The GHC developers are very happy to at announce the availability of GHC > 9.2.3. Binary distributions, source distributions, and documentation are > available at [`downloads.haskell.org`]( > https://downloads.haskell.org/ghc/9.2.3). > > Download Page: https://www.haskell.org/ghc/download_ghc_9_2_3.html > Blog Post: > https://www.haskell.org/ghc/blog/20220527-ghc-9.2.3-released.html > > This release includes many bug-fixes and other improvements to 9.2.2 > including: > > * A fix to a critical linking bug on Windows causing the 9.2.2 release > to be unusable (#21196). > > * Numerous bug fixes for regressions and other issues in the > typechecker (#2147, #21515, #20582, #20820, #21130, #21479). > > * Correctness bugs in the code generator and compiler backends (#21396, > #20959, #21465). > > * Packaging fixes on many platforms (#20760, #21487, #21402). > > * 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. > > We would like to thank Microsoft Azure, GitHub, IOG, 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 compiling, > > - Zubin > > > [ticket]: https://gitlab.haskell.org/ghc/ghc/-/issues/new > [release notes]: > https://downloads.haskell.org/ghc/9.2.3/docs/html/users_guide/9.2.3-notes.html > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > -------------- next part -------------- An HTML attachment was scrubbed... URL: