June 2023 - ghc-devs - Haskell.org

Final Call for Talks: Haskell Implementors' Workshop 2023
by Ryan Scott 01 Jul '23

01 Jul '23

The 2023 Haskell Implementors' Workshop deadline is just under one month away. We are looking forward to your talk submissions. Best, Ryan ================================== ACM SIGPLAN Haskell Implementors' Workshop https://icfp23.sigplan.org/home/hiw-2023 Seattle, Washington, United States, September 4, 2023 Co-located with ICFP 2023 https://icfp23.sigplan.org/ Important dates --------------- Deadline: July 4, 2023 (AoE) Notification: August 4, 2023 Workshop: September 4, 2023 The 15th Haskell Implementors' Workshop is to be held alongside ICFP 2023 this year in Seattle. 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 to 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 short 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 2023. 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 are encouraged to attend the workshop -- we need your feedback to keep the Haskell ecosystem thriving. Students working with Haskell are especially 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, optimisation 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://icfphiw23.hotcrp.com until July 4 (anywhere on earth). We will also have a lightning talks session. These have been very well received in recent years, and we aim to increase the time available to them. Lightning talks should 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. Program Committee ----------------- * Gergő Érdi (Standard Chartered Bank) * Sebastian Graf (Karlsruhe Institute of Technology) * Wen Kokke (University of Strathclyde) * Ryan Scott (Galois, Inc.) * Rebecca Skinner (Mercury) * Li-yao Xia (University of Edinburgh) Contact ------- * Ryan Scott <ryan.gl.scott at gmail.com>

1 1

CI *sad face*
by Bryan Richter 30 Jun '23

30 Jun '23

Two things are negatively impacting GHC CI right now: Darwin runner capacity is down to one machine, since the other three are paused. The problem and solution are known[1], but until the fix is implemented in GHC, expect pipelines to get backed up. I will work on a patch this morning [1]: https://gitlab.haskell.org/ghc/ghc/-/issues/23561 The other problem is one I just noticed, and I don't have any good info about it yet. The symptom is that Marge batch merges are failing reliably. Three patches that do fine individually somehow cause a type error in the hadrian-ghc-in-ghci job when combined[2]. The only clue is the error itself, which complains of an out-of-scope data constructor "ArchJavaScript" in the file compiler/GHC/Driver/Main.hs. A cursory look at the individual patches doesn't shed any light. I just rebased all of them to see if I can shake the error out of them that way. Any knowledge that can be brought to bear would be appreciated [2]: https://gitlab.haskell.org/ghc/ghc/-/merge_requests/10745#note_507418 -Bryan

2 3

Distinct closure types vs. known infotables for stack frames
by Alexis King 28 Jun '23

28 Jun '23

Hello all, I am tinkering with the RTS again while trying to fix #23513 <https://gitlab.haskell.org/ghc/ghc/-/issues/23513>, and every time I touch the exceptions/continuations code, I find myself waffling about whether to introduce more closure types. I’d like to get a second opinion so I can stop changing my mind! Currently, we have distinct closure types for certain special stack frames, like CATCH_FRAME, ATOMICALLY_FRAME, and UNDERFLOW_FRAME. However, there are other special stack frames that *don’t* get their own closure types: there is no MASK_ASYNC_EXCEPTIONS_FRAME or PROMPT_FRAME. Instead, when code needs to recognize these frames on the stack, it just looks for a known infotable pointer. That is, instead of writing if (frame->header.info->i.type == PROMPT_FRAME) { ... } we write if (*frame == &stg_prompt_frame_info) { ... } which works out because there’s only one info table that’s used for all prompt frames. There are a handful of stack frames that are recognized in this way by some part of the RTS, but the criteria used to determine which frames get their own types and which don’t is not particularly clear. For some frames, like UPDATE_FRAME, the closure type is necessary because it is shared between several infotables. But other types, like CATCH_FRAME and UNDERFLOW_FRAME, are only ever used by precisely one infotable. I think one can make the following arguments for/against using separate closure types for these stack frames: - Pro: It’s helpful to have separate types for particularly special frames like UNDERFLOW_FRAME because it makes it easier to remember which special cases to handle when walking the stack. - Pro: Branching on stack frame closure types using switch is easier to read than comparing infotable pointers. - Con: Adding more closure types unnecessarily pollutes code that branches on closure types, like the garbage collector. - Con: Using special closure types for these frames might make it seem like they have some special layout when in fact they are just ordinary stack frames. Does anyone have any opinions about this? I’m personally okay with the status quo, but the inconsistency makes me constantly second-guess whether someone else might feel strongly that I ought to be doing things the other way! Thanks, Alexis

