- ghc-devs - Haskell.org

Broken links in GHC User’s Manual
by Wolfgang Jeltsch 13 Jul '20

13 Jul '20

Hi! When I go to https://www.haskell.org/ghc/ and click on “Documentation”, I’m taken to https://downloads.haskell.org/ghc/latest/docs/html/users_guide/ . Clicking there on the entry for Section 9.1, for example, takes me to https://downloads.haskell.org/ghc/latest/docs/html/users_guide/glasgow_exts… , where there is no page. On the other hand, when I go to https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/index.html (which I have in my bookmarks) and then click on the entry for Section 9.1, I’m taken to https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/glasgow_ext… , where there is the expected page. Could this perhaps be fixed? Thank you. All the best, Wolfgang

3 2

A small documentation PR on github
by Alexander Kjeldaas 05 Jul '20

05 Jul '20

Hi devs! I created a small documentation PR for the GHC FFI on github and noticed that there's another one-liner PR from May 2019 that was not merged. https://github.com/ghc/ghc/pull/260 https://github.com/ghc/ghc/pull/255 Just checking that simple PRs are still accepted on github. Alexander

4 5

Async exceptions and delimited continuations
by Alexis King 03 Jul '20

03 Jul '20

Hi all, As some of you are likely aware, I have an open GHC proposal[1] to add native support for delimited continuations to the RTS. I also have an incomplete implementation,[2] and the only major remaining obstacle concerns async exceptions. The issue is subtle, so I’ve tried to provide all the necessary context in this email. If you’re already familiar with the ideas at play, you can skip the context about how delimited continuations work. For those unfamiliar, delimited continuations allow capturing slices of the call stack and restoring them later. For example, the program do y <- prompt $ do x <- control0 $ \k -> k (pure 10) pure (x + 5) print y will print 15. To understand what’s happening operationally, we can imagine an abstract call stack made up of continuation frames: ┌──────────┐ │ ● + 5 │ redex: control0 $ \k -> k (pure 10) ├──────────┤ │ prompt ● │ ├──────────┤ │ print ● │ ├──────────┤ │ ... │ ├──────────┤ Here, each ● represents the “hole” where the evaluated result of the redex will be returned. `control0` moves all the frames between the top of the stack and the first `prompt` into the heap and returns a reference to them, so after a single reduction step, we have ┌──────────┐ │ print ● │ redex: k1 (pure 10) ├──────────┤ heap: k1 = ┌──────────┐ │ ... │ │ ● + 5 │ ├──────────┤ └──────────┘ When a continuation is applied, its stored stack frames are copied back onto the top of the current stack, and the argument becomes the new redex: ┌──────────┐ │ ● + 5 │ redex: pure 10 ├──────────┤ │ print ● │ ├──────────┤ │ ... │ ├──────────┤ Now it should hopefully be clear how we end up printing 15. With that context, consider the following expression: prompt $ mask_ $ do x <- control0 $ \k -> k (pure 10) f x The call stack at the point of control0 looks very similar in this program, but now we have a use of `mask_` in there as well: ┌──────────┐ │ f ● │ redex: control0 $ \k -> k (pure 10) ├──────────┤ exns: masked │ mask_ ● │ ├──────────┤ │ prompt ● │ ├──────────┤ │ ... │ ├──────────┤ When capturing the continuation, we’ll unwind the stack the same way we did before. Because we’re popping mask_ off the stack, we’ll unmask async exceptions: ┌──────────┐ redex: k1 (pure 10) │ ... │ exns: not masked ├──────────┤ heap: k1 = ┌──────────┐ │ f ● │ ├──────────┤ │ mask_ ● │ └──────────┘ Now when we apply `k1`, we’ll copy the `mask_` frame back onto the stack, and we must re-mask async exceptions. Otherwise, exceptions will not be masked during the call to `f`, which would be wrong. Why is this a problem? The RTS applies an optimization: if you call mask_ (actually maskAsyncExceptions#) while exceptions are already masked, it doesn’t push a new stack frame at all. So, for example, if you write mask_ $ mask_ $ foo bar you’ll end up with only one mask_ frame on the call stack, not two. This tiny optimization actually allows not one but two savings: 1. The immediate benefit is that we save a stack frame. 2. The hidden benefit is that we never need to push the old exception masking state onto the stack. If we had multiple mask_ frames on the stack simultaneously, we wouldn’t know what to do when returning: should we unmask them, or should they stay masked? We’d need to push that information onto the stack in the same way we must push a return address when calling a function. By skipping these redundant stack frames, we can always be certain the right thing to do on return is to unmask async exceptions. No need to store anything else. (This explanation is a slight simplification, especially once maskUninterruptible comes into play, but it’s close enough.) Now you may see the looming problem: this strategy completely breaks down in the presence of delimited continuations. With delimited continuations, we might have a program like this: mask_ $ prompt $ mask_ $ ... If we capture a continuation up to this prompt, we expect the inner mask_ frame to be captured along with it. But that won’t happen if we never pushed a mask_ frame at all due to the aforementioned optimization. So now I can finally state my question: what is the right solution for this? I see three obvious possible ways forward: 1. Keep track of whether or not we’re inside a prompt and skip the optimization in that case. 2. Keep some bookkeeping that tracks the modifications to the async exception masking state since the most recently pushed prompt. 3. Just don’t bother with the optimization at all. Option 3 certainly seems the most appealing from a simplicity point of view, and I suspect the optimization doesn’t matter much in practice. Why? Because the real `mask` implementation from Control.Exception already avoids re-masking exceptions if they’re masked! (And that’s okay, because prompt# and control0# are not intended to be used directly in IO, so code that uses them can provide its own version of `mask`.) However, it is admittedly possible for the restore action passed to the argument of `mask` to create redundant calls, as the check is only performed in `mask` itself. Is eliminating this optimization an acceptable compromise? Or is there reason to believe this is important for performance of real programs? Thanks, Alexis [1]: https://github.com/ghc-proposals/ghc-proposals/pull/313 [2]: https://gitlab.haskell.org/lexi.lambda/ghc/-/commits/first-class-continuati…

4 3

Perf notes
by Simon Peyton Jones 02 Jul '20

02 Jul '20

Despite a recent git fetch https://gitlab.haskell.org/ghc/ghc-performance-notes.git refs/notes/perf:refs/notes/ci/perf I'm getting lots of perf regressions in HEAD. For example =====> T9203(normal) 1 of 1 [0, 0, 0] ]0;T9203(normal) 1 of 1 [0, 0, 0]cd "T9203.run" && "/home/simonpj/code/HEAD-3/inplace/bin/ghc-stage2" -o T9203 T9203.hs -dcore-lint -dstg-lint -dcmm-lint -no-user-package-db -rtsopts -fno-warn-missed-specialisations -fshow-warning-groups -fdiagnostics-color=never -fno-diagnostics-show-caret -Werror=compat -dno-debug-output -O2< cd "T9203.run" && ./T9203 +RTS -V0 -tT9203.stats --machine-readable -RTS < runtime/bytes allocated increased from x86_64-linux-deb9 baseline @ HEAD~28: Expected T9203 (normal) runtime/bytes allocated: 56046952.0 +/-5% Lower bound T9203 (normal) runtime/bytes allocated: 53244604 Upper bound T9203 (normal) runtime/bytes allocated: 58849300 Actual T9203 (normal) runtime/bytes allocated: 108464536 Deviation T9203 (normal) runtime/bytes allocated: 93.5 % *** unexpected stat test failure for T9203(normal) Performance Metrics (test environment: local): T9203(normal) runtime/bytes allocated 108464536.000 (baseline @ HEAD~28) 56046952.000 [increased, 93.5%] What am I doing wrong? Simon

2 6

perf regression with TypeFamilies
by Richard Eisenberg 02 Jul '20

02 Jul '20

Hi Harendra, I saw your comment on a ghc proposal (https://github.com/ghc-proposals/ghc-proposals/pull/343#issuecomment-650797…) that said you experienced perf regressions with -XTypeFamilies enabled (but no other changes). Are these reproducible in a way that can be shared publicly? And are the regressions in compile times or run times? -XTypeFamilies enables -XMonoLocalBinds, which disables let-generalization on some nested lets. It is thus just barely conceivable that different Core is produced depending on this extension, and that there may be a possibility of performance changes. But this would be unexpected, and something worth investigating. In other words: if you can, do please post a bug -- simply enabling -XTypeFamilies should not slow anything down! Thanks, Richard

2 2

IP/key change for gitlab.haskell.org?
by Richard Eisenberg 26 Jun '20

26 Jun '20

An innocent `git push` yielded this today: @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @ WARNING: POSSIBLE DNS SPOOFING DETECTED! @ @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ The ED25519 host key for gitlab.haskell.org has changed, and the key for the corresponding IP address 139.178.85.33 is unknown. This could either mean that DNS SPOOFING is happening or the IP address for the host and its host key have changed at the same time. @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @ @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY! Someone could be eavesdropping on you right now (man-in-the-middle attack)! It is also possible that a host key has just been changed. The fingerprint for the ED25519 key sent by the remote host is SHA256:/dI7zsBRZNPB+0TqskF7rSaZ/LhQw0cF4c5W+4uMlRo. Please contact your system administrator. Add correct host key in /Users/rae/.ssh/known_hosts to get rid of this message. Offending ED25519 key in /Users/rae/.ssh/known_hosts:21 ED25519 host key for gitlab.haskell.org has changed and you have requested strict checking. Host key verification failed. I know the server had a rough weekend. Is this a natural consequence, or is something fishy going on? Thanks, Richard

4 3

[HIW'20] Third Call for Talks
by Ben Gamari 24 Jun '20

24 Jun '20

Hello everyone, Haskell Implementors Workshop is calling for talk proposals. Co-located with ICFP, HiW is an ideal place to describe a Haskell library, a Haskell extension, compiler, works-in-progress, demo a new Haskell-related tool, or even propose future lines of Haskell development. The deadline for submissions is next week, July 2nd 2020. Call for Talks ============== The 12th Haskell Implementors’ Workshop is to be held alongside ICFP 2020 this year. It is a forum for people involved in the design and development of Haskell implementations, tools, libraries, and supporting infrastructure, to share their work and discuss future directions and collaborations with others. Talks and/or demos are proposed by submitting an abstract, and selected by a small program committee. There will be no published proceedings. The workshop will be informal and interactive, with open spaces in the timetable and room for ad-hoc discussion, demos and lightning talks. Scope and Target Audience ------------------------- It is important to distinguish the Haskell Implementors’ Workshop from the Haskell Symposium which is also co-located with ICFP 2020. The Haskell Symposium is for the publication of Haskell-related research. In contrast, the Haskell Implementors’ Workshop will have no proceedings – although we will aim to make talk videos, slides and presented data available with the consent of the speakers. The Implementors’ Workshop is an ideal place to describe a Haskell extension, describe works-in-progress, demo a new Haskell-related tool, or even propose future lines of Haskell development. Members of the wider Haskell community encouraged to attend the workshop – we need your feedback to keep the Haskell ecosystem thriving. Students working with Haskell are specially encouraged to share their work. The scope covers any of the following topics. There may be some topics that people feel we’ve missed, so by all means submit a proposal even if it doesn’t fit exactly into one of these buckets: - Compilation techniques - Language features and extensions - Type system implementation - Concurrency and parallelism: language design and implementation - Performance, optimization and benchmarking - Virtual machines and run-time systems - Libraries and tools for development or deployment Talks ----- We invite proposals from potential speakers for talks and demonstrations. We are aiming for 20-minute talks with 5 minutes for questions and changeovers. We want to hear from people writing compilers, tools, or libraries, people with cool ideas for directions in which we should take the platform, proposals for new features to be implemented, and half-baked crazy ideas. Please submit a talk title and abstract of no more than 300 words. Submissions can be made via HotCRP at https://icfp-hiw20.hotcrp.com/ until July 2nd (anywhere on earth). We will also have lightning talks session. These have been very well received in recent years, and we aim to increase the time available to them. Lightning talks be ~7mins and are scheduled on the day of the workshop. Suggested topics for lightning talks are to present a single idea, a work-in-progress project, a problem to intrigue and perplex Haskell implementors, or simply to ask for feedback and collaborators. Logistics --------- Due to the on-going COVID-19 situation, ICFP (and, consequently, HIW) will be held remotely this year. However, the organizers are still working hard to provide for a great workshop experience. While we are sad that this year will lack the robust hallway track that is often the highlight of HIW, we believe that this remote workshop presents a unique opportunity to include more of the Haskell community in our discussion and explore new modes of communicating with our colleagues. We hope that you will join us in making this HIW as vibrant as any other. Program Committee ----------------- - Andrey Mokhov (Newcastle University) - Ben Gamari (Well-Typed LLP) - Christian Baaij (QBayLogic) - George Karachalias (Tweag I/O) - Klara Marntirosian (KU Leuven) - Matthew Pickering (Univeristy of Bristol) - Ryan G.L. Scott (Indiana University Bloomington) Best wishes, ~ Ben

1 0

Fixing type synonyms to Uniq(D)FM newtypes
by Andreas Klebinger 23 Jun '20

23 Jun '20

There was a discussion about making UniqFM typed for the keys here a while ago. (https://mail.haskell.org/pipermail/ghc-devs/2020-January/018451.html and following) I wrote up an MR for one possible approach here: https://gitlab.haskell.org/ghc/ghc/-/merge_requests/3577 It implements solution 2 from that discussion. Just while getting the patch to typecheck I've already seen a number of cases where this increased readability of the code quite a bit so I think it's a good improvement. If there are strong objections to this solution let me know. In that case I'm happy to abandon the patch. If not I will clean it up and get it ready for merging.

2 2

Re: GitLab status
by Ryan Scott 22 Jun '20

22 Jun '20

Just as an FYI, there appears to be some data loss from this migration. For example, I pushed a commit to !3536 [1] that appears to have been dropped, leading to confusion here [2]. To make things worse, I never received an e-mail notification for this comment—I only discovered it by chance. I also opened an issue about FUN, but that appears to have been lost. I could try to resubmit it, but perhaps the data still exists somewhere on servers somewhere? Ryan S. ----- [1] https://gitlab.haskell.org/ghc/ghc/-/merge_requests/3536 [2] https://gitlab.haskell.org/ghc/ghc/-/merge_requests/3536#note_283322

2 1

Introducing GHC whole program compiler (GHC-WPC)
by Csaba Hruska 22 Jun '20

22 Jun '20

Hello, I've created a whole program compilation pipeline for GHC via STG. Please read my blog post for the details: Introducing GHC whole program compiler (GHC-WPC) <https://www.patreon.com/posts/introducing-ghc-38173710> Regards, Csaba Hruska

3 5