February 2021 - ghc-devs

cep_app traces
by Simon Peyton Jones 15 Feb '21

15 Feb '21

Ben I'm getting a lot of cpe_app(keepAlive#) 3 cpe_app(keepAlive) trace messages from HEAD. Maybe it's a leftover from tracing when you were developing? Remove? Simon

2 1

gitlab.haskell.org certificate expired?
by Richard Eisenberg 15 Feb '21

15 Feb '21

Hi Ben, It looks like the Let's Encrypt certificate for gitlab.haskell.org <http://gitlab.haskell.org/> has expired, as of about 15 minutes ago. I guess it's time to renew. Thanks, Richard

5 4

Slowing down churn in master prior to 9.2 freeze
by Ben Gamari 13 Feb '21

13 Feb '21

Hi all, Since we are in the final weeks of preparation before the 9.2 branch it would be appreciated if we could refrain from pushing work that isn't either a bug-fix or release-critical feature starting next week, especially where the work requires coordination across submodules. At the moment we have quite a backlog in the merge queue, with a number of dependent patches touching submodules. Consequently, I am a tad worried that the three weeks of runway that we currently have may prove to be insufficient unless we try to keep the merge traffic down. I suggest that we set the milestone of non-release-critical patches to %9.4.1 instead of assigning @marge-bot to allow merging to easily proceed after the branch is cut. Cheers, - Ben

1 0

Boot libraries for GHC 9.2
by Ben Gamari 12 Feb '21

12 Feb '21

Hi all, I am currently in the process of planning out the GHC 9.2 release. As you know, part of this process is working out which core library versions we will ship. My current plan is the following: package maintainer version --------------- ------------------ ----------------- Cabal Mikhail Glushenkov 3.6.0.0 Win32 Tamar Christina 2.10.0.0 array GHC HQ 0.5.3.0 binary Lennart Kolmodin 0.8.7.0 bytestring Andrew Lelechenko 0.11.0.0 (see GHC #19091) containers David Feuer/CLC? 0.6.4.1 deepseq CLC 1.4.4.0 directory CLC 1.3.6.1 exceptions Ed Kmett 0.10.4 filepath Neil Mitchell? 1.4.2.1 haddock Hécate ? haskeline Judah Jacobson 0.8.1.0 hsc2hs GHC HQ 0.68.7 mtl Ed Kmett 2.2.2 parsec Herbert Valerio Reidel 3.1.14 pretty David Terei? 1.1.3.6 process Michael Snoyman 1.6.10.0 stm GHC HQ 2.5.0.0 terminfo Judah Jacobson 0.4.1.4 text CLC 1.2.4.0 time Ashley Yakeley 1.11.1 transformers Ross Paterson 0.5.6.2 unix Andrew Lelechenko 2.8.0.0? xhtml Chris Dornan 3000.2.2.1 If you disagree with this plan or see a question mark next to a library that you are responsible for, please do be in touch. Cheers, - Ben

1 0

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

12 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