- ghc-devs - Haskell.org

Re: Plan for GHC 9.2
by Roland Senn 11 Feb '21

11 Feb '21

I hope ticket #19157 will make it in the GHC 9.2 release. In the GHCi debugger it adds the possibility to set ignore counts to breakpoints. The next <count> times the break point is reached the program's execution does not stop. This feature is available in nearly every debugger, but until now not yet in the GHCi debugger. Merge request !4839 is ready for review (and it's NOT rocket science...)

4 4

Stop holding hadrian back with backwards compatibility
by Moritz Angermann 11 Feb '21

11 Feb '21

Hi, so we've finally run into a case where we need to bump the rts version. This has a great ripple effect. There is some implicit assumption that rts-1.0 will always be true. Of course that was a lie, but a lie we lived with for a long time. Now, hadrian tries *really* hard to replicate some of the Make based build systems idiosyncrasies, this includes creating versionless symlinks for the rts. E.g. libHSrts<X> -> libHSrts-1.0<X>. There is a great deal of logic just to achieve this, and of course it all crumbles now. I'd therefore like to float and propose the idea that we agree to *not* bother (too?) much with make based build systems backwards compatibility and warts that grew over the years in the make based build system with hadrian going forward. Yes, I can probably fix this, and add even more code to this burning pile of complexity, but why? The next person will assume libHSrts does not need to be versioned and continue with this mess. Let's have Hadrian be a clean cut in some areas (it already is, it does away with the horrible abomination that ghc-cabal is--which only serves the purpose of translating cabal descriptions into make readable files), and not be bogged down by backwards compatibility. This is thus my call for voicing concern or the upkeep of legacy support, or I'll take silence as the collective support of making hadrian *not* be held back by backwards compatibility. (This would mean in this case, that I'd just delete the backwards compat code instead of adding even more to it). I hope we all still want Hadrian to replace Make, if not and we want to keep Make, why are we concerning ourselves with Hadrian in the first place. If we are intending to ditch Make, let's not be held back by it. Cheers, Moritz

4 6

Newtype over (~#)
by Igor Popov 10 Feb '21

10 Feb '21

Hello list! Recently I've had this idea of letting Haskell source handle unboxed equalities (~#) by the means of an unboxed newtype. The idea is pretty straightforward: in Core Constraint is Type and (=>) is (->), so a datatype like data Eq a b = (a ~ b) => Refl could become a newtype because it only has a single "field": (a ~ b). Furthermore now that we have unlifted newtypes, we could write it as a newtype over (~#), of kind TYPE (TupleRep []). Defining such a datatype is of course impossible in source Haskell, but what I came up with is declaring a plugin that magically injects the necessary bits into the interface file. Sounds like it should be straightforward: define a newtype (:~:#) with a constructor whose representation type is: forall k (a :: k) (b :: k). (a ~# b) -> a :~:# b The worker constructor is implemented by a coercion (can even be eta-reduced): axiom N::~:# :: forall {k}. (:~:#) = (~#) Refl# = \ (@ k) (@ (a :: k)) (@ (b :: k)) (v :: a ~# b) -> v `cast` (Sym (N::~:#) <k>_N) <a>_N _N And the wrapper constructor has a Haskell-ish type: $WRefl# :: forall k (b :: k). b :~:# b $WRefl# = \ (@ k) (@ (b :: k)) -> Refl# @ k @ a @ b @~ _N Caveat: we don't actually get to specify the unwrappings ourselves, and we have to rely on mkDataConRep generating the right wrapper based on the types and the EqSpec (because this will have to be done every time the constructor is loaded from an iface). In this case the machinery is not convinced that a wrapper is required, unless we ensure that dataConUserTyVarsArePermuted by fiddling around with ordering of variables. This is a minor issue (which I think I can work around) but could be addressed on the GHC side. I've indeed implemented a plugin that declares these, but we run into a more major issue: the simplifier is not ready for such code! Consider a simple utility function: sym# :: a :~:# b -> b :~:# a sym# Refl# = Refl# This gets compiled into: sym# = \ (@ k) (@ (a :: k)) (@ (b :: k)) (ds :: a :~:# b) -> case ds `cast` N::~:# <k>_N <a>_N _N of co -> $WRefl# @ k @ b `cast` ((:~:#) <k>_N (Sym co))_R which seems valid but then the simplifier incorrectly inlines the unfolding of $WRefl# and arrives at code that is not even well-scoped (-dcore-lint catches this): sym# = \ (@ k) (@ (a :: k)) (@ (b :: k)) (ds :: a :~:# b) -> case ds `cast` N::~:# <k>_N <a>_N _N of co -> v `cast` (Sym (N::~: <k>_N)) _N _N ; ((:~:#) <k>_N _N (Sym co))_R Actually the problem manifests itself even earlier: when creating an unfolding for the wrapper constructor with mkCompulsoryUnfolding we run the unfolding term through simpleOptExpr once before memorizing the unfolding, and this produces an unfolding for $WRefl# that is broken (ill-scoped) in a similar fashion: $WRefl = \ (@ k) (@ (b :: k)) -> v `cast` Sym (N::~:# <k>_N) _N _N And we can verify that the issue is localized here: applying simpleOptExpr to: (\ (v :: a ~# a) -> v `cast` <a ~# a>_R) @~ <a>_N results in: v The former term is closed and the latter is not. There is an invariant on mkPrimEqPred (though oddly not on mkReprPrimEqPred) that says that the related types must not be coercions (we're kind of violating this here). I have several questions here: - Is there a good reason for the restriction that equalities should not contain other equalities? - Should this use case be supported? Coercions are almost first class citizens in Core (are they?), makes sense to let source Haskell have a bit of that? - Does it make sense to include this and a few similar types (unboxed Coercion and Dict) as a wired in type packaged with GHC in some form? -- mniip

3 6

Find the ghc binary path from libdir
by Fendor 10 Feb '21

10 Feb '21

Hello everyone! I want to find out the location of the `ghc` (and `ghc-pkg`) executable given the `$libdir` (obtained by `ghc --print-libdir`). Is there a platform independent way of doing that, which we can rely on? E.g. on windows, we found that the ghc executable's location is: * `$libdir/../bin/ghc` For NixOs (or when using ghcup), it works with: * `$libdir/../../bin/ghc` but I worry that this is a just an accident that is not guaranteed by the installation process. I also noticed there seems to be a binary in * `$libdir/bin/ghc` Is one of these ways documented to be guaranteed by the ghc installation process? (P. S. first time using a mailing list, hope I am doing it correctly) Best regards, Fendor

3 4

[ANNOUNCE] GHC 8.10.4 released
by Ben Gamari 10 Feb '21

10 Feb '21

The GHC team is very pleased to announce the availability of GHC 8.10.4. Source and binary distributions are available at the usual place: https://downloads.haskell.org/ghc/8.10.4/ This is a small bug-fix release, fixing two bugs present in 8.10.3: * Fix a linker hang triggered by dynamic code loading on Windows (#19155) * Fix a crash caused by inappropriate garbage of heap-allocated data reachable from foreign exports (#19149) As always, feel free to report any issues you encounter via [gitlab.haskell.org](https://gitlab.haskell.org/ghc/ghc/-/issues/new). Cheers, - Ben

2 1

Re: Plan for GHC 9.2
by Andrzej Rybczak 09 Feb '21

09 Feb '21

Hey Ben, It would be excellent to get NoFieldSelectors extension (https://gitlab.haskell.org/ghc/ghc/-/merge_requests/4743) in. IIUC it's almost ready to be merged.

1 0

Has ghc-9.0 for windows changed to require installation?
by Takenobu Tani 09 Feb '21

09 Feb '21

Hi devs, The ghc-binary for windows needs to `make install` since ghc-9.0 [1]. Is this an intended change? Previously, ghc-8.10.4 binary for windows [2] doesn't need to `make install`. We only expand the tar-file and then we can execute `bin/ghcii.sh`. [1]: https://downloads.haskell.org/ghc/9.0.1/ghc-9.0.1-x86_64-unknown-mingw32.ta… [2]: https://downloads.haskell.org/ghc/8.10.4/ghc-8.10.4-x86_64-unknown-mingw32.… Regards, Takenobu

3 3

[ANNOUNCE] GHC 9.0.1 released
by Ben Gamari 09 Feb '21

09 Feb '21

The GHC team is very pleased to announce the availability of GHC 9.0.1. Source and binary distributions are available at the usual place: https://downloads.haskell.org/ghc/9.0.1/ In addition to numerous bug fixes, GHC 9.0.1 will bring a number of new features: * A first cut of the new LinearTypes language extension [2], allowing use of linear function syntax and linear record fields. * A new bignum library, ghc-bignum, improving portability and allowing GHC to be more easily used with integer libraries other than GMP. * Improvements in code generation, resulting in considerable runtime performance improvements in some programs. * Improvements in pattern-match checking, allowing more precise detection of redundant cases and reduced compilation time. * Implementation of the "simplified subsumption" proposal [3] simplifying the type system and paving the way for QuickLook impredicativity in GHC 9.2. * Implementation of the QualifiedDo extension [4], allowing more convenient overloading of `do` syntax. * An experimental new IO manager implementation for Windows platforms, both improving performance and fixing many of the quirks with the old manager built on POSIX-emulation. * Improvements in compilation time. And many more. See the release notes [5] for a full accounting of the changes in this release. As always, feel free to report any issues you encounter via gitlab.haskell.org. Cheers, - Ben [1]: https://gitlab.haskell.org/ghc/ghc/-/wikis/migration/9.0#ghc-prim-07 [2]: https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0111-l… [3]: https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0287-s… [4]: https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0216-q… [5]: https://downloads.haskell.org/ghc/9.0.1/docs/html/users_guide/9.0.1-notes.h…

3 4

Reduction in Windows CI capacity
by Ben Gamari 08 Feb '21

08 Feb '21

tl;dr. GHC's CI capacity will be a reduced due to a loss of sponsorship, particularly in Windows runner capacity. Help wanted in finding additional capacity. Hi all, For many years Google X has generously donated Google Compute Engine resources to GHC's CI infrastructure. We all owe a debt of gratitude to Google X for providing us with what has undoubtedly amounted to tens of thousands of dollars of computational capacity over the years. I would especially like to thank Greg Steuck, whose advocacy made this donation possible. Of course, organizational priorities understandably change and Google X will be unable to continue their sponsorship in the future. This puts us in a bit of a tricky situation; Google Compute Engine is currently the home of nearly 100 cores worth of CI capacity, including: * roughly 20% of our x86-64/Linux capacity * our only x86-64/FreeBSD runner * all five of our x86-64 Windows runners While the Linux runners are fairly easy to replace, the Windows capacity is a bit harder since Windows cloud capacity is quite expensive (IIRC nearly half of the cost of our Windows GCE instances is put towards the license). In the short term I can cover for some of this lost capacity by bringing up a Windows runner using our generous donation from Packet [1]. However, I am extrmely wary of outspending our welcome on Packet's infrastructure and therefore we will need to accept a small reduction in capacity for a bit while we work out a more sustainable path forward. We will have to see how things go but it may be necessary to disable the Windows jobs on (non-Marge) merge request validation pipelines. I am looking into various options for again reaching our previous capacity, but this is an area where you might be able to help: * Familiarity with Windows licensing. Unfortunately the details of Windows licensing for virtualization purposes are a bit tricky. I suspect that the cheapest way forward is a single Windows Server license on a large machine but if you are familiar with Windows licensing in this setting, please do be in touch. * Providing Windows licenses. If you know of an organization that may be able to donate Windows licenses either in-kind or via financial support, please do be in touch. * Providing Windows cloud instances. If you know of an organization that may be able to donate Windows cloud instances, do holler. As always, we welcome any hardware or cloud instance contributions. Do be in touch if you may be in an position to help out. Cheers, - Ben [1] https://www.packet.com/

1 0

remAddr# primop inconsistency
by Csaba Hruska 06 Feb '21

06 Feb '21

Hello, I've discovered that the remAddr# primop documentation is inconsistent with the implementation. According to the docs (primops.txt.pp) the remAddr# should be the same as remInt#. > primop AddrRemOp "remAddr#" GenPrimOp Addr# -> Int# -> Int# {Return the remainder when the {\tt Addr\#} arg, treated like an {\tt Int\#}, is divided by the {\tt Int\#} arg.} > > But it is implemented with the mo_wordURem instruction, just like the WordRemOp primop. > GHC/StgToCmm/Prim.hs: > AddrRemOp -> \args -> opTranslate args (mo_wordURem platform) > WordRemOp -> \args -> opTranslate args (mo_wordURem platform) > IntRemOp -> \args -> opTranslate args (mo_wordSRem platform) > Which one is correct, the docs or the implementation? Regards, Csaba Hruska

2 2