3 4

Re: Inquiry about Supporting RISC-V 32 in Haskell
by Moritz Angermann 27 Jun '23

27 Jun '23

Hi Shiwei, Let me try to draw up a more visual representation do the current pipelines over the weekend. That might also explain why I think the subset might work as the intermediate steps *do* carry register width. Cheers, Moritz On Thu, 8 Jun 2023 at 2:44 PM, 卢诗炜 <shiwei.lu(a)compiler-dev.com> wrote: > Moritz, > > Thank you for your detailed response. However, we think that RV32 is not a > subset of RV64, and that the instruction selection logic for RV32 and RV64 > may differ. Because RV32 and RV64 have different register widths, it is > sometimes necessary to use different instructions than RV64 to ensure > correct results. > > We plan to support RV32 in Native Code Generation. And we may draw > inspiration from your support for RV64. We do want to be able to support RV32I+MAF, > also include C extensions. > > Do you have any comments or suggestions? > > Thank you so much for your answer and help! > > Best regards， > Shiwei > > > > > 卢诗炜 > shiwei.lu(a)compiler-dev.com > > <https://lingxi.office.163.com/static_html/signature.html?id=694846303015866…> > 签名由网易灵犀办公 <https://hubble.netease.com/sl/aaagLd> 定制 > > > > Original: > > - From：moritz.angermann<moritz.angermann(a)gmail.com> > - Date：2023-06-08 09:59:38(中国(GMT+08:00)) > > > - To：卢诗炜<shiwei.lu(a)compiler-dev.com> > - Cc： > - Subject：Re: Inquiry about Supporting RISC-V 32 in Haskell > > > > 诗炜, > > This is a bit hard to answer. As GHC is a fairly distributed open source > project, everyone can effectively just contribute (by opening a Merge > Request on gitlab.haskell.org/ghc) and then the discussion around it > will start. There is no fixed plan as to what ends up in e.g. GHC 9.8 > (merge window will close June 16th), or even what GHC 9.10 will look like > or when it will be release (likely the merge window will close mid > December). > > GHC has various ways to generate code: > - Via a C backend (compile Haskell to C, use a C compiler to compile to > machine code). This backend is quite slow (compile time, and runtime) > - Via LLVM (comile Haskell to LLVM textual IR, then use LLVM's `opt` and > `llc` to compile it to machine code). This backend produces good performing > code, but is very slow to compile. > - Via Native Code Generation (this turns Haskell into assembly, and then > uses usually the CC compiler to just turn .S into .o). This has good > compile time performance, and often competitive runtime performance. > However this lacks for all supposed architectures proper SIMD support. > > The LLVM backend can _in theory_ compile to any LLVM supported target. > (The LLVM RV64 backend in GHC is that effectively). The Native Code > Generator (NCG), support x86_64, i686, aarch64, and soon rv64. There are > also powerpc, sparc and mips NCG backends, however the state of most cross > compilation targets are only on a best effort basis and are not tested in > CI. Since GHC 9.2 there are also JavaScript and WASM backends in GHC. > > If you just want to cross compile for RV32, going down the LLVM route > might be the easiest. > > _my_ current plans are to work on > - The RV64 NCG > - The linker/loader for ELF/RV64 > - aarch32 NCG > > For RV32, we are in the lucky position that the instruction set is > effectively just a subset of the RV64 instruction set. So we might be able > to request some of the RV64 backend, or even better make the RV64 backend a > superset of the RV32 backend. > > I assume you are looking to support RV32I+MAF? > > Happy to help with any follow up questions. > > Cheers, > Moritz > > On Thu, 8 Jun 2023 at 08:38, 卢诗炜 <shiwei.lu(a)compiler-dev.com> wrote: > >> Thank you for your prompt reply. We have seen the support for your team >> working for RV64 in the GHC. You've done a great job. >> >> >> >> We'd like to do what your team does for GHC by supporting new compile >> backends, like RV32, to contribute to the community. We are more focused >> on _cross compilation_ from x86_64 to RV32 on Linux. But we dont know >> much about GHC's current dynamics and plans, whether there is a need for >> this or whether support is being provided. >> >> Do we need to support RV32 for GHC? Or is there anything else you think >> we can contribute to? >> >> Looking forward to your reply, Thanks! >> >> Best regards， >> Shiwei >> >> >> 卢诗炜 >> shiwei.lu(a)compiler-dev.com >> >> <https://lingxi.office.163.com/static_html/signature.html?id=694846303015866…> >> 签名由网易灵犀办公 <https://hubble.netease.com/sl/aaagLd> 定制 >> >> >> >> Original: >> >> - From：moritz.angermann<moritz.angermann(a)gmail.com> >> - Date：2023-06-07 19:45:32 >> - To：卢诗炜<shiwei.lu(a)compiler-dev.com> >> - Cc： >> - Subject：Re: Inquiry about Supporting RISC-V 32 in Haskell >> >> 您好诗炜！ >> 对不起，我的中文不很好。写英语。 >> I assume you've found my email from the ghc source repo? Yes, I have >> extensive experience adding compiler backends to GHC, including GHC's >> internal static linker. >> Recently a friend and I have started working on RV64 support in GHC (See >> https://gitlab.haskell.org/ghc/ghc/-/merge_requests/10367) So we have >> some prior experience >> with RISC-V. >> >> I understand you want to have support for RV32 in ghc? Are you looking >> for _native_ RV32 support GHC the compiler running natively on RISC-V 32 >> hardware? Or are you >> primarily interested in _cross compilation_ to RV32 from e.g. RV64, >> x86_64, aarch64? >> >> Also which platform are you interested in? Linux? >> >> Happy to provide more concrete feedback based on your exact requirements >> and vision. Ultimately GHC is a community project and everyone can >> contribute. I can certainly >> provide guidance and assistance here. >> >> Cheers, >> Moritz >> >> On Wed, 7 Jun 2023 at 18:16, 卢诗炜 <shiwei.lu(a)compiler-dev.com> wrote: >> >>> Dear Moritz Angermann， >>> >>> Hello! I am writing on behalf of Hunan Compiler Technology Co., Ltd. to >>> inquire about the possibility of supporting RISC-V 32 in Haskell o >>> >>> r if you're supporting it >>> . We are a technology company based in China and we would like to >>> contribute to the Haskell community by providing support for this >>> architecture. >>> >>> As you may know, RISC-V is an open-source instruction set architecture >>> that is gaining popularity in the industry. It is important for us to >>> ensure that our products are compatible with this architecture, and we >>> believe that supporting RISC-V in Haskell would be a valuable contribution >>> to the community. >>> >>> >>> We are willing to work closely with the community to understand the >>> requirements and challenges of supporting RISC-V in Haskell. We have a team >>> of experienced engineers who are familiar with both Haskell and RISC-V, and >>> we are confident that we can provide high-quality support for this >>> architecture. >>> >>> >>> We would appreciate any guidance or feedback from the community on this >>> matter. Please let us know if there are any specific requirements or >>> challenges that we should be aware of. We look forward to working with the >>> Haskell community to support RISC-V. >>> >>> >>> Thank you for your time and consideration. >>> >>> >>> Sincerely, Shiwei LU, Hunan Compiler Technology Co., Ltd. >>> >>> >>> >>> <https://lingxi.office.163.com/static_html/signature.html?id=694846303015866…> >>> >>> >>> >>> >> >> > >

