- ghc-devs - Haskell.org

GHC Steering Committee Call for Nominations
by Adam Gundry 28 Jan '24

28 Jan '24

Dear Haskellers, The GHC Steering Committee is seeking nominations for new members. The committee scrutinizes, debates and eventually decides to accept or reject proposals to change the language or major features supported by GHC. Our processes are described in the GitHub repository where proposals are submitted (https://github.com/ghc-proposals/ghc-proposals) In particular, please have a look at the committee bylaws (https://github.com/ghc-proposals/ghc-proposals/blob/master/committee.rst) We are looking for members who have the ability to: - understand GHC proposals (e.g. for new language extensions), - find holes and missing corner cases in the specifications, - foresee the interaction with other language or compiler features, - comment constructively and improve proposals through engagement with others, - judge the cost/benefit ratio of changes, and - come to a justifiable conclusion. Ideally, committee members should: - have substantial experience of writing or teaching Haskell; - have a track record of active contributions to the Haskell community; or - have expertise in language design and implementation, in either Haskell or related languages. It is our aim that this committee be diverse; by representing different viewpoints, we will make decisions that benefit larger segments of our community. Even if you are uncertain whether your background qualifies you for the role, you are warmly encouraged to apply. The committee's work requires a small, but non-trivial amount of time, especially when you are assigned a proposal for shepherding. We estimate the workload to be around 2 hours per week, and our process works best if members usually respond to technical emails within 1-2 weeks (within days is even better). Please keep that in mind if your email inbox is already overflowing. To nominate yourself, please send an email to me (as the committee secretary) at adam(a)well-typed.com by February 16th 2024, briefly summarising your background and relevant experience. I will distribute the nominations among the committee, and we will keep the nominations and our deliberations private. Self-nominations are the norm. You can nominate someone else, but please obtain their explicit consent to do so. (We don't want to choose someone who turns out to be unable to serve.) On behalf of the committee, Adam Gundry -- Adam Gundry, Haskell Consultant Well-Typed LLP, https://www.well-typed.com/ Registered in England & Wales, OC335890 27 Old Gloucester Street, London WC1N 3AX, England

1 0

How to disable the simple optimizer
by Facundo Domínguez 26 Jan '24

26 Jan '24

Dear devs, I noticed that GHC sometimes inlines bindings during desugaring, e.g foo = z where z = z1 + z2 z1 = 42 z2 = 1 is desugared to foo = 42 + 1 This inlining is problematic when using a plugin like Liquid Haskell, which wants to analyse in Core the local bindings provided by the user. Until ghc-9.6 LH didn't experience the inlining when using the GHC API. And this is despite the fact that using ghc from the command line would seem to always inline during desugaring, even when using -O0. When using ghc-9.8.1 though, even the output of the GHC API started having the bindings inlined. Some debugging with -ddump-ds and -ddump-ds-preopt shows that inlining must be happening in the simple optimizer. Is there anything one could do to disable the optimizations? Thanks in advance, Facundo -- All views and opinions expressed in this email message are the personal opinions of the author and do not represent those of the organization or its customers.

3 3

Help needed with optimization
by Tom Ellis 24 Jan '24

24 Jan '24

Hello GHC devs, I'm trying to understand why my code is not being optimized in the way I would expect. I'm completely stuck and I think I need the advice of an expert. I'm writing an effect system on top of transformers. The effect system wraps monad transformers in a newtype that encodes the composition structure of the transformers at the type level. Because it's a newtype all of the class members are inherited directly from the underlying type using coerce. When I implement something using this effect system I would expect to generate exactly the same code as if I had written it using transformers directly. However, it generates significantly worse code, even in a very simple case. Firstly, a case where I do get the same code. All of these compile to the constant 1. Hooray! https://github.com/tomjaguarpaw/ad/blob/cd0d876ddb448fe611515e8768dee66dc02… Secondly, a simple cases where I do not get the same code. `mySumMTL` and `mySumNewtype` yield the same code, as expected. After all, `mySumNewtype` does exactly the same thing as `mySumMTL`, it's just wrapped in some newtypes. However, `mySumEff` yields worse code, despite *also* being the same thing as `mySumMTL` just wrapped in some newtypes. https://github.com/tomjaguarpaw/ad/blob/cd0d876ddb448fe611515e8768dee66dc02… You can compare the generated loops at: https://github.com/tomjaguarpaw/ad/blob/cd0d876ddb448fe611515e8768dee66dc02… Does anyone have a clue what's going wrong in the optimizer here? I don't think the singleton that I pass around to access the type level index at runtime has anything to do with it. That seems to be optimized away by inlining. Is the simplifier confused by all the coercions? Thanks for any help anyone may be able to shed, Tom

2 2

Google Summer of Code Ideas
by Aaron Allen 24 Jan '24

24 Jan '24

Hello, Haskell will be applying for the Google Summer of Code 2024 program and it would be great to have some project ideas involving GHC. If anything comes to mind, you can submit an idea proposal using the instructions found here: https://summer.haskell.org/ideas.html. Kind Regards, Aaron

1 0

GHC Weekly call
by Simon Peyton Jones 23 Jan '24

23 Jan '24

Dear GHC developers Every week (2pm London time, Tuesdays) we hold a call for people to share what they are working on GHC-land. Would you like to come? The call is open to *any member of the GHC Team. *And *the GHC Team is inclusive*: if you are working on GHC you are a member of the Team: see here for details <https://gitlab.haskell.org/ghc/ghc-hq#2-the-ghc-team>. Why come? - It gives you a window into what is happening in GHC land - It gives you a chance to influence what is happening - It builds community -- you get face-to-face contact with others working on GHC If you'd like to come, drop a line to Matthew Pickering matthew(a)well-typed.com See you there! Simon

1 0

Do you use stack to build hadrian?
by Bryan Richter 19 Jan '24

19 Jan '24

If nobody uses stack to build hadrian, (or even if a few people do), there's talk of removing that option because very few people do use it. Feel free to weigh in at https://gitlab.haskell.org/ghc/ghc/-/issues/24274#note_541913 -Bryan

1 0

Nofib patch
by Simon Peyton Jones 11 Jan '24

11 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 18 Dec '23

18 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