March 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

devel2 build flavour thoughts
by Matthew Pickering 31 Mar '22

31 Mar '22

Hi all, In semi-private I have been making very bold claims about the unsuitability of the devel2 as a build flavour of choice for the aspiring developer. In order to bolster my claim I set out to find out some statistics about 1. devel2 flavour 2. default+no_profiled_libs+omit_pragmas+assertions flavour The difference between the two is essentially that flavour (2) builds each module with optimisation but disables cross-module optimisation (in particular inlining) In short the difference between the two flavours is negligible from my testing apart from one larger difference when building larger packages. Full build + test: Near identical Testsuite run: Near identical Recompile: Near identical - (2) is slower Build Cabal: 167s vs 259s So if you want to build packages use flavour 2 but otherwise it seems to make little difference. Cheers, Matt

2 1

question about mapSuccessors in GHC.Cmm.Node
by Norman Ramsey 29 Mar '22

29 Mar '22

Does anyone know why the continuations of CmmCall and CmmForeignCall are not considered successors for the purpose of `mapSuccessors`? Norman

1 0

safe maps within GHC?
by Norman Ramsey 28 Mar '22

28 Mar '22

A blog post of lexi-lambda's recently put me onto Matt Noonan's technique "Ghosts of Departed Proofs" [1], which appeared in the 2018 Haskell Symposium. One example that intrigued me was a safe `Map`, which uses the type system to guarantee that lookup does not fail. Maps are used pretty extensively in Cmm-land; for example, I recently have been using them to get information like the dominator set or the reverse postorder number of every node in a `CmmGraph`. In these maps, every `Label` that appears in the `CmmGraph` is expected to have an entry. For the moment, I am just using the standard lookup function; if an entry should be missing, my code calls `panic`. The idea of eliminating these calls and getting compile-time type safety is intriguing, but I'm not sure the game is worth the candle. What do other GHC devs think? Norman [1] https://iohk.io/en/research/library/papers/ghosts-of-departed-proofsfunctio…

3 3

Call for Talks: Haskell Implementors' Workshop 2022
by Alejandro Serrano Mena 23 Mar '22

23 Mar '22

(apologies for multiple copies of this message) ACM SIGPLAN Haskell Implementors' Workshop https://icfp22.sigplan.org/home/hiw-2022 Ljubljana, Slovenia, 11 September 2022 Co-located with ICFP 2022 https://icfp22.sigplan.org/ Important dates --------------- Deadline: 11 July, 2022 (AoE) Notification: 11 August, 2022 Workshop: 11 September, 2022 The 14th Haskell Implementors' Workshop is to be held alongside ICFP 2022 this year in Ljubljana. 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 short 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 2022. 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, 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://icfphiw22.hotcrp.com until July 11th (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. Program Committee ----------------- * Pepe Iborra (Meta) * Gabrielle Keller (Utrecht University) * Emily Pilmore (Kadena) * Vladislav Zavialov (Serokell) * Alejandro Serrano (Tweag) Contact ------- * Alejandro Serrano <trupill at gmail.com>

1 0

Wiki page for WebAssembly support in GHC
by Cheng Shao 03 Mar '22

03 Mar '22

Hi all, We're planning to add WebAssembly support to GHC. This work will be delivered by me and Norman Ramsey, the former Asterius team at Tweag. In the past few months, we did a strategic shift and focused on growing GHC towards Asterius, leveraging existing RTS as much as possible. We've made decent progress since then, and we expect to target 9.6 release much like GHCJS. We've created the https://gitlab.haskell.org/ghc/ghc/-/wikis/WebAssembly-backend wiki page, as a central point for communication. You're welcome to take a look and ask questions (either in this thread or editing that page in place), we'll answer the questions in the FAQ section. Cheers, Cheng

2 1