4 3

SSH on Gitlab
by Simon Peyton Jones 27 Jun '23

27 Jun '23

Is SSH working on gitlab.haskell.org? I'm getting this simonpj@CDW-8FABODHF0V5:~$ ssh -v git(a)gitlab.haskell.org OpenSSH_8.2p1 Ubuntu-4, OpenSSL 1.1.1f 31 Mar 2020 debug1: Reading configuration data /home/simonpj/.ssh/config debug1: Reading configuration data /etc/ssh/ssh_config debug1: /etc/ssh/ssh_config line 19: include /etc/ssh/ssh_config.d/*.conf matched no files debug1: /etc/ssh/ssh_config line 21: Applying options for * debug1: Connecting to gitlab.haskell.org [145.40.64.137] port 22. debug1: Connection established. debug1: identity file /home/simonpj/.ssh/id_rsa type 0 debug1: identity file /home/simonpj/.ssh/id_rsa-cert type -1 debug1: identity file /home/simonpj/.ssh/id_dsa type 1 debug1: identity file /home/simonpj/.ssh/id_dsa-cert type -1 debug1: identity file /home/simonpj/.ssh/id_ecdsa type -1 debug1: identity file /home/simonpj/.ssh/id_ecdsa-cert type -1 debug1: identity file /home/simonpj/.ssh/id_ecdsa_sk type -1 debug1: identity file /home/simonpj/.ssh/id_ecdsa_sk-cert type -1 debug1: identity file /home/simonpj/.ssh/id_ed25519 type 3 debug1: identity file /home/simonpj/.ssh/id_ed25519-cert type -1 debug1: identity file /home/simonpj/.ssh/id_ed25519_sk type -1 debug1: identity file /home/simonpj/.ssh/id_ed25519_sk-cert type -1 debug1: identity file /home/simonpj/.ssh/id_xmss type -1 debug1: identity file /home/simonpj/.ssh/id_xmss-cert type -1 debug1: Local version string SSH-2.0-OpenSSH_8.2p1 Ubuntu-4 At this point it hangs. Stackoverflow suggests <https://superuser.com/questions/1374076/what-does-it-mean-if-ssh-hangs-afte…>a server fault. But I'm on a new WLAN so I suppose there could be some bizarre filtering? Thanks Simon

