- ghc-devs - Haskell.org

Nofib patch
by Simon Peyton Jones 12 Jan '24

12 Jan '24

Friends I have forgotten the workflow for adding a patch to nofib. The patch is below. (Trivial). Could someone apply it (and update GHC head to use it). Or tell me how to do it. Or both! Thanks Simon This patch makes 'veritas' stop using 'forall' as a function name. Reason: 'forall' is now a keyword diff --git a/real/veritas/Kernel.hs b/real/veritas/Kernel.hs index b1c69ef..2c491a7 100644 --- a/real/veritas/Kernel.hs +++ b/real/veritas/Kernel.hs @@ -384,7 +384,7 @@ constructor (SG sg) i j k {- Datatype elimination -} recurse tmL (TM (tm@(Binder Pi (Symbol_dec tm1 _) _ _ _)) _ sg) - = if forall ok (zip tmL tyL) + = if vforall ok (zip tmL tyL) then TM (Recurse (map fst tmL) tm [] []) tm sg else @@ -570,7 +570,7 @@ def (TM tm1 tm2 sg) make_data tmLL (TH tm sg) - = if forall (forall (wf_param sg1)) tmLL + = if vforall (vforall (wf_param sg1)) tmLL then if exists (eq_trm tm) non_empty_thms then diff --git a/real/veritas/Main.hs b/real/veritas/Main.hs index c0ed8e3..5191a67 100644 --- a/real/veritas/Main.hs +++ b/real/veritas/Main.hs @@ -107,7 +107,7 @@ goto_next tr@(TreeSt t _ _) incomplete_tree (Tree _ tl (SOME _) _ _ ) = False -incomplete_tree (Tree _ tl NONE _ _ ) = forall is_complete tl +incomplete_tree (Tree _ tl NONE _ _ ) = vforall is_complete tl diff --git a/real/veritas/Sub_Core3.hs b/real/veritas/Sub_Core3.hs index f6fd733..12c2987 100644 --- a/real/veritas/Sub_Core3.hs +++ b/real/veritas/Sub_Core3.hs @@ -248,7 +248,7 @@ eval (Constant F _ _) = False --eval (Constant _ _ _) = error "EvalError" -- ** exn eval (Binder Forall dc tm _ _) - = eval_quant forall dc tm + = eval_quant vforall dc tm eval (Binder Exists dc tm _ _) = eval_quant exists dc tm diff --git a/real/veritas/Vtslib.hs b/real/veritas/Vtslib.hs index 9a6c0fe..9ae06ab 100644 --- a/real/veritas/Vtslib.hs +++ b/real/veritas/Vtslib.hs @@ -1,4 +1,4 @@ -module Vtslib( Option(..) , Sum(..) , forall , exists , assoc , +module Vtslib( Option(..) , Sum(..) , vforall , exists , assoc , haskey , uncurry , curry , for , map' , module Core_datatype ) where @@ -14,9 +14,9 @@ data Sum a b = Inl a | Inr b N.B. forall & exists rewritten from ML -} -forall :: ( a -> Bool ) -> [a] -> Bool +vforall :: ( a -> Bool ) -> [a] -> Bool -forall p = and . ( map p ) +vforall p = and . ( map p )

1 0

Upcoming GHC 9.4.8 release
by Zubin Duggal 10 Jan '24

10 Jan '24

Hi all, We hope to prepare the 9.4.8 release in the coming weeks. This will likely be the final release in the 9.4 series. The major patches currently slated for inclusion into the 9.4.8 are: 1. A process submodule bump to 1.6.17.0 avoiding segfaults on Darwin (https://github.com/haskell/process/issues/295) 2. A fix for a recompilation checking bug where GHC may miss changes in transitive dependencies when deciding to relink a program (https://gitlab.haskell.org/ghc/ghc/-/merge_requests/11178) 3. A fix for a packaging bug so that we can ensure all released binaries and bundled libraries are built with `-split-sections` enabled (https://gitlab.haskell.org/ghc/ghc/-/merge_requests/9492) If you would like any patches to be considered for inclusion in this release please ensure that the corresponding Merge Requests are marked with the ~"backport needed:9.4" by **the end of this week**. Please note that we will be quite conservative with the changes we accept for this branch at this point in its lifecycle. The current set of all MRs being considered for inclusion can be viewed at https://gitlab.haskell.org/ghc/ghc/-/merge_requests?scope=all&state=all&lab… Thanks, Zubin

2 4

[ANNOUNCE] GHC 9.6.4 is now available
by Zubin Duggal 09 Jan '24

09 Jan '24

The GHC developers are happy to announce the availability of GHC 9.6.4. Binary distributions, source distributions, and documentation are available on the [release page](https://www.haskell.org/ghc/download_ghc_9_6_4.html). This release is primarily a bugfix release addressing a few issues found in the 9.6 series. These include: * A fix for a bug where certain warnings flags were not recognised (#24071) * Fixes for a number of simplifier bugs (#23952, #23862). * Fixes for compiler panics with certain package databases involving unusable units and module reexports (#21097, #16996, #11050). * A fix for a typechecker crash (#24083). * A fix for a code generator bug on AArch64 platforms resulting in invalid conditional jumps (#23746). * Fixes for some memory leaks in GHCi (#24107, #24118) * And a few other fixes A full accounting of changes can be found in the [release notes]. 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, Well-Typed, Tweag I/O, Serokell, Equinix, SimSpace, Haskell Foundation, 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 hacking! -Zubin [ticket]: https://gitlab.haskell.org/ghc/ghc/-/issues/new [release notes]: https://downloads.haskell.org/~ghc/9.6.4/docs/users_guide/9.6.4-notes.html

1 0

STG register mapping
by DashiellWill 19 Dec '23

19 Dec '23

Hi all, I'm newbie at GHC, trying to read the source code and understand the design of GHC. Now I'm learning about the Haskell Execution Model, but now I'm a bit confused about the STG-machine Registers. First, as shown in the GHC wiki e.g. https://gitlab.haskell.org/ghc/ghc/-/wikis/commentary/rts/haskell-execution… , the STG-machine has some virtual registers that are mapped to real registers, such as Base, Sp, SpLim, Hp, Rn, Fn and Dn, but unfortunately the mapping logic of the STG registers is not explained in detail here. Then I tried to read the source files of various platforms in rts/include/stg/MachRegs. At first I thought they were mapped using the callee saved registers, such as aarch64, ppc, loongarch64 and riscv64 platforms, but this seems broken on s390x and x86_64 platforms. so now I have two questions: 1. What determines the amounts of Rn, Fn and Dn for different platforms? As for Rn, aarch64 has 6 registers, loongarch64 has 5 registers, ppc has 10 registers, and riscv64 has 7 registers. As for Fn, both aarch64 and loongarch64 have 4 registers, and both ppc and riscv64 have 6 registers. 2. What is the basic rule to assign the actual processor registers to the STG machine registers? The aarch64, loongarch64, ppc and riscv64 platforms seem to have a 'normal' mapping, while the s390x and x86_64 platforms have an 'non-normal' mapping e.g. R4~R8, F5~F6 and D5~D6 in s390x use the caller saved registers. Does this mean that the caller saved registers for passing argument can be used for mapping when the callee saved registers are insufficient? Thanks, Dashiell

2 1

How is account sign-up supposed to work?
by Tom Ellis 12 Dec '23

12 Dec '23

Hello GHC devs, It is hard for new users to understand how to get their new Gitlab accounts approved by an administrator. See, for example, these messages, both in the last ten days: * https://discourse.haskell.org/t/why-isalpha-can-parse-some-non-alphabetic-u… * https://old.reddit.com/r/haskell/comments/18ge6vj/access_to_ghc_gitlab_for_… The Wiki doesn't seem to provide any guidance in the "Contributing" or "Newcomers" sections. Nor does ghc.dev. Perhaps that's understandable; GHC is not the Gitlab instance. * https://gitlab.haskell.org/ghc/ghc/-/wikis/contributing * https://gitlab.haskell.org/ghc/ghc/-/wikis/contributing#newcomers-to-ghc * https://ghc.dev/ So how is a new user supposed to know how to get their accounts approved? It would be nice to make the process super clear. This is a longstanding issue. Tom

3 3

Build GHC in GHC2021
by Arnaud Spiwack 11 Dec '23

11 Dec '23

Dear GHC devs, Year 2024 is upon us. GHC2021 was released 2 years ago, in GHC 9.2. I think it's time for the base language for GHC to be GHC2021. What do we think? PS: I don't actually know where the base language for GHC is specified. I couldn't find it with a cursory search PPS: if someone makes an MR, bonus points for clearing up hundreds of lines of now-unnecessary extension on top of files. -- Arnaud Spiwack Director, Research at https://moduscreate.com and https://tweag.io.

5 6

"Merge-buddy" response
by Alan & Kim Zimmerman 05 Dec '23

05 Dec '23

Hi all If you recall I asked a while back for people to help me get my exact print annotation re-work stack merged. I had a number of people step up to offer their help (Brandon Allbery, Zubin Duggal, Ben Gamari and Alexandre Baldé). Of these, Brandon Allbery really stepped up to the plate. We got into a daily rhythm and have now landed 37 Merge Requests, completing my initial rework. Thank you very much. There has been further discussion of next steps at https://gitlab.haskell.org/ghc/ghc/-/issues/23447, and I will be starting on the further simplification we have discussed there. Thanks again all. Alan

1 0

Annotating instances
by Jaro Reinders 04 Dec '23

04 Dec '23

Hi GHC devs, I'm working on a GHC plugin which implements a custom instance resolution mechanism: https://github.com/noughtmare/transitive-constraint-plugin Currently, I need to place instances in a specific order in a specific file to recognize them and use them in my plugin. I think my life would be a lot easier if I could put annotations on instances. I imagine a syntax like this: data MyInstanceTypes = Refl | Trans deriving Eq class f <= g where inj :: f x -> g x instance {-# ANN instance Refl #-} f <= f where inj = id instance {-# ANN instance Trans #-} forall f g h. (f <= g, g <= h) => f <= h where inj = inj @g @h . inj @f @g Using this information I should be able to find the right instances in a more reliable way. One more thing I was thinking about is to make it possible to remove these instances from the normal resolution algorithm and only allow them to be used by my plugin. Do you think this would be easy to implement and useful? Or are there other ways to achieve this? Cheers, Jaro

3 7

Problems building cabal-install?
by Viktor Dukhovni 26 Nov '23

26 Nov '23

I am having a rather unexpected difficulty building older versions of cabal-install. The invariably run into conflicts between "Cabal" and "Cabal-syntax". The latter shows up as a dependency of "Cabal" on hackage, but not in the upstream Git repo. Is there is there some sort of problem with the hackage metadata for Cabal 3.0, 3.2, 3.4, ... It is odd for these to have "Cabal-syntax 3.10.*" as a dependency, with conflicting definitions. -- Viktor.

2 6

Upcoming GHC 9.6.4 release
by Zubin Duggal 24 Nov '23

24 Nov '23

Hi all, We are planning a release in the 9.6 series before Christmas, with a preliminary ETA of 15th December. Release tracking ticket: https://gitlab.haskell.org/ghc/ghc/-/issues/24017 Please use this ticket to request any submodule bumps or for any other discussion related to the release. If you would like any patches to be considered for inclusion in this release please ensure that the corresponding Merge Requests are marked with the ~"backport needed:9.6" label. The current set of all MRs being considered for inclusion can be viewed at https://gitlab.haskell.org/ghc/ghc/-/merge_requests?scope=all&state=all&lab… Cheers, Zubin

2 3