- ghc-devs - Haskell.org

Our ambitions for GHC 9.6
by Hécate 03 May '22

03 May '22

Hi everyone, With 9.4 just around the corner, I am gathering broad ambitions for user-facing improvements that we wish to ship for GHC 9.6. At this moment, the new JavaScript and WebAssembly backends have been listed, but I'd be very interested to add more content. This document is especially for public communication regarding our activities. Since these are ambitions, it's not a hard deadline, nor does it imply dreadful consequences for the people who didn't manage to have their improvements shipped in time. I'm really excited for 9.4 and all the good stuff we're going to have in the future of GHC! Cheers, Hécate. -- Hécate ✨ 🐦: @TechnoEmpress IRC: Hecate WWW: https://glitchbra.in RUN: BSD

1 1

Extending call_args when specialising DFuns
by ÉRDI Gergő 02 May '22

02 May '22

Hi, In GHC.Core.Opt.Specialise.specCalls, when specialising a DFun call, GHC extends the call_args with dummy UnspecArg elements, to make it trivially fully saturated. There's a Note describing this behaviour: """ Note [Specialising DFuns] ~~~~~~~~~~~~~~~~~~~~~~~~~ DFuns have a special sort of unfolding (DFunUnfolding), and these are hard to specialise a DFunUnfolding to give another DFunUnfolding unless the DFun is fully applied (#18120). So, in the case of DFunIds we simply extend the CallKey with trailing UnspecArgs, so we'll generate a rule that completely saturates the DFun. There is an ASSERT that checks this, in the DFunUnfolding case of GHC.Core.Unfold.specUnfolding. """ (note that the reference in the second paragraph is stale; it should point to GHC.Core.Unfold.Make.specUnfolding) So my question is, why UnspecArgs instead of UnspecTypes? Unless I'm missing something, a DFun can't have any term parameters, only type and dictionary ones. Changing the padding from UnspecArg to UnspecType doesn't break validate, which suggests that it is hard to even exercise this code path. I'm bringing this up because on the GHC fork that I'm working on, I have the specializer do more than vanilla GHC: on my fork, specialization of higher-kinded type variables is just as useful as specializing dictionaries. With that change, I can get GHC panics when padding DFun calls with UnspecArgs, but not when padding with UnspecTypes. Yes, this is a very weak argument for this change; what I'm looking for here is a discussion on what the padding should be, in vanilla GHC, from first principles. Thanks, Gergo

2 2

GHC 9.4.1-alpha1 now available
by Ben Gamari 02 May '22

02 May '22

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-c… [ticket]: https://gitlab.haskell.org/ghc/ghc/-/issues/new

2 1

Documenting primtypes, round 1: ByteArray# and Array#
by Hécate 30 Apr '22

30 Apr '22

Hi everyone, With the sunny days back in this hemisphere, so do the documentation MRs. I have two primtypes for which I'd like some help / review / interesting information: * ByteArray#: This is mostly done, you can observe the current rendered draft documentation here: https://gitlab.haskell.org/ghc/ghc/-/merge_requests/8067#note_425560 Please note that the free-floating "Byte Arrays" section of documentation cannot be exported or re-exported by GHC.Exts, so we're pretty much left with what's in the types' documentation; * Array#: The ticket is here: https://gitlab.haskell.org/ghc/ghc/-/issues/21462 State of things: In terms of documentation, we have no documentation. Some stuff can be inferred from the SmallArray# haddocks but I doubt that every property / interesting usage / pitfall can be reasonable derived from putting ¬ at the beginning of the SmallArray# documentation. Now, on an unrelated note, I'm also wondering about the fate of GHC.Pack, for a number of reasons. You will find the ticket here: https://gitlab.haskell.org/ghc/ghc/-/issues/21461. My thanks to everyone who's helped me so far, with a special mention to bodigrim and koz ross. Cheers -- Hécate ✨ 🐦: @TechnoEmpress IRC: Hecate WWW: https://glitchbra.in RUN: BSD

1 0

How to coordinate Haddock MR with GHC MR?
by Norman Ramsey 19 Apr '22

19 Apr '22

GHC merge request !7442 changes the GHC API in a way that requires a one-line change in `utils/haddock`. What should I do with this? I can create an MR for the Haddock people, but I don't know how to mark it as something that should be applied at exactly the same time that Haddock transitions to GHC 9.6. Please advise. Norman

2 2

Seeking RTS experts to review delimited continuations MR
by Alexis King 18 Apr '22

18 Apr '22

Hi all, I have recently opened a draft MR with my initial implementation of first-class delimited continuations in the RTS, available here: https://gitlab.haskell.org/ghc/ghc/-/merge_requests/7942 The MR is not entirely finished—it still requires docs and tests, which I am gradually working on. However, barring any bugs I discover after writing those tests, I believe the implementation itself is feature-complete with respect to the proposal. Given that it is a nontrivial patch to a somewhat unloved portion of GHC, and given that there are a couple questions I have about how best to go about testing certain interactions in the first place, I figured I would reach out and see if anyone particularly familiar with the guts of the RTS would be willing to volunteer some time to give it a careful look. The good news is that the patch is not actually very large, and it changes very little existing code: the diffstats currently sit at +1,078 -48. For those interested in taking a look at the patch, I recommend starting with the Notes mentioned in the MR description. I suspect they may be a bit sparse at the moment, so please do not hesitate to ask questions; I will do my best to respond promptly. Many thanks, Alexis

3 2

Haskell.org outage
by Ben Gamari 18 Apr '22

18 Apr '22

Hello everyone, Unfortunately Haskell.org, downloads.haskell.org, and hoogle.haskell.org are currently down. We are currently investigating the cause. Updates will be posted as they are available. Cheers, - Ben

1 1

how to build Haddock documentation for a single module?
by Norman Ramsey 15 Apr '22

15 Apr '22

I'm fine-tuning the Haddock documentation for just one module that sits in the $GHC/compiler/GHC subtree. Is there a way I can get Hadrian to build the documentation for just that module? Norman

2 2

Markup language/convention for Notes?
by Sebastian Graf 14 Apr '22

14 Apr '22

Hi Devs, When writing Notes, I find myself using markdown-inspired or haddock-inspired features. The reason is that I keep telling myself > In 5 years time, we'll surely have an automated tool that renders Notes referenced under the cursor in a popup in our IDE And I might not be completely wrong about that, after all the strong conventions about Note declaration syntax allow me to do jump-to-definition on Note links in my IDE already (thanks to a shell script written by Zubin!). Still, over the years I kept drifting between markdown and haddock syntax, sometimes used `backticked inline code` or haddock 'ticks' to refer to functions in the compiler (sometimes even 'GHC.Fully.Qualified.ticks') and for code blocks I used all of the following forms: Haddock "code quote" > id :: a -> a > id x = x Markdown triple backticks ```hs id :: a -> a id x = x ``` Indentation by spaces id :: a -> a id x = x And so on. I know that at least Simon was thrown off in the past about my use of "tool-aware markup", perhaps also because I kept switching the targetted tool. I don't like that either. So I wonder Do you think it is worth optimising Notes for post-processing by an external tool?I think it's only reasonable if we decide for a target syntax. Which syntax should it be? Cheers, Sebastian

4 4

Re: Run-time absence info
by David Feuer 13 Apr '22

13 Apr '22

> > Date: Wed, 13 Apr 2022 08:59:06 +0200 > From: Andreas Klebinger <klebinger.andreas(a)gmx.at> > To: ghc-devs(a)haskell.org > Subject: Re: Absence info at run-time > Message-ID: <a577aa9c-6c96-945d-85f6-eb207f88b5b3(a)gmx.at> > Content-Type: text/plain; charset=UTF-8; format=flowed > > W/W should transform such a function into one who takes one less > argument removing any runtime overhead at least for fully applied > functions. > Fully applied functions are definitely not what I'm talking about. I suppose your suggestion is then if we an expression`f x` where bar > takes multiple arguments, but doesn't use the current argument then GHC > should: > > * Inspect f, check if the first argument to f is used > * If we can determine it isn't used instead of creating a PAP capturing > `f` and `x` instead only capture `f` and record this in the PAP closure > somehow. > * Once the PAP is fully applied pass a dummy argument instead of `x` to f. > Yes, that's the idea. The "somehow" is described below. If f is a known call that seems doable, although adding a bitmap to paps > might require us to increase the size of all PAP closures, making this > optimization less useful. > Every PAP has to carry its arity. I just looked it up: typedef struct { StgHeader header; StgHalfWord arity; // number of arguments left to apply, if zero this is an AP closure StgHalfWord n_args; // number of applied arguments StgClosure *fun; // guaranteed to point to a FUN closure StgClosure *payload[]; } StgPAP; On a 64-bit machine, we can combine arity and absence info for functions of up to 31 arguments into half a word. Specifically, set the lowest bit to indicate whether the first argument is used, etc. Then bitwise-or that with 1 `shiftL` arity. Each partial application performed shifts right by the number of arguments applied; if the result is 1, we know it's fully applied. (Any idea why we need the number of arguments that have been applied in the PAP? If that's actually only need for AP, then we might be able to make things a little more compact.) > If `f` is a unknown function there is currently no way to get > absent/used info for it's arguments at runtime. And changing that would > be a major change which seems unlikely to pay off. > I described a mechanism for encoding this concisely above. The same encoding could be used for functions that haven't been partially applied. I don't know where their arities are stashed. In their info tables? > So I think this would be theoretically possible, but it would rarely pay > off. > I'm not sure it's so rare. We end up having to work around this issue in libraries, with varying levels of effort and success. > Also do you have an example where `(const a) b` leads to stupid thunks? > It seems to me const should always be inlined in such a case, avoiding a > PAP allocation. > There won't be a PAP allocation if const inlines. The stupid thunk is a thunk to apply (\ _ -> a) to b. Suppose we define `fmap` for plain arrays (I know; probably not the best example), and let <$ take its default implementation: (<$) a = fmap (const a) If we calculate x <$ arr, that will fill an array with thunks, each of them retaining an element of the original array which will never be used. > Am 12/04/2022 um 23:02 schrieb David Feuer: > > Suppose `f` doesn't use its first argument. When forming the thunk (or > > partial application) `f a`, we don't need to record `a`. What if > > instead of arity, we store a bitmap used/absent arguments, terminated > > by a 1 bit? Could we then get rid of "stupid thunks" like `(const a) b`? > > > > _______________________________________________ > > ghc-devs mailing list > > ghc-devs(a)haskell.org > > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > > ------------------------------ > > Message: 3 > Date: Wed, 13 Apr 2022 08:21:25 +0000 > From: "Sebastian Graf" <sgraf1337(a)gmail.com> > To: "GHC Devs" <ghc-devs(a)haskell.org> > Subject: Markup language/convention for Notes? > Message-ID: <eme97afb2c-f674-4ed3-9d50-52c6482169d0@sebastian-pc> > Content-Type: text/plain; charset="utf-8"; Format="flowed" > > Hi Devs, > > When writing Notes, I find myself using markdown-inspired or > haddock-inspired features. The reason is that I keep telling myself > > > In 5 years time, we'll surely have an automated tool that renders > Notes referenced under the cursor in a popup in our IDE > > And I might not be completely wrong about that, after all the strong > conventions about Note declaration syntax allow me to do > jump-to-definition on Note links in my IDE already (thanks to a shell > script written by Zubin!). > Still, over the years I kept drifting between markdown and haddock > syntax, sometimes used `backticked inline code` or haddock 'ticks' to > refer to functions in the compiler (sometimes even > 'GHC.Fully.Qualified.ticks') and for code blocks I used all of the > following forms: > > Haddock "code quote" > > > id :: a -> a > > id x = x > > Markdown triple backticks > > ```hs > id :: a -> a > id x = x > ``` > > Indentation by spaces > > id :: a -> a > id x = x > > And so on. > > I know that at least Simon was thrown off in the past about my use of > "tool-aware markup", perhaps also because I kept switching the targetted > tool. I don't like that either. So I wonder > Do you think it is worth optimising Notes for post-processing by an > external tool?I think it's only reasonable if we decide for a target > syntax. Which syntax should it be? > Cheers, > Sebastian >

1 0