4 6

Improving Merge Request review processes
by Matthew Pickering 27 Jun '23

27 Jun '23

Hi all, Recently there has been some discussion about better systems and processes for keeping the flow of merge requests going smoothly through the review process. It has become clear that we need to be a bit more deliberate in handling merge requests in order to make sure we can correctly triage, review and merge the many fantastic contributions we get to GHC on a daily basis. Therefore we are proposing to introduce a "GHC Reviewer Group" whose members will share collective responsibility for ensuring that MRs make their way smoothly from creation to merge. The description of the role and responsibility for this group can be read and commented on here: https://docs.google.com/document/d/1FK9mryjC82DM6e5yxP7BOgu94As2bXccb55L8Or… The motivation for this proposal is two-fold. * Ensuring that MRs are reviewed and triaged in a timely manner. * Documenting where the responsibility for MR reviewing We welcome any discussion about this document and other ideas about how to improve the systems in this regard. Cheers, Matt

3 6

Minutes of Sunday's meeting of the "Staged Working Group"
by Sebastian Graf 23 Jun '23

23 Jun '23

Hi GHC devs, On Sunday I realised that there were many different people around at ZuriHac that are very knowledgeable about staged metaprogramming and macro systems (outside GHC, even). I really want a good staged metaprogramming story in Haskell (but don't know much about it or what I could contribute), and so I called everyone into a very spontaneous meeting, dubbed the "Staged Working Group". The purpose of the whole meeting was rather nebulous (staged, even); the only goal for me was to throw involved people in one room to have a focussed discussion (rather than lumping together with a subset of the people and then dissolving in the hall way) and to talk about different efforts in the community. In the end, I think we got a lot clearer picture about the challenges involved. We are very fortunate that Ben has kept minutes with useful pointers: https://edit.smart-cactus.org/u__IGA1bTd2DpulYmlnxaw Note that I don't intend to hold regular meetings or something of the sort; it was essentially a one time thing (but perhaps we'll have a 2.0 meeting at next year's ZuriHac). We loosely agreed to keep everyone posted on ongoing efforts in the direction of staged metaprogramming (and macros) by writing short status reports to this mailing list. Thanks to everyone who is involved in improving (Typed) Template Haskell and who was there on Sunday! Sebastian

2 1

GHCi tags generation: the end
by Hécate 13 Jun '23

13 Jun '23

Hello everyone, As the three-releases deprecation cycle has come to an end, GHC 9.8 marks the end of the integrated tags generation feature that used to live in GHCi. Started in 2020, the deprecation proposal showed that many people didn't know about its existence, and favoured external tools. It is also a burden that is removed from the shoulders of GHC developers, as it used to create friction with other features like UnboxedSums. You can find the proposal here: https://gitlab.haskell.org/ghc/ghc/-/issues/19884 and the migration wiki page here: https://gitlab.haskell.org/ghc/ghc/-/wikis/commentary/GHCi/Tags Thanks to everyone who was involved in this, especially Emily Martins. Cheers, Hécate -- Hécate ✨ 🐦: @TechnoEmpress IRC: Hecate WWW: https://glitchbra.in RUN: BSD

1 0

End of 9.2.* release series
by Matthew Pickering 06 Jun '23

06 Jun '23

Hi all, Just a quick message to say that we don't intend to produce any more releases in the 9.2.* release series. The forthcoming 9.8 release will be branched on June 16th. Cheers, Matt

1 0

Trouble building GHC
by Lyle Kopnicky 04 Jun '23

04 Jun '23

Hi folks, I’m new here. I’ll be attending the GHC Contributors’ Workshop next week, and in preparation, I’m trying to build GHC, both the native code backend and the JS backend. So far, I’ve only tried to build it with the native code backend, but I haven’t been able to get it to work. I’ve gotten help from some friendly folks on the #ghc channel on Matrix, and made some progress, but I’m still stuck. Is there anyone here who could be a point person for helping me get it to build? BTW I’m located on the west coast of the US (until next week when I’ll be in Switzerland), so time lag may be a factor. I’m using a Mac with aarch64 and macOS 13.3. Here are some of the things I’ve tried, and issues I’ve run into: - Started with the advice from this wiki: https://gitlab.haskell.org/ghc/ghc/-/wikis/building - Checked out the ghc source, on HEAD. - The rest of the steps were at https://gitlab.haskell.org/ghc/ghc/-/wikis/building/preparation/mac-osx - Already had Apple’s command line tools, but when I tried to do operations using them, I got an error saying I needed the full Xcode, so I installed that. - brew install autoconf automake python sphinx-doc - Worked fine, also added sphinx-build to the path - Initially tried using ghc 9.2.7 to build - later tried switching to 9.4.4 and eventually 9.4.5 - cabal update; cabal install alex happy haddock - This is where I ran into trouble - couldn’t build haddock. Cabal said it couldn’t resolve the dependencies. - I tried switching to ghc 9.4.4 and cabal 3.10.1.0 - same problem - User romes (Rodrigo) on #ghc helped with this - was able to reproduce it and filed a ticket: https://github.com/haskell/haddock/issues/1596 - However he pointed out that haddock was already supplied through ghcup so I don’t need to build it. - Already had MacTex installed and I installed the DejaVu font family. - ./boot && ./configure - Worked fine, although ./boot gave me lots of autoconf warnings like: configure.ac:9: warning: The macro `AC_HELP_STRING' is obsolete. configure.ac:9: You should run autoupdate. - Apparently autoconf has renamed these macros to pluralize them, and also encloses the arguments in square brackets. - hadrian/build - Ran into another problem: The build failed with: Error, file does not exist and no rule available: /Users/lyle/devel/haskell/ghc/_build/stage1/libraries/ghc-prim/build/GHC/Classes.hi - Rodrigo helped me out with this. Introduced me to other build flags like -j —flavour-quick. - The issue proved quite persistent, but it might fail on different .hi files. - It turns out if you ask Hadrian to build that specific file, it works. So somehow it can find a rule! Then you can proceed to rebuild and it will fail on a different .hi file. Obviously it would be tedious to do this for all the possible files it can fail on. - I also tried not building profiled libraries. - I tried, instead of using the Apple toolchain, using llvm 12, then llvm 16. But I got different errors from that. - Rodrigo was unable to reproduce the issue. - So, I thought I’d try the Nix approach. - First I had to repair my nix installation, because apparently updating macOS overwrites /etc/zshrc, overwriting the bit that sources '/nix/var/nix/profiles/default/etc/profile.d/nix-daemon.sh’ - Nix reminded me when I ran commands that I needed to add the flag '--extra-experimental-features nix-command’ and sometimes '--extra-experimental-features flakes’ - The instructions from the wiki <https://gitlab.haskell.org/ghc/ghc/-/wikis/building/preparation/mac-osx> didn’t work, got an error: - - nix build -f .gitlab/darwin/toolchain.nix -o toolchain.sh --extra-experimental-features nix-command - error: cannot evaluate a function that has an argument without a value ('system’) - But folks on #ghc recommended I use ghc.nix instead - Pointed me to https://ghc.dev/ - That linked to these instructions: https://github.com/alpmestan/ghc.nix#building-ghc - But those instructions failed with: - error: nix-shell requires a single derivation - User Artem said my command was wrong, instead recommended: - nix develop https://github.com/alpmestan/ghc.nix/archive/master.tar.gz - Once I added the magic experimental flags… - It failed, with: - error: NAR hash mismatch in input 'github:commercialhaskell/all-cabal-hashes/02bb1361217e690d83af9cc132b1d2bf2096763c' (/nix/store/zbav3qqbyz7mn7rh4iwybs0ni01ppdbj-source), expected 'sha256-HdAnlSc4U8ftnZrBZr2CewsPQs03V9K2gkTVHKG8IfA=', got 'sha256-86BgvJ+ebMxTp+nPxo659hsNJbhE6CYJWiIbQXX+sBM= - User MangoIV helped me out with this. - First I tried regenerating the lock file, with nix flake update. - Didn’t fix the problem. - Then, I checked out the branch update_flake_lock_action - This is apparently a branch designed to fix the problem - Didn’t fix the problem - Then I regenerated the lock file again, with nix flake update - That worked! Well, at least that got me to a ghc.nix prompt - So, I did: - ./boot - ./configure - cabal v2-update - hadrian/build -j --flavour=quick - It chugged along for quite a while. Sadly, it ended with this error: - - Linking /Users/lyle/Sync/devel/haskell/ghc/hadrian/dist-newstyle/build/aarch64-osx/ghc-9.2.4/hadrian-0.1.0.0/x/hadrian/build/hadrian/hadrian ... Data.Binary.Get.runGet at position 1181: Unknown encoding for constructor - What also worries me is that I thought I read somewhere that ghc.nix doesn’t work for cross-compilers, so even if it works for the native backend, it may not work for the JS backend. Any help would be much appreciated! — Lyle

6 12