April 2022 - ghc-devs

Question about ambiguous predicates in pattern bindings
by Benjamin Redelings 16 Aug '22

16 Aug '22

Hi, 1. I'm reading "A Static semantics for Haskell" and trying to code it up. I came across some odd behavior with pattern bindings, and I was wondering if someone could explain or point me in the right direction. Suppose you have the declaration (x,y) = ('a',2) My current code is yielding: x :: Num a => Char y :: Num a => a However, I notice that ghci gives x the type Char, with no constraint, which is what I would expect. It also gives y the type 'Num b => b', so I don't think it is defaulting a to Int here. The weird results from my code stem from rule BIND-PRED in Figure 15 of https://homepages.inf.ed.ac.uk/wadler/papers/staticsemantics/static-semanti… E |- bind ~~> \dicts : theta -> monobinds in bind : (LIE_{encl}, theta => LVE) Here theta = ( Num a ) and LVE = { x :: Char, y :: a }. So, theta => LVE is { x :: Num a => Char, y :: Num a => a } The obvious thing to do is avoid changing a type T to Num a => T if T does not contain a. Also I'm not totally sure if that trick gets to the bottom of the issue. However, the paper doesn't mention define theta => LVE that way. Is there something else I should read on this? 2. If we just chop out predicates which mention variables not in the type ( == ambiguous predicates?) then I'm not totally sure how to create code for this. I would imagine that we have something like tup dn = ('a', fromInteger dn 2) x = case (tup dn) of (x,y) -> x y dn case (tup dn) of (x,y) -> y In this case its not clear where to get the `dn` argument of `tup` from, in the definition of `x`. Can we pass in `undefined`? Should we do something else? If anyone can shed light on this, I would be grateful :-) -BenRI

4 8

[ANNOUNCE] GHC 9.2.2 is not available
by Ben Gamari 05 May '22

05 May '22

The GHC developers are very happy to at announce the availability of GHC 9.2.2. Binary distributions, source distributions, and documentation are available at downloads.haskell.org: https://downloads.haskell.org/ghc/9.2.2 This release includes many bug-fixes and other improvements to 9.2.1 including: * A number of bug-fixes in the new AArch64 native code generator * Fixes ensuring that the `indexWord8ArrayAs*#` family of primops is handled correctly on platforms lacking support for unaligned memory accesses (#21015, #20987). * Improvements to the compatibility story in GHC's migration to the XDG Base Directory Specification (#20684, #20669, #20660) * Restored compatibility with Windows 7 * A new `-fcompact-unwind` flag, improving compatibility with C++ libraries on Apple Darwin (#11829) * Introduction of a new flag, `-fcheck-prim-bounds`, enabling runtime bounds checking of array primops (#20769) * Unboxing of unlifted types (#20663) * Numerous improvements in compiler performance. * Many, many others. See the [release notes] for a full list. As some of the fixed issues do affect correctness users are encouraged to upgrade promptly. Finally, thank you to Microsoft Research, 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. Moreover, this release would not have been possible without the hundreds of open-source contributors whose work comprise this release. As always, do open a [ticket][] if you see anything amiss. Happy compiling, - Ben [ticket]: https://gitlab.haskell.org/ghc/ghc/-/issues/new [release notes]: https://downloads.haskell.org/ghc/9.2.2/docs/html/users_guide/9.2.2-notes.h…

3 5

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

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