From cheng.shao at tweag.io Thu Mar 3 14:11:56 2022 From: cheng.shao at tweag.io (Cheng Shao) Date: Thu, 3 Mar 2022 15:11:56 +0100 Subject: Wiki page for WebAssembly support in GHC Message-ID: 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 From harendra.kumar at gmail.com Thu Mar 3 17:11:34 2022 From: harendra.kumar at gmail.com (Harendra Kumar) Date: Thu, 3 Mar 2022 22:41:34 +0530 Subject: Wiki page for WebAssembly support in GHC In-Reply-To: References: Message-ID: This is exciting news. Thank you Cheng and Norman, and Tweag! With both GHCJS and WASM officially supported in GHC, Haskell will now have first class support for JS. I am looking forward to GHC 9.6. -harendra On Thu, 3 Mar 2022 at 19:42, Cheng Shao wrote: > > 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 > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs From ben at well-typed.com Sun Mar 6 22:59:42 2022 From: ben at well-typed.com (Ben Gamari) Date: Sun, 06 Mar 2022 17:59:42 -0500 Subject: [ANNOUNCE] GHC 9.2.2 is not available Message-ID: <87r17ewuxe.fsf@smart-cactus.org> 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.html -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From ben at well-typed.com Sun Mar 6 23:11:29 2022 From: ben at well-typed.com (Ben Gamari) Date: Sun, 06 Mar 2022 18:11:29 -0500 Subject: [ANNOUNCE] GHC 9.2.2 is now available In-Reply-To: <87r17ewuxe.fsf@smart-cactus.org> References: <87r17ewuxe.fsf@smart-cactus.org> Message-ID: <87mti2wubc.fsf@smart-cactus.org> Naturally, the subject line here should have read GHC 9.2.2 is *now* available Apologies for the confusion. Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From george.colpitts at gmail.com Mon Mar 7 00:42:47 2022 From: george.colpitts at gmail.com (George Colpitts) Date: Sun, 6 Mar 2022 20:42:47 -0400 Subject: [ANNOUNCE] GHC 9.2.2 is not available In-Reply-To: <87r17ewuxe.fsf@smart-cactus.org> References: <87r17ewuxe.fsf@smart-cactus.org> Message-ID: Thanks Ben When I do an install on macos Monterey 12.2.1 (Intel) I get ghc-pkg-9.2.2 cannot be opened because the developer cannot be verified On Sun, Mar 6, 2022 at 7:02 PM Ben Gamari wrote: > > 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.html > > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kazu at iij.ad.jp Mon Mar 7 06:27:40 2022 From: kazu at iij.ad.jp (Kazu Yamamoto (=?iso-2022-jp?B?GyRCOzNLXE9CSScbKEI=?=)) Date: Mon, 07 Mar 2022 15:27:40 +0900 (JST) Subject: [ANNOUNCE] GHC 9.2.2 is not available In-Reply-To: References: <87r17ewuxe.fsf@smart-cactus.org> Message-ID: <20220307.152740.1433207400109063719.kazu@iij.ad.jp> Hi George, FYI: https://twitter.com/kazu_yamamoto/status/1500643489985761282 --Kazu > Thanks Ben > > When I do an install on macos Monterey 12.2.1 (Intel) I get > > ghc-pkg-9.2.2 cannot be opened because the developer cannot be verified > > > On Sun, Mar 6, 2022 at 7:02 PM Ben Gamari wrote: > >> >> 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.html >> >> _______________________________________________ >> Glasgow-haskell-users mailing list >> Glasgow-haskell-users at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users >> From nr at cs.tufts.edu Tue Mar 22 18:10:01 2022 From: nr at cs.tufts.edu (Norman Ramsey) Date: Tue, 22 Mar 2022 14:10:01 -0400 Subject: safe maps within GHC? Message-ID: <20220322181001.D0FC02C2D1B@homedog.cs.tufts.edu> 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-proofsfunctional-pearls/ From lists at richarde.dev Fri Mar 25 19:20:01 2022 From: lists at richarde.dev (Richard Eisenberg) Date: Fri, 25 Mar 2022 19:20:01 +0000 Subject: safe maps within GHC? In-Reply-To: <20220322181001.D0FC02C2D1B@homedog.cs.tufts.edu> References: <20220322181001.D0FC02C2D1B@homedog.cs.tufts.edu> Message-ID: <010f017fc2857781-a5c3c9ca-6b88-4668-b5b9-633508b90e38-000000@us-east-2.amazonses.com> I've tried once or twice to introduce more static checking in the GHC source code. My limited experience with this is that the effort is large, and the payoff small. Maybe your experience will be different -- I haven't tried the particular technique in that paper -- but I probably wouldn't personally invest much energy in this direction. Richard > On Mar 22, 2022, at 2:10 PM, Norman Ramsey wrote: > > 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-proofsfunctional-pearls/ > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs From simon.peytonjones at gmail.com Sat Mar 26 20:07:32 2022 From: simon.peytonjones at gmail.com (Simon Peyton Jones) Date: Sat, 26 Mar 2022 20:07:32 +0000 Subject: safe maps within GHC? In-Reply-To: <010f017fc2857781-a5c3c9ca-6b88-4668-b5b9-633508b90e38-000000@us-east-2.amazonses.com> References: <20220322181001.D0FC02C2D1B@homedog.cs.tufts.edu> <010f017fc2857781-a5c3c9ca-6b88-4668-b5b9-633508b90e38-000000@us-east-2.amazonses.com> Message-ID: My instinct is the same as Richard's. I had a quick look at the paper and didn't immediately grok how to use it for finite maps. Still, in the TTG work we are slowly adding more static checking to GHC's code, and the O/C stuff in Hoopl is another example. And perhaps you may find a sweet spot? Feel free to have a try, so we can evaluate whether the cost (in understanding what's going on) is worth the benefit. Simon On Fri, 25 Mar 2022 at 19:26, Richard Eisenberg wrote: > I've tried once or twice to introduce more static checking in the GHC > source code. My limited experience with this is that the effort is large, > and the payoff small. Maybe your experience will be different -- I haven't > tried the particular technique in that paper -- but I probably wouldn't > personally invest much energy in this direction. > > Richard > > > On Mar 22, 2022, at 2:10 PM, Norman Ramsey wrote: > > > > 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-proofsfunctional-pearls/ > > _______________________________________________ > > ghc-devs mailing list > > ghc-devs at haskell.org > > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nr at cs.tufts.edu Mon Mar 28 17:29:03 2022 From: nr at cs.tufts.edu (Norman Ramsey) Date: Mon, 28 Mar 2022 13:29:03 -0400 Subject: safe maps within GHC? In-Reply-To: (sfid-H-20220327-120030-+108.32-1@multi.osbf.lua) References: <20220322181001.D0FC02C2D1B@homedog.cs.tufts.edu> <010f017fc2857781-a5c3c9ca-6b88-4668-b5b9-633508b90e38-000000@us-east-2.amazonses.com> (sfid-H-20220327-120030-+108.32-1@multi.osbf.lua) Message-ID: <20220328172903.9F20B2C1B05@homedog.cs.tufts.edu> > Feel free to have a try, so we can evaluate whether the > cost (in understanding what's going on) is worth the benefit. Sounds good. This experiment goes on my "someday/maybe" list. Norman > On Fri, 25 Mar 2022 at 19:26, Richard Eisenberg wrote: > > > I've tried once or twice to introduce more static checking in the GHC > > source code. My limited experience with this is that the effort is large, > > and the payoff small. Maybe your experience will be different -- I haven't > > tried the particular technique in that paper -- but I probably wouldn't > > personally invest much energy in this direction. > > > > Richard > > > > > On Mar 22, 2022, at 2:10 PM, Norman Ramsey wrote: > > > > > > 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-proofsfunctional-pearls/ > > > _______________________________________________ > > > ghc-devs mailing list > > > ghc-devs at haskell.org > > > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > > > _______________________________________________ > > ghc-devs mailing list > > ghc-devs at haskell.org > > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > > From nr at cs.tufts.edu Tue Mar 29 18:28:51 2022 From: nr at cs.tufts.edu (Norman Ramsey) Date: Tue, 29 Mar 2022 14:28:51 -0400 Subject: question about mapSuccessors in GHC.Cmm.Node Message-ID: <20220329182851.8E1832C257B@homedog.cs.tufts.edu> Does anyone know why the continuations of CmmCall and CmmForeignCall are not considered successors for the purpose of `mapSuccessors`? Norman From matthewtpickering at gmail.com Thu Mar 31 09:50:00 2022 From: matthewtpickering at gmail.com (Matthew Pickering) Date: Thu, 31 Mar 2022 10:50:00 +0100 Subject: devel2 build flavour thoughts Message-ID: 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 From lists at richarde.dev Thu Mar 31 16:23:51 2022 From: lists at richarde.dev (Richard Eisenberg) Date: Thu, 31 Mar 2022 16:23:51 +0000 Subject: devel2 build flavour thoughts In-Reply-To: References: Message-ID: <010f017fe0ca5706-28177cb5-9fb9-4213-8f85-1bfa4d6c4550-000000@us-east-2.amazonses.com> Interesting -- thanks for taking the time to do this. > > Full build + test: Near identical > Testsuite run: Near identical > Recompile: Near identical - (2) is slower > Build Cabal: 167s vs 259s I assume from your statement that (2) is 167s and (1) is 259s? These results surprise me, in a few ways: - My understanding is that devel2 does not optimise (-O0) the stage-2 compiler. So I'm surprised that the testsuite runs in the same amount of time for both: I would expect (2) to be measurably faster. - And if the testsuite is the same for both, then I would expect "Build Cabal" to be the same for both: both measurements are looking at the performance of the stage-2 compiler. Yet the difference in time in "Build Cabal" is drastic. Why is this not echoed in the testsuite? (Maybe the testsuite overhead dwarfs the efficiency of the compiler itself?) - As we have discovered, devel2 behaves differently in the testsuite than your flavour (2). But your text suggests that the only difference is that devel2 is completely unoptimised... and yet the testsuite-behavior differences are not (I think) about performance. So there's some *other* difference. My key requirements in a build flavor are: A. assertions enabled B. quick recompilation C. < 3 spurious test case failures when running the testsuite locally I don't have any particular attachment to devel2, per se, other than that (with `make`, at least), it delivers A,B,C. My struggle with Hadrian is that devel2 no longer delivers C. If a different flavor provides A,B,C with Hadrian, I'm happy to give it a go. I'm a little worried about "(2) is slower" above, so my money is still with devel2, as delivering A,B,C better. Building packages is not one of my requirements. In any case, this is a good conversation to have, because it may yield an understanding that we should jettison or replace devel2. Thanks for starting it! Richard > > So if you want to build packages use flavour 2 but otherwise it seems > to make little difference. > > Cheers, > > Matt > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs From trupill at gmail.com Wed Mar 23 08:44:03 2022 From: trupill at gmail.com (Alejandro Serrano Mena) Date: Wed, 23 Mar 2022 08:44:03 -0000 Subject: Call for Talks: Haskell Implementors' Workshop 2022 Message-ID: <20F7F799-892E-47A3-BED1-EAAC629E09DF@getmailspring.com> (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 -------------- next part -------------- An HTML attachment was scrubbed... URL: