From ryan.gl.scott at gmail.com Sat Jul 1 21:29:57 2023 From: ryan.gl.scott at gmail.com (Ryan Scott) Date: Sat, 1 Jul 2023 17:29:57 -0400 Subject: Final Call for Talks: Haskell Implementors' Workshop 2023 In-Reply-To: References: Message-ID: One correction to the previous email: the link should be https://icfp-hiw2023.hotcrp.com (with a hyphen), not https://icfphiw23.hotcrp.com. (The former matches what is listed on the HIW website at https://icfp23.sigplan.org/home/hiw-2023.) I apologise for any confusion this may have caused. Best, Ryan On Mon, Jun 5, 2023 at 7:47 AM Ryan Scott wrote: > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben at well-typed.com Sun Jul 2 04:42:01 2023 From: ben at well-typed.com (Ben Gamari) Date: Sun, 02 Jul 2023 00:42:01 -0400 Subject: GitLab upgraded Message-ID: <87bkguq609.fsf@smart-cactus.org> Hi all, This evening (EST) I performed a quick upgrade of gitlab.haskell.org. As a result, you will notice that the UI has changed quite a bit. This is due to a beta redesign of GitLab's navigation scheme. While I've found it relatively unobjectionable (and seemingly a bit more snappier), your mileage may vary. If you find the redesign particularly onerous, you can (for now) disable it by toggling the "New navigation" slider in your "user" menu (accessed by clicking on your avatar icon in the sidebar on the left). If you do find that reverting is necessary, please do raise an issue with upstream as I suspect that upstream will commit to the redesign in the next few releases. As always, if you find something isn't working as you would expect, don't hesitate to reach out. 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 bryan at haskell.foundation Mon Jul 3 11:15:30 2023 From: bryan at haskell.foundation (Bryan Richter) Date: Mon, 3 Jul 2023 14:15:30 +0300 Subject: GitLab CI happenings in July Message-ID: Hello, This is the first (and, perhaps, last[1]) monthly update on GitLab CI. This month in particular deserves its own little email for the following reasons: 1. Some of the Darwin runners recently spontaneously self-upgraded, introducing toolchain changes that broke CI. All the fixes are now on GHC's master branch. This leaves us with two choices: A) Re-enable the affected runners now. All current patches will have a 50% of failing CI because the old problems are still present. Users (you) can rebase your patches to avoid this problem. B) Wait before re-enabling the runners. All in-flight MRs have a better chance of getting green CI and/or organically getting rebased for other reasons. However, Darwin capacity would remain at 50% for longer, slowing down all pipelines. My current plan is to wait one week before re-enabling the runners, but ultimately it's not my call. Opinions welcome. 2. I will be on vacation from July 17 to July 28 (weeks 29 and 30). Please tell Marge to be good while I am away. 3. GitLab was recently upgraded. Please do not be alarmed by any UI changes. Enjoy! -Bryan [1]: Intuitively, I like the idea of giving monthly updates about GitLab CI. But I don't know if it will be practical or valuable. I'll take a look in a month to see if there's anything notable to write about again. -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.peytonjones at gmail.com Sun Jul 9 16:49:38 2023 From: simon.peytonjones at gmail.com (Simon Peyton Jones) Date: Sun, 9 Jul 2023 17:49:38 +0100 Subject: I can't build HEAD Message-ID: in a clean HEAD build, including "git submodule update", I get this. Can anyone help? Simon | Run Ar Pack (Stage0 InTreeLibs): _build/stage0/libraries/ghc-heap/build/cmm/cbits/HeapPrim.o (and 15 more) => _build/stage0/libraries/ghc-heap/build/libHSghc-heap-9.9-inplace.a ar: creating _build/stage0/libraries/ghc-heap/build/libHSghc-heap-9.9-inplace.a /-----------------------------------------------------------------------------\ | Successfully built library 'ghc-heap' (Stage0 InTreeLibs, way v). | | Library: _build/stage0/libraries/ghc-heap/build/libHSghc-heap-9.9-inplace.a | | Library synopsis: Functions for walking GHC's heap. | \-----------------------------------------------------------------------------/ ]0;Running for 2m35s [2621/2966], predicted 47s (77%) ]0;Running for 2m40s [2621/2966], predicted 47s (77%) ]0;Running for 2m45s [2621/2966], predicted 47s (77%) | Run Ghc CompileHs (Stage0 InTreeLibs): libraries/containers/containers/src/Data/Sequence/Internal/Sorting.hs => _build/stage0/libraries/containers/containers/build/Data/Sequence/Internal/Sorting.o | Run GhcPkg Unregister (Stage0 GlobalLibs): process => none | Run GhcPkg Update (Stage0 InTreeLibs): _build/stage0/libraries/exceptions/inplace-pkg-config => none | Copy package 'exceptions' # cabal-copy (for _build/stage0/lib/package.conf.d/exceptions-0.10.7-inplace.conf) # cabal-configure (for _build/stage0/libraries/text/setup-config) | Run GhcPkg Recache (Stage0 InTreeLibs): none => none hadrian: Encountered missing or private dependencies: data-array-byte >=0.1 && <0.2 ]0;Finished in 2m47s ExitFailure 1 Build failed. make: *** [/home/simonpj/code/Makefile-spj:10: all] Error 1 simonpj at CDW-8FABODHF0V5:~/code/HEAD$ -------------- next part -------------- An HTML attachment was scrubbed... URL: From ietf-dane at dukhovni.org Sun Jul 9 17:44:09 2023 From: ietf-dane at dukhovni.org (Viktor Dukhovni) Date: Sun, 9 Jul 2023 13:44:09 -0400 Subject: I can't build HEAD Message-ID: Spam detection software, running on the system "mail.haskell.org", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see @@CONTACT_ADDRESS@@ for details. Content preview: On Sun, Jul 09, 2023 at 05:49:38PM +0100, Simon Peyton Jones wrote: > in a clean HEAD build, including "git submodule update", I get this. > > Can anyone help? Did you run "cabal update"? What is your boot compiler version? [...] Content analysis details: (5.8 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -0.0 SPF_PASS SPF: sender matches SPF record 5.0 UNWANTED_LANGUAGE_BODY BODY: Message written in an undesired language 0.8 BAYES_50 BODY: Bayes spam probability is 40 to 60% [score: 0.4970] -------------- next part -------------- An embedded message was scrubbed... From: Viktor Dukhovni Subject: Re: I can't build HEAD Date: Sun, 9 Jul 2023 13:44:09 -0400 Size: 3210 URL: From ben at smart-cactus.org Sun Jul 9 17:48:21 2023 From: ben at smart-cactus.org (Ben Gamari) Date: Sun, 09 Jul 2023 13:48:21 -0400 Subject: I can't build HEAD In-Reply-To: References: Message-ID: <87a5w5m0wq.fsf@smart-cactus.org> Simon Peyton Jones writes: > in a clean HEAD build, including "git submodule update", I get this. > > Can anyone help? > Upgrade your bootstrap compiler to >= 9.4. We have now bumped HEAD's version to 9.8, which means that 9.4 is the earliest possible bootstrap compiler (which `text` now takes advantage of, as you see here). I have a patch bumping the `configure` check stewing in my 9.8 preparation branch. Cheers, - Ben From simon.peytonjones at gmail.com Sun Jul 9 20:52:39 2023 From: simon.peytonjones at gmail.com (Simon Peyton Jones) Date: Sun, 9 Jul 2023 21:52:39 +0100 Subject: I can't build HEAD In-Reply-To: <87a5w5m0wq.fsf@smart-cactus.org> References: <87a5w5m0wq.fsf@smart-cactus.org> Message-ID: > > Upgrade your bootstrap compiler to >= 9.4. We have now bumped HEAD's > version to 9.8, which means that 9.4 is the earliest possible bootstrap > compiler (which `text` now takes advantage of, as you see here). I have > Aha. I'll do that. You have to admit, the error message is not helpful :-). A suggestion for the future: when bumping the minimum bootstrap compiler, it would be possible (in the same commit) to fix configure to complain about too-early versions? Anyway I'm now building with 9.6, and doubtless that will be fine. Thanks. Simon On Sun, 9 Jul 2023 at 18:49, Ben Gamari wrote: > Simon Peyton Jones writes: > > > in a clean HEAD build, including "git submodule update", I get this. > > > > Can anyone help? > > > Upgrade your bootstrap compiler to >= 9.4. We have now bumped HEAD's > version to 9.8, which means that 9.4 is the earliest possible bootstrap > compiler (which `text` now takes advantage of, as you see here). I have > a patch bumping the `configure` check stewing in my 9.8 preparation > branch. > > Cheers, > > - Ben > -------------- next part -------------- An HTML attachment was scrubbed... URL: From benbellick at protonmail.com Sun Jul 9 21:46:23 2023 From: benbellick at protonmail.com (Ben Bellick) Date: Sun, 09 Jul 2023 21:46:23 +0000 Subject: JSON output of GHC Diagnostics Message-ID: Hey everyone, I am working on a summer of Haskell project to implement JSON output of GHC's diagnostics. I have begun working through some of the implementation details but have stumbled across a few road blocks and I wanted to get some feedback on. Discussion surrounding the plan can be found [here](https://github.com/haskellfoundation/tech-proposals/pull/50). In looking through the current implementation of the -ddump-json​ flag, I found a [note](https://gitlab.haskell.org/ghc/ghc/-/blob/master/compiler/GHC/Utils/Logger.hs#L392) which seems to indicate that a sensible (albeit invasive) approach is to alter the definition of [LogAction](https://gitlab.haskell.org/ghc/ghc/-/blob/master/compiler/GHC/Utils/Logger.hs#L174), reproduced below: type LogAction = LogFlags -> MessageClass -> SrcSpan -> SDoc -> IO () So instead of taking in an SDoc​, I could alter this signature to take a set of Diagnostic​s, though this may introduce other complications. In the first place, it seems log action is processing all of the diagnostics one at a time, though this particular JSON output should process all of them at once in order to place them all in a single JSON object. So, I am inclined to believe that this approach may not work. Another approach could be the one originally tried and mentioned in the note linked above, which is to keep track of all diagnostics in an IORef​, and use this to produce a final JSON result at the end of GHC's execution. This approach seems invasive in a different way. Does anyone familiar with the handling of diagnostics throughout the compiler have any suggestions on how best to implement such a feature? You can find the work that I have done so far [here](https://gitlab.haskell.org/benbellick/ghc/-/compare/master...json-diag-dump). All I am really doing is checking if the new flag is set in [printMessages](https://gitlab.haskell.org/benbellick/ghc/-/compare/master...json-diag-dump#2c680115d7e70b54a18c48be02dce2d676eaf4f8_17_18). If it is, then I simply invoke the json​ function of the ToJson​ typeclass and use that to print the diagnostic. It is currently a bit messy, but I wanted to just see if the path that I am taking seems fruitful or if there are any obvious hurdles that I am not seeing. Thanks so much! Best, Ben Bellick -------------- next part -------------- An HTML attachment was scrubbed... URL: From bryan at haskell.foundation Mon Jul 10 06:56:09 2023 From: bryan at haskell.foundation (Bryan Richter) Date: Mon, 10 Jul 2023 09:56:09 +0300 Subject: JSON output of GHC Diagnostics In-Reply-To: References: Message-ID: How feasible would it be to use something like https://jsonlines.org/ ? (In short, newline-delimited json values.) This could be in addition to any future single-json-value output format, or as a stepping stone to that goal. On Mon, 10 Jul 2023 at 00:46, Ben Bellick via ghc-devs wrote: > Hey everyone, > > I am working on a summer of Haskell project to implement JSON output of > GHC's diagnostics. I have begun working through some of the implementation > details but have stumbled across a few road blocks and I wanted to get some > feedback on. Discussion surrounding the plan can be found here > . > > In looking through the current implementation of the -ddump-json​ flag, I > found a note > > which seems to indicate that a sensible (albeit invasive) approach is to > alter the definition of LogAction > , > reproduced below: > > type LogAction = LogFlags -> MessageClass -> SrcSpan -> SDoc -> IO () > > So instead of taking in an SDoc​, I could alter this signature to take a > set of Diagnostic​s, though this may introduce other complications. In > the first place, it seems log action is processing all of the diagnostics > one at a time, though this particular JSON output should process all of > them at once in order to place them all in a single JSON object. So, I am > inclined to believe that this approach may not work. > > Another approach could be the one originally tried and mentioned in the > note linked above, which is to keep track of all diagnostics in an IORef​, > and use this to produce a final JSON result at the end of GHC's execution. > This approach seems invasive in a different way. > > Does anyone familiar with the handling of diagnostics throughout the > compiler have any suggestions on how best to implement such a feature? > > You can find the work that I have done so far here > . > All I am really doing is checking if the new flag is set in printMessages > . > If it is, then I simply invoke the json​ function of the ToJson​ > typeclass and use that to print the diagnostic. > > It is currently a bit messy, but I wanted to just see if the path that I > am taking seems fruitful or if there are any obvious hurdles that I am not > seeing. Thanks so much! > > Best, > Ben Bellick > _______________________________________________ > 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 matthewtpickering at gmail.com Mon Jul 10 08:55:53 2023 From: matthewtpickering at gmail.com (Matthew Pickering) Date: Mon, 10 Jul 2023 09:55:53 +0100 Subject: I can't build HEAD In-Reply-To: References: <87a5w5m0wq.fsf@smart-cactus.org> Message-ID: The ticket which tracks bumping the bootstrap compiler to 9.4 is https://gitlab.haskell.org/ghc/ghc/-/issues/23195 We should bump all the images and update the configure check *before* merging changes which require a newer bootstrap compiler. I imagine this problem has been introduced by https://gitlab.haskell.org/ghc/ghc/-/merge_requests/10827 so I will revert that commit for now until the relevant other parts have been updated. Cheers, Matt On Sun, Jul 9, 2023 at 9:53 PM Simon Peyton Jones wrote: >> >> Upgrade your bootstrap compiler to >= 9.4. We have now bumped HEAD's >> version to 9.8, which means that 9.4 is the earliest possible bootstrap >> compiler (which `text` now takes advantage of, as you see here). I have > > > Aha. I'll do that. > > You have to admit, the error message is not helpful :-). A suggestion for the future: when bumping the minimum bootstrap compiler, it would be possible (in the same commit) to fix configure to complain about too-early versions? > > Anyway I'm now building with 9.6, and doubtless that will be fine. Thanks. > > Simon > > > > On Sun, 9 Jul 2023 at 18:49, Ben Gamari wrote: >> >> Simon Peyton Jones writes: >> >> > in a clean HEAD build, including "git submodule update", I get this. >> > >> > Can anyone help? >> > >> Upgrade your bootstrap compiler to >= 9.4. We have now bumped HEAD's >> version to 9.8, which means that 9.4 is the earliest possible bootstrap >> compiler (which `text` now takes advantage of, as you see here). I have >> a patch bumping the `configure` check stewing in my 9.8 preparation >> branch. >> >> Cheers, >> >> - Ben > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs From oleg.grenrus at iki.fi Mon Jul 10 09:09:25 2023 From: oleg.grenrus at iki.fi (Oleg Grenrus) Date: Mon, 10 Jul 2023 12:09:25 +0300 Subject: I can't build HEAD In-Reply-To: References: <87a5w5m0wq.fsf@smart-cactus.org> Message-ID: <1c96fdcb-d9e3-bd41-3db6-c9ec00eee326@iki.fi> Thank you Matt for being strict This kind of issue have bitten me in the past e.g. - https://gitlab.haskell.org/ghc/ghc/-/issues/22450 - https://gitlab.haskell.org/ghc/ghc/-/issues/22245 So I really welcome the change in policy - Oleg On 10.7.2023 11.55, Matthew Pickering wrote: > The ticket which tracks bumping the bootstrap compiler to 9.4 is > https://gitlab.haskell.org/ghc/ghc/-/issues/23195 > > We should bump all the images and update the configure check *before* > merging changes which require a newer bootstrap compiler. > > I imagine this problem has been introduced by > https://gitlab.haskell.org/ghc/ghc/-/merge_requests/10827 so I will > revert that commit for now until the relevant other parts have been > updated. > > Cheers, > > Matt > > On Sun, Jul 9, 2023 at 9:53 PM Simon Peyton Jones > wrote: >>> Upgrade your bootstrap compiler to >= 9.4. We have now bumped HEAD's >>> version to 9.8, which means that 9.4 is the earliest possible bootstrap >>> compiler (which `text` now takes advantage of, as you see here). I have >> >> Aha. I'll do that. >> >> You have to admit, the error message is not helpful :-). A suggestion for the future: when bumping the minimum bootstrap compiler, it would be possible (in the same commit) to fix configure to complain about too-early versions? >> >> Anyway I'm now building with 9.6, and doubtless that will be fine. Thanks. >> >> Simon >> >> >> >> On Sun, 9 Jul 2023 at 18:49, Ben Gamari wrote: >>> Simon Peyton Jones writes: >>> >>>> in a clean HEAD build, including "git submodule update", I get this. >>>> >>>> Can anyone help? >>>> >>> Upgrade your bootstrap compiler to >= 9.4. We have now bumped HEAD's >>> version to 9.8, which means that 9.4 is the earliest possible bootstrap >>> compiler (which `text` now takes advantage of, as you see here). I have >>> a patch bumping the `configure` check stewing in my 9.8 preparation >>> branch. >>> >>> Cheers, >>> >>> - Ben >> _______________________________________________ >> 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 ben at smart-cactus.org Mon Jul 10 14:24:26 2023 From: ben at smart-cactus.org (Ben Gamari) Date: Mon, 10 Jul 2023 10:24:26 -0400 Subject: JSON output of GHC Diagnostics In-Reply-To: References: Message-ID: <87ttubzvxh.fsf@smart-cactus.org> Ben Bellick via ghc-devs writes: > Hey everyone, > > I am working on a summer of Haskell project to implement JSON output of GHC's diagnostics. I have begun working through some of the implementation details but have stumbled across a few road blocks and I wanted to get some feedback on. Discussion surrounding the plan can be found [here](https://github.com/haskellfoundation/tech-proposals/pull/50). > > In looking through the current implementation of the -ddump-json​ flag, I found a [note](https://gitlab.haskell.org/ghc/ghc/-/blob/master/compiler/GHC/Utils/Logger.hs#L392) which seems to indicate that a sensible (albeit invasive) approach is to alter the definition of [LogAction](https://gitlab.haskell.org/ghc/ghc/-/blob/master/compiler/GHC/Utils/Logger.hs#L174), reproduced below: > ... > > So instead of taking in an SDoc​, I could alter this signature to take > a set of Diagnostic​s, though this may introduce other complications. > In the first place, it seems log action is processing all of the > diagnostics one at a time, though this particular JSON output should > process all of them at once in order to place them all in a single > JSON object. So, I am inclined to believe that this approach may not > work. > Taking all of the diagnostics at once is possible (and, with the addition of internal state, could even be done without changing the LogAction type). However, it would mean that downstream users wouldn't benefit from incremental reporting of errors. I don't honestly know whether how much value such incrementality has to the typical consumers you have in mind, but I think it could be easily preserved with something like the JSON Lines approach that Bryan suggests. Admittedly, this would be a change in the semantics of -ddump-json but I don't consider this to be a problem. Frankly, `-d` flags are intended primarily for debugging and are generally not considered to be stable interfaces. In fact, if we are going to improve the JSON output, I think we should probably rename the flag to something in the `-f` namespace and deprecate the old `-d` flag. Cheers, - Ben From ryan.gl.scott at gmail.com Mon Jul 10 22:34:53 2023 From: ryan.gl.scott at gmail.com (Ryan Scott) Date: Mon, 10 Jul 2023 18:34:53 -0400 Subject: Call for Talks: Haskell Implementors' Workshop 2023 (deadline extension) Message-ID: TL;DR: The submission deadline for the 2023 Haskell Implementors' Workshop has been extended to June 16. ================================== 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 16, 2023 (AoE) (extended) 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://icfp-hiw23.hotcrp.com until July 16 (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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From ryan.gl.scott at gmail.com Mon Jul 10 22:40:16 2023 From: ryan.gl.scott at gmail.com (Ryan Scott) Date: Mon, 10 Jul 2023 18:40:16 -0400 Subject: Call for Talks: Haskell Implementors' Workshop 2023 (deadline extension) In-Reply-To: References: Message-ID: Apologies, that should read *July* 16, not June 16, for the submission deadline at the top of the email. (The body of the email contains the correct date.) Best, Ryan On Mon, Jul 10, 2023 at 6:34 PM Ryan Scott wrote: > TL;DR: The submission deadline for the 2023 Haskell Implementors' Workshop > has been extended to June 16. > > ================================== > > 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 16, 2023 (AoE) (extended) > 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://icfp-hiw23.hotcrp.com > until July 16 (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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From gergo at erdi.hu Wed Jul 12 03:40:25 2023 From: gergo at erdi.hu (=?UTF-8?B?R2VyZ8WRIMOJcmRp?=) Date: Wed, 12 Jul 2023 11:40:25 +0800 Subject: Usage of Template Haskell quotes in GHC source tree vs. usage of GHC as a library In-Reply-To: References: Message-ID: Hi, A recent commit 983ce55815f2dd57f84ee86eee97febf7d80b470 starts using TemplateHaskellQuotes in the GHC codebase. It seems this is at odds with using GHC as a library, a la ghc-lib. The `ghc-lib` approach is to basically take the module hierarchy from the `compiler/` subtree, and compile it as a completely vanilla Haskell library, with no direct attachment to the host GHC version. This enables using e.g. GHC 9.4 to compile a program using the GHC 9.6 API, and so on. In particular, it also makes it very easy to apply patches to the version of GHC used as a library, since in this setup it doesn’t need to be able to bootstrap. So what is the problem with using TemplateHaskellQuotes? The problem is the dependency on the template-haskell package. When a module inside GHC-as-a-library containing TH quotes is compiled, the quotes are translated into applications of the constructors defined by the *host* GHC’s TH package. But because GHC is tightly coupled to the TH support library, GHC-as-a-library needs to ship with its own internal version of the library. So the code that tries to process the results of these quotes is using the *target* GHC’s TH definitions. And that leads to a conflict: code like leftName :: Namel leftName = ‘Left is now a type mismatch between the type of `’Left` being template-haskell-2.19.0.0:Language.Haskell.TH.Syntax.Name (example when using GHC 9.4.5 as the host) and the type of `leftName` being ghc-lib-9.9.20230712:Language.Haskell.TH.Syntax.Name (example when the target version is built from recent `master`). Currently, `ghc-lib-gen` has a pre-processing step on the GHC source tree that replaces these quotations with applications containing direct references to the target TH constructors: https://github.com/digital-asset/ghc-lib/blob/ab01fb2b4d1e3a9338390e9c10ccd769bbf37aeb/ghc-lib-gen/src/Ghclibgen.hs#L419-L467 but I am worried that this is very fragile. So any ideas on how to tackle this situation better? Thanks, Gergo -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.peytonjones at gmail.com Wed Jul 12 11:25:14 2023 From: simon.peytonjones at gmail.com (Simon Peyton Jones) Date: Wed, 12 Jul 2023 12:25:14 +0100 Subject: Usage of Template Haskell quotes in GHC source tree vs. usage of GHC as a library In-Reply-To: References: Message-ID: Gergo I'm not close enough to this to have a well-formed opinion, but it looks like a good question to me, esp if the new dependence on TH is optional. Would you like to transfer the text into a GHC ticket? Simon On Wed, 12 Jul 2023 at 04:40, Gergő Érdi wrote: > Hi, > > > > A recent commit 983ce55815f2dd57f84ee86eee97febf7d80b470 starts using > TemplateHaskellQuotes in the GHC codebase. It seems this is at odds with > using GHC as a library, a la ghc-lib. > > > > The `ghc-lib` approach is to basically take the module hierarchy from the > `compiler/` subtree, and compile it as a completely vanilla Haskell > library, with no direct attachment to the host GHC version. This enables > using e.g. GHC 9.4 to compile a program using the GHC 9.6 API, and so on. > In particular, it also makes it very easy to apply patches to the version > of GHC used as a library, since in this setup it doesn’t need to be able to > bootstrap. > > > > So what is the problem with using TemplateHaskellQuotes? The problem is > the dependency on the template-haskell package. When a module inside > GHC-as-a-library containing TH quotes is compiled, the quotes are > translated into applications of the constructors defined by the *host* > GHC’s TH package. But because GHC is tightly coupled to the TH support > library, GHC-as-a-library needs to ship with its own internal version of > the library. So the code that tries to process the results of these quotes > is using the *target* GHC’s TH definitions. And that leads to a conflict: > code like > > > > leftName :: Namel > > leftName = ‘Left > > > is now a type mismatch between the type of `’Left` being > template-haskell-2.19.0.0:Language.Haskell.TH.Syntax.Name (example when > using GHC 9.4.5 as the host) and the type of `leftName` being > ghc-lib-9.9.20230712:Language.Haskell.TH.Syntax.Name (example when the > target version is built from recent `master`). > > > > Currently, `ghc-lib-gen` has a pre-processing step on the GHC source tree > that replaces these quotations with applications containing direct > references to the target TH constructors: > https://github.com/digital-asset/ghc-lib/blob/ab01fb2b4d1e3a9338390e9c10ccd769bbf37aeb/ghc-lib-gen/src/Ghclibgen.hs#L419-L467 > but I am worried that this is very fragile. > > > > So any ideas on how to tackle this situation better? > > > > Thanks, > > Gergo > _______________________________________________ > 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 simon.peytonjones at gmail.com Wed Jul 12 11:38:50 2023 From: simon.peytonjones at gmail.com (Simon Peyton Jones) Date: Wed, 12 Jul 2023 12:38:50 +0100 Subject: Can't build nofib Message-ID: Friends With a clean HEAD I can't build nofib. See below. What should I do? Thanks Simon (cd nofib; cabal v2-run -- nofib-run --compiler=`pwd`/../_build/stage1/bin/ghc --output=`date -I`) Resolving dependencies... Error: cabal: Could not resolve dependencies: [__0] trying: nofib-0.1.0.0 (user goal) [__1] next goal: base (dependency of nofib) [__1] rejecting: base-4.18.0.0/installed-4.18.0.0 (conflict: nofib => base>=4.5 && <4.17) [__1] skipping: base-4.18.0.0, base-4.17.1.0, base-4.17.0.0 (has the same characteristics that caused the previous version to fail: excluded by constraint '>=4.5 && <4.17' from 'nofib') [__1] rejecting: base-4.16.4.0, base-4.16.3.0, base-4.16.2.0, base-4.16.1.0, base-4.16.0.0, base-4.15.1.0, base-4.15.0.0, base-4.14.3.0, base-4.14.2.0, base-4.14.1.0, base-4.14.0.0, base-4.13.0.0, base-4.12.0.0, base-4.11.1.0, base-4.11.0.0, base-4.10.1.0, base-4.10.0.0, base-4.9.1.0, base-4.9.0.0, base-4.8.2.0, base-4.8.1.0, base-4.8.0.0, base-4.7.0.2, base-4.7.0.1, base-4.7.0.0, base-4.6.0.1, base-4.6.0.0, base-4.5.1.0, base-4.5.0.0, base-4.4.1.0, base-4.4.0.0, base-4.3.1.0, base-4.3.0.0, base-4.2.0.2, base-4.2.0.1, base-4.2.0.0, base-4.1.0.0, base-4.0.0.0, base-3.0.3.2, base-3.0.3.1 (constraint from non-upgradeable package requires installed instance) [__1] fail (backjumping, conflict set: base, nofib) After searching the rest of the dependency tree exhaustively, these were the goals I've had most trouble fulfilling: base, nofib make: *** [/home/simonpj/code/Makefile-spj:39: nofib] Error 1 -------------- next part -------------- An HTML attachment was scrubbed... URL: From klebinger.andreas at gmx.at Wed Jul 12 11:40:41 2023 From: klebinger.andreas at gmx.at (Andreas Klebinger) Date: Wed, 12 Jul 2023 13:40:41 +0200 Subject: Can't build nofib In-Reply-To: References: Message-ID: <1a8a89a9-b4f2-5491-ebe7-9477fe3dbe5f@gmx.at> Try adding --allow-newer we probably just haven't updated the bounds yet. (cd nofib; cabal v2-run --allow-newer -- nofib-run --compiler=`pwd`/../_build/stage1/bin/ghc --output=`date -I`) Am 12/07/2023 um 13:38 schrieb Simon Peyton Jones: > Friends > > With a clean HEAD I can't build nofib.  See below.  What should I do? > > Thanks > > Simon > > (cd nofib; cabal v2-run -- nofib-run > --compiler=`pwd`/../_build/stage1/bin/ghc --output=`date -I`) > Resolving dependencies... > Error: cabal: Could not resolve dependencies: > [__0] trying: nofib-0.1.0.0 (user goal) > [__1] next goal: base (dependency of nofib) > [__1] rejecting: base-4.18.0.0/installed-4.18.0.0 (conflict: nofib => > base>=4.5 && <4.17) > [__1] skipping: base-4.18.0.0, base-4.17.1.0, base-4.17.0.0 (has the same > characteristics that caused the previous version to fail: excluded by > constraint '>=4.5 && <4.17' from 'nofib') > [__1] rejecting: base-4.16.4.0, base-4.16.3.0, base-4.16.2.0, > base-4.16.1.0, > base-4.16.0.0, base-4.15.1.0, base-4.15.0.0, base-4.14.3.0, base-4.14.2.0, > base-4.14.1.0, base-4.14.0.0, base-4.13.0.0, base-4.12.0.0, base-4.11.1.0, > base-4.11.0.0, base-4.10.1.0, base-4.10.0.0, base-4.9.1.0, base-4.9.0.0, > base-4.8.2.0, base-4.8.1.0, base-4.8.0.0, base-4.7.0.2, base-4.7.0.1, > base-4.7.0.0, base-4.6.0.1, base-4.6.0.0, base-4.5.1.0, base-4.5.0.0, > base-4.4.1.0, base-4.4.0.0, base-4.3.1.0, base-4.3.0.0, base-4.2.0.2, > base-4.2.0.1, base-4.2.0.0, base-4.1.0.0, base-4.0.0.0, base-3.0.3.2, > base-3.0.3.1 (constraint from non-upgradeable package requires installed > instance) > [__1] fail (backjumping, conflict set: base, nofib) > After searching the rest of the dependency tree exhaustively, these > were the > goals I've had most trouble fulfilling: base, nofib > > make: *** [/home/simonpj/code/Makefile-spj:39: nofib] Error 1 > > > _______________________________________________ > 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 rodrigo.m.mesquita at gmail.com Wed Jul 12 11:41:23 2023 From: rodrigo.m.mesquita at gmail.com (Rodrigo Mesquita) Date: Wed, 12 Jul 2023 12:41:23 +0100 Subject: Can't build nofib In-Reply-To: References: Message-ID: <05C5D3C3-60F6-465C-8E38-A2C057619B9F@gmail.com> From the error message it looks like you’re using ghc-9.6(and base 4.18) while nofib requires base < 4.17. I’d say as a temporary workaround you can likely run your invocation additionally with —allow-newer, and hope that doesn’t break. Otherwise you could downgrade to 9.4 or bump the version manually in the cabal file of nofib? Rodrigo > On 12 Jul 2023, at 12:38, Simon Peyton Jones wrote: > > Friends > > With a clean HEAD I can't build nofib. See below. What should I do? > > Thanks > > Simon > > (cd nofib; cabal v2-run -- nofib-run --compiler=`pwd`/../_build/stage1/bin/ghc --output=`date -I`) > Resolving dependencies... > Error: cabal: Could not resolve dependencies: > [__0] trying: nofib-0.1.0.0 (user goal) > [__1] next goal: base (dependency of nofib) > [__1] rejecting: base-4.18.0.0/installed-4.18.0.0 (conflict: nofib => > base>=4.5 && <4.17) > [__1] skipping: base-4.18.0.0, base-4.17.1.0, base-4.17.0.0 (has the same > characteristics that caused the previous version to fail: excluded by > constraint '>=4.5 && <4.17' from 'nofib') > [__1] rejecting: base-4.16.4.0, base-4.16.3.0, base-4.16.2.0, base-4.16.1.0, > base-4.16.0.0, base-4.15.1.0, base-4.15.0.0, base-4.14.3.0, base-4.14.2.0, > base-4.14.1.0, base-4.14.0.0, base-4.13.0.0, base-4.12.0.0, base-4.11.1.0, > base-4.11.0.0, base-4.10.1.0, base-4.10.0.0, base-4.9.1.0, base-4.9.0.0, > base-4.8.2.0, base-4.8.1.0, base-4.8.0.0, base-4.7.0.2, base-4.7.0.1, > base-4.7.0.0, base-4.6.0.1, base-4.6.0.0, base-4.5.1.0, base-4.5.0.0, > base-4.4.1.0, base-4.4.0.0, base-4.3.1.0, base-4.3.0.0, base-4.2.0.2, > base-4.2.0.1, base-4.2.0.0, base-4.1.0.0, base-4.0.0.0, base-3.0.3.2, > base-3.0.3.1 (constraint from non-upgradeable package requires installed > instance) > [__1] fail (backjumping, conflict set: base, nofib) > After searching the rest of the dependency tree exhaustively, these were the > goals I've had most trouble fulfilling: base, nofib > > make: *** [/home/simonpj/code/Makefile-spj:39: nofib] Error 1 > > _______________________________________________ > 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 simon.peytonjones at gmail.com Wed Jul 12 11:48:14 2023 From: simon.peytonjones at gmail.com (Simon Peyton Jones) Date: Wed, 12 Jul 2023 12:48:14 +0100 Subject: Can't build nofib In-Reply-To: <05C5D3C3-60F6-465C-8E38-A2C057619B9F@gmail.com> References: <05C5D3C3-60F6-465C-8E38-A2C057619B9F@gmail.com> Message-ID: Thanks. That is very unfortunate: ./configure does not issue any complaint. I upgraded from 9.2 because GHC won't compile with 9.2 any more. But now you are saying that nofib won't build with 9.6? So that leaves 9.4 only. Well I can install 9.4 and rebuild everything. But really, it would be good if configure complained if you are using a boot compiler that won't work. That's what configure is for! Simon On Wed, 12 Jul 2023 at 12:41, Rodrigo Mesquita wrote: > From the error message it looks like you’re using ghc-9.6(and base 4.18) > while nofib requires base < 4.17. > I’d say as a temporary workaround you can likely run your invocation > additionally with —allow-newer, and hope that doesn’t break. Otherwise you > could downgrade to 9.4 or bump the version manually in the cabal file of > nofib? > > Rodrigo > > On 12 Jul 2023, at 12:38, Simon Peyton Jones > wrote: > > Friends > > With a clean HEAD I can't build nofib. See below. What should I do? > > Thanks > > Simon > > (cd nofib; cabal v2-run -- nofib-run > --compiler=`pwd`/../_build/stage1/bin/ghc --output=`date -I`) > Resolving dependencies... > Error: cabal: Could not resolve dependencies: > [__0] trying: nofib-0.1.0.0 (user goal) > [__1] next goal: base (dependency of nofib) > [__1] rejecting: base-4.18.0.0/installed-4.18.0.0 (conflict: nofib => > base>=4.5 && <4.17) > [__1] skipping: base-4.18.0.0, base-4.17.1.0, base-4.17.0.0 (has the same > characteristics that caused the previous version to fail: excluded by > constraint '>=4.5 && <4.17' from 'nofib') > [__1] rejecting: base-4.16.4.0, base-4.16.3.0, base-4.16.2.0, > base-4.16.1.0, > base-4.16.0.0, base-4.15.1.0, base-4.15.0.0, base-4.14.3.0, base-4.14.2.0, > base-4.14.1.0, base-4.14.0.0, base-4.13.0.0, base-4.12.0.0, base-4.11.1.0, > base-4.11.0.0, base-4.10.1.0, base-4.10.0.0, base-4.9.1.0, base-4.9.0.0, > base-4.8.2.0, base-4.8.1.0, base-4.8.0.0, base-4.7.0.2, base-4.7.0.1, > base-4.7.0.0, base-4.6.0.1, base-4.6.0.0, base-4.5.1.0, base-4.5.0.0, > base-4.4.1.0, base-4.4.0.0, base-4.3.1.0, base-4.3.0.0, base-4.2.0.2, > base-4.2.0.1, base-4.2.0.0, base-4.1.0.0, base-4.0.0.0, base-3.0.3.2, > base-3.0.3.1 (constraint from non-upgradeable package requires installed > instance) > [__1] fail (backjumping, conflict set: base, nofib) > After searching the rest of the dependency tree exhaustively, these were > the > goals I've had most trouble fulfilling: base, nofib > > make: *** [/home/simonpj/code/Makefile-spj:39: nofib] Error 1 > > _______________________________________________ > 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 rodrigo.m.mesquita at gmail.com Wed Jul 12 11:49:55 2023 From: rodrigo.m.mesquita at gmail.com (Rodrigo Mesquita) Date: Wed, 12 Jul 2023 12:49:55 +0100 Subject: Can't build nofib In-Reply-To: References: <05C5D3C3-60F6-465C-8E38-A2C057619B9F@gmail.com> Message-ID: I would recommend —allow-newer rather than rebuilding with 9.4. In retrospect, 9.4 implies base == 4.17, but nofib seems to only allow < 4.17, which would leave 9.4 out. Rodrigo > On 12 Jul 2023, at 12:48, Simon Peyton Jones wrote: > > Thanks. That is very unfortunate: ./configure does not issue any complaint. > > I upgraded from 9.2 because GHC won't compile with 9.2 any more. But now you are saying that nofib won't build with 9.6? So that leaves 9.4 only. > > Well I can install 9.4 and rebuild everything. But really, it would be good if configure complained if you are using a boot compiler that won't work. That's what configure is for! > > Simon > > On Wed, 12 Jul 2023 at 12:41, Rodrigo Mesquita > wrote: >> From the error message it looks like you’re using ghc-9.6(and base 4.18) while nofib requires base < 4.17. >> I’d say as a temporary workaround you can likely run your invocation additionally with —allow-newer, and hope that doesn’t break. Otherwise you could downgrade to 9.4 or bump the version manually in the cabal file of nofib? >> >> Rodrigo >> >>> On 12 Jul 2023, at 12:38, Simon Peyton Jones > wrote: >>> >>> Friends >>> >>> With a clean HEAD I can't build nofib. See below. What should I do? >>> >>> Thanks >>> >>> Simon >>> >>> (cd nofib; cabal v2-run -- nofib-run --compiler=`pwd`/../_build/stage1/bin/ghc --output=`date -I`) >>> Resolving dependencies... >>> Error: cabal: Could not resolve dependencies: >>> [__0] trying: nofib-0.1.0.0 (user goal) >>> [__1] next goal: base (dependency of nofib) >>> [__1] rejecting: base-4.18.0.0/installed-4.18.0.0 (conflict: nofib => >>> base>=4.5 && <4.17) >>> [__1] skipping: base-4.18.0.0, base-4.17.1.0, base-4.17.0.0 (has the same >>> characteristics that caused the previous version to fail: excluded by >>> constraint '>=4.5 && <4.17' from 'nofib') >>> [__1] rejecting: base-4.16.4.0, base-4.16.3.0, base-4.16.2.0, base-4.16.1.0, >>> base-4.16.0.0, base-4.15.1.0, base-4.15.0.0, base-4.14.3.0, base-4.14.2.0, >>> base-4.14.1.0, base-4.14.0.0, base-4.13.0.0, base-4.12.0.0, base-4.11.1.0, >>> base-4.11.0.0, base-4.10.1.0, base-4.10.0.0, base-4.9.1.0, base-4.9.0.0, >>> base-4.8.2.0, base-4.8.1.0, base-4.8.0.0, base-4.7.0.2, base-4.7.0.1, >>> base-4.7.0.0, base-4.6.0.1, base-4.6.0.0, base-4.5.1.0, base-4.5.0.0, >>> base-4.4.1.0, base-4.4.0.0, base-4.3.1.0, base-4.3.0.0, base-4.2.0.2, >>> base-4.2.0.1, base-4.2.0.0, base-4.1.0.0, base-4.0.0.0, base-3.0.3.2, >>> base-3.0.3.1 (constraint from non-upgradeable package requires installed >>> instance) >>> [__1] fail (backjumping, conflict set: base, nofib) >>> After searching the rest of the dependency tree exhaustively, these were the >>> goals I've had most trouble fulfilling: base, nofib >>> >>> make: *** [/home/simonpj/code/Makefile-spj:39: nofib] Error 1 >>> >>> _______________________________________________ >>> 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 klebinger.andreas at gmx.at Wed Jul 12 12:17:34 2023 From: klebinger.andreas at gmx.at (Andreas Klebinger) Date: Wed, 12 Jul 2023 14:17:34 +0200 Subject: Can't build nofib In-Reply-To: References: <05C5D3C3-60F6-465C-8E38-A2C057619B9F@gmail.com> Message-ID: <35ee8286-3971-92c0-3b4c-5330419763ea@gmx.at> The nofib master branch has updated bounds. It's just ghcs submodule that's lagging behind. Am 12/07/2023 um 13:49 schrieb Rodrigo Mesquita: > I would recommend —allow-newer rather than rebuilding with 9.4. In > retrospect, 9.4 implies base == 4.17, but nofib seems to only allow < > 4.17, which would leave 9.4 out. > > Rodrigo > >> On 12 Jul 2023, at 12:48, Simon Peyton Jones >> wrote: >> >> Thanks.  That is very unfortunate: ./configure does not issue any >> complaint. >> >> I upgraded from 9.2 because GHC won't compile with 9.2 any more.  But >> now you are saying that nofib won't build with 9.6? So that leaves >> 9.4 only. >> >> Well I can install 9.4 and rebuild everything.  But really, it would >> be good if configure complained if you are using a boot compiler that >> won't work.  That's what configure is for! >> >> Simon >> >> On Wed, 12 Jul 2023 at 12:41, Rodrigo Mesquita >> wrote: >> >> From the error message it looks like you’re using ghc-9.6(and >> base 4.18) while nofib requires base < 4.17. >> I’d say as a temporary workaround you can likely run your >> invocation additionally with —allow-newer, and hope that doesn’t >> break. Otherwise you could downgrade to 9.4 or bump the version >> manually in the cabal file of nofib? >> >> Rodrigo >> >>> On 12 Jul 2023, at 12:38, Simon Peyton Jones >>> wrote: >>> >>> Friends >>> >>> With a clean HEAD I can't build nofib.  See below.  What should >>> I do? >>> >>> Thanks >>> >>> Simon >>> >>> (cd nofib; cabal v2-run -- nofib-run >>> --compiler=`pwd`/../_build/stage1/bin/ghc --output=`date -I`) >>> Resolving dependencies... >>> Error: cabal: Could not resolve dependencies: >>> [__0] trying: nofib-0.1.0.0 (user goal) >>> [__1] next goal: base (dependency of nofib) >>> [__1] rejecting: base-4.18.0.0/installed-4.18.0.0 (conflict: >>> nofib => >>> base>=4.5 && <4.17) >>> [__1] skipping: base-4.18.0.0, base-4.17.1.0, base-4.17.0.0 (has >>> the same >>> characteristics that caused the previous version to fail: >>> excluded by >>> constraint '>=4.5 && <4.17' from 'nofib') >>> [__1] rejecting: base-4.16.4.0, base-4.16.3.0, base-4.16.2.0, >>> base-4.16.1.0, >>> base-4.16.0.0, base-4.15.1.0, base-4.15.0.0, base-4.14.3.0, >>> base-4.14.2.0, >>> base-4.14.1.0, base-4.14.0.0, base-4.13.0.0, base-4.12.0.0, >>> base-4.11.1.0, >>> base-4.11.0.0, base-4.10.1.0, base-4.10.0.0, base-4.9.1.0, >>> base-4.9.0.0, >>> base-4.8.2.0, base-4.8.1.0, base-4.8.0.0, base-4.7.0.2, >>> base-4.7.0.1, >>> base-4.7.0.0, base-4.6.0.1, base-4.6.0.0, base-4.5.1.0, >>> base-4.5.0.0, >>> base-4.4.1.0, base-4.4.0.0, base-4.3.1.0, base-4.3.0.0, >>> base-4.2.0.2, >>> base-4.2.0.1, base-4.2.0.0, base-4.1.0.0, base-4.0.0.0, >>> base-3.0.3.2, >>> base-3.0.3.1 (constraint from non-upgradeable package requires >>> installed >>> instance) >>> [__1] fail (backjumping, conflict set: base, nofib) >>> After searching the rest of the dependency tree exhaustively, >>> these were the >>> goals I've had most trouble fulfilling: base, nofib >>> >>> make: *** [/home/simonpj/code/Makefile-spj:39: nofib] Error 1 >>> >>> _______________________________________________ >>> 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 simon.peytonjones at gmail.com Wed Jul 12 13:25:51 2023 From: simon.peytonjones at gmail.com (Simon Peyton Jones) Date: Wed, 12 Jul 2023 14:25:51 +0100 Subject: Can't build nofib In-Reply-To: References: <05C5D3C3-60F6-465C-8E38-A2C057619B9F@gmail.com> Message-ID: > > I would recommend —allow-newer rather than rebuilding with 9.4. In > retrospect, 9.4 implies base == 4.17, but nofib seems to only allow < 4.17, > which would leave 9.4 out. Oh wow -- so there is *no* version of GHC that works as a bootstrap GHC. That seems bad. Very bad. I see a patch from Andreas -- maybe that fixes it? Meanwhile, --allow-newer I guess. Simon On Wed, 12 Jul 2023 at 12:50, Rodrigo Mesquita wrote: > I would recommend —allow-newer rather than rebuilding with 9.4. In > retrospect, 9.4 implies base == 4.17, but nofib seems to only allow < 4.17, > which would leave 9.4 out. > > Rodrigo > > On 12 Jul 2023, at 12:48, Simon Peyton Jones > wrote: > > Thanks. That is very unfortunate: ./configure does not issue any > complaint. > > I upgraded from 9.2 because GHC won't compile with 9.2 any more. But now > you are saying that nofib won't build with 9.6? So that leaves 9.4 only. > > Well I can install 9.4 and rebuild everything. But really, it would be > good if configure complained if you are using a boot compiler that won't > work. That's what configure is for! > > Simon > > On Wed, 12 Jul 2023 at 12:41, Rodrigo Mesquita < > rodrigo.m.mesquita at gmail.com> wrote: > >> From the error message it looks like you’re using ghc-9.6(and base 4.18) >> while nofib requires base < 4.17. >> I’d say as a temporary workaround you can likely run your invocation >> additionally with —allow-newer, and hope that doesn’t break. Otherwise you >> could downgrade to 9.4 or bump the version manually in the cabal file of >> nofib? >> >> Rodrigo >> >> On 12 Jul 2023, at 12:38, Simon Peyton Jones >> wrote: >> >> Friends >> >> With a clean HEAD I can't build nofib. See below. What should I do? >> >> Thanks >> >> Simon >> >> (cd nofib; cabal v2-run -- nofib-run >> --compiler=`pwd`/../_build/stage1/bin/ghc --output=`date -I`) >> Resolving dependencies... >> Error: cabal: Could not resolve dependencies: >> [__0] trying: nofib-0.1.0.0 (user goal) >> [__1] next goal: base (dependency of nofib) >> [__1] rejecting: base-4.18.0.0/installed-4.18.0.0 (conflict: nofib => >> base>=4.5 && <4.17) >> [__1] skipping: base-4.18.0.0, base-4.17.1.0, base-4.17.0.0 (has the same >> characteristics that caused the previous version to fail: excluded by >> constraint '>=4.5 && <4.17' from 'nofib') >> [__1] rejecting: base-4.16.4.0, base-4.16.3.0, base-4.16.2.0, >> base-4.16.1.0, >> base-4.16.0.0, base-4.15.1.0, base-4.15.0.0, base-4.14.3.0, base-4.14.2.0, >> base-4.14.1.0, base-4.14.0.0, base-4.13.0.0, base-4.12.0.0, base-4.11.1.0, >> base-4.11.0.0, base-4.10.1.0, base-4.10.0.0, base-4.9.1.0, base-4.9.0.0, >> base-4.8.2.0, base-4.8.1.0, base-4.8.0.0, base-4.7.0.2, base-4.7.0.1, >> base-4.7.0.0, base-4.6.0.1, base-4.6.0.0, base-4.5.1.0, base-4.5.0.0, >> base-4.4.1.0, base-4.4.0.0, base-4.3.1.0, base-4.3.0.0, base-4.2.0.2, >> base-4.2.0.1, base-4.2.0.0, base-4.1.0.0, base-4.0.0.0, base-3.0.3.2, >> base-3.0.3.1 (constraint from non-upgradeable package requires installed >> instance) >> [__1] fail (backjumping, conflict set: base, nofib) >> After searching the rest of the dependency tree exhaustively, these were >> the >> goals I've had most trouble fulfilling: base, nofib >> >> make: *** [/home/simonpj/code/Makefile-spj:39: nofib] Error 1 >> >> _______________________________________________ >> 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 Gergo.Erdi at sc.com Thu Jul 13 06:04:14 2023 From: Gergo.Erdi at sc.com (Erdi, Gergo) Date: Thu, 13 Jul 2023 06:04:14 +0000 Subject: [External] Re: Usage of Template Haskell quotes in GHC source tree vs. usage of GHC as a library In-Reply-To: References: Message-ID: PUBLIC https://gitlab.haskell.org/ghc/ghc/-/issues/23647 From: ghc-devs On Behalf Of Simon Peyton Jones Sent: Wednesday, July 12, 2023 7:25 PM To: Gergő Érdi Cc: GHC Devs Subject: [External] Re: Usage of Template Haskell quotes in GHC source tree vs. usage of GHC as a library ATTENTION: This email came from an external source. Do not open attachments or click on links from unknown senders or unexpected emails. Always report suspicious emails using the Report As Phishing button in Outlook to protect the Bank and our clients. Gergo I'm not close enough to this to have a well-formed opinion, but it looks like a good question to me, esp if the new dependence on TH is optional. Would you like to transfer the text into a GHC ticket? Simon On Wed, 12 Jul 2023 at 04:40, Gergő Érdi > wrote: Hi, A recent commit 983ce55815f2dd57f84ee86eee97febf7d80b470 starts using TemplateHaskellQuotes in the GHC codebase. It seems this is at odds with using GHC as a library, a la ghc-lib. The `ghc-lib` approach is to basically take the module hierarchy from the `compiler/` subtree, and compile it as a completely vanilla Haskell library, with no direct attachment to the host GHC version. This enables using e.g. GHC 9.4 to compile a program using the GHC 9.6 API, and so on. In particular, it also makes it very easy to apply patches to the version of GHC used as a library, since in this setup it doesn't need to be able to bootstrap. So what is the problem with using TemplateHaskellQuotes? The problem is the dependency on the template-haskell package. When a module inside GHC-as-a-library containing TH quotes is compiled, the quotes are translated into applications of the constructors defined by the *host* GHC's TH package. But because GHC is tightly coupled to the TH support library, GHC-as-a-library needs to ship with its own internal version of the library. So the code that tries to process the results of these quotes is using the *target* GHC's TH definitions. And that leads to a conflict: code like leftName :: Namel leftName = 'Left is now a type mismatch between the type of `'Left` being template-haskell-2.19.0.0:Language.Haskell.TH.Syntax.Name (example when using GHC 9.4.5 as the host) and the type of `leftName` being ghc-lib-9.9.20230712:Language.Haskell.TH.Syntax.Name (example when the target version is built from recent `master`). Currently, `ghc-lib-gen` has a pre-processing step on the GHC source tree that replaces these quotations with applications containing direct references to the target TH constructors: https://github.com/digital-asset/ghc-lib/blob/ab01fb2b4d1e3a9338390e9c10ccd769bbf37aeb/ghc-lib-gen/src/Ghclibgen.hs#L419-L467 but I am worried that this is very fragile. So any ideas on how to tackle this situation better? Thanks, Gergo _______________________________________________ ghc-devs mailing list ghc-devs at haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs This email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please delete all copies and notify the sender immediately. You may wish to refer to the incorporation details of Standard Chartered PLC, Standard Chartered Bank and their subsidiaries at https: //www.sc.com/en/our-locations Where you have a Financial Markets relationship with Standard Chartered PLC, Standard Chartered Bank and their subsidiaries (the "Group"), information on the regulatory standards we adhere to and how it may affect you can be found in our Regulatory Compliance Statement at https: //www.sc.com/rcs/ and Regulatory Compliance Disclosures at http: //www.sc.com/rcs/fm Insofar as this communication is not sent by the Global Research team and contains any market commentary, the market commentary has been prepared by the sales and/or trading desk of Standard Chartered Bank or its affiliate. It is not and does not constitute research material, independent research, recommendation or financial advice. Any market commentary is for information purpose only and shall not be relied on for any other purpose and is subject to the relevant disclaimers available at https: //www.sc.com/en/regulatory-disclosures/#market-disclaimer. Insofar as this communication is sent by the Global Research team and contains any research materials prepared by members of the team, the research material is for information purpose only and shall not be relied on for any other purpose, and is subject to the relevant disclaimers available at https: //research.sc.com/research/api/application/static/terms-and-conditions. Insofar as this e-mail contains the term sheet for a proposed transaction, by responding affirmatively to this e-mail, you agree that you have understood the terms and conditions in the attached term sheet and evaluated the merits and risks of the transaction. We may at times also request you to sign the term sheet to acknowledge the same. Please visit https: //www.sc.com/en/regulatory-disclosures/dodd-frank/ for important information with respect to derivative products. -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.peytonjones at gmail.com Thu Jul 13 11:22:56 2023 From: simon.peytonjones at gmail.com (Simon Peyton Jones) Date: Thu, 13 Jul 2023 12:22:56 +0100 Subject: Exact-print info in the the HsSyn syntax tree Message-ID: Dear GHC developers Could you please look at #23447 Where should "tokens" live ? In brief, the question is whether we want to have: data HsExpr p = .... | HsLet (XLet p) (HsLocalBinds p) (LHsExpr p) or data HsExpr p = .... | HsLet (XLet p) (HsToken "let" p) (HsLocalBinds p) (HsToken "in" p) (LHsExpr p) In the former, if a client wants HsTokes to track the precise source locations of the "let" and "in" keywords, they'd have to put it in the TTG extension field; in the latter, this information is in *every* syntax tree. At the moment we have some of each, which is not satisfactory. We need to decide a policy and stick to it. If you use HsSyn, HsExpr, HsPat etc, in any way, you should have an opinion. Please do express it. At the moment we have only a few voices so we risk deciding without enough evidence and use-cases. Comments with specific use-cases and examples would be particularly helpful. Thanks! Simon -------------- next part -------------- An HTML attachment was scrubbed... URL: From jakob.bruenker at gmail.com Thu Jul 13 12:31:23 2023 From: jakob.bruenker at gmail.com (=?UTF-8?Q?Jakob_Br=C3=BCnker?=) Date: Thu, 13 Jul 2023 14:31:23 +0200 Subject: Exact-print info in the the HsSyn syntax tree In-Reply-To: References: Message-ID: Having written the MonadicBang plugin somewhat recently, where I don't care about the exact-print annotations, I do have some snippets in my code that look like this: AsPat xa name tok pat -> do tellName name AsPat xa name tok <$> traverse (liftMaybeT . evacPats) pat where the `tok` variable only exists to pass along the exact-print annotations unchanged. So in that context, I would have a slight preference for the exact-print annotations being hidden away in the extension points. However, I think this also illustrates that the cost to clients is quite manageable. Adding this one variable doesn't make the code unreadable - of course, that's assuming exact-print annotations remain special and not just the first in a long list of properties to eventually be added to each node. Of course, the cost *is* multiplied by the number of pattern matches on AST nodes you have, which could be a lot given the amount of constructors the types have. In my case, it was very few, because I was able to handle the vast majority of constructors generically via the Data.Data instance. Jakob On Thu, Jul 13, 2023 at 1:23 PM Simon Peyton Jones < simon.peytonjones at gmail.com> wrote: > Dear GHC developers > > Could you please look at #23447 Where should "tokens" live > ? > > In brief, the question is whether we want to have: > > data HsExpr p = .... > | HsLet (XLet p) (HsLocalBinds p) (LHsExpr p) > or > > data HsExpr p = .... > | HsLet (XLet p) (HsToken "let" p) > (HsLocalBinds p) (HsToken "in" p) (LHsExpr p) > > > In the former, if a client wants HsTokes to track the precise source > locations of the "let" and "in" keywords, they'd have to put it in the TTG > extension field; in the latter, this information is in *every* syntax > tree. > > At the moment we have some of each, which is not satisfactory. We need to > decide a policy and stick to it. If you use HsSyn, HsExpr, HsPat etc, in > any way, you should have an opinion. Please do express it. At the moment > we have only a few voices so we risk deciding without enough evidence and > use-cases. > > Comments with specific use-cases and examples would be particularly > helpful. > > Thanks! > > Simon > > _______________________________________________ > 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 bryan at haskell.foundation Thu Jul 13 13:01:42 2023 From: bryan at haskell.foundation (Bryan Richter) Date: Thu, 13 Jul 2023 16:01:42 +0300 Subject: New spurious failure bot is running on GitLab Message-ID: Today I've deployed a new version of my retry service. I think I've worked out most of the kinks, so I'm going to leave it running overnight and see how it goes. In the worst case, it might crash and die, in which case spurious failures will not get retried until I come back and fix it tomorrow morning, Europe time. In the best case, the service will just keep doing what the old one did, with two improvements: 1. If the same job keeps failing, it will give up retries. 2. If sending a retry command to GitLab itself fails, those will also be retried a few times. -Bryan "Who retries the retryer?" - Juvenal, probably -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.peytonjones at gmail.com Thu Jul 13 13:32:20 2023 From: simon.peytonjones at gmail.com (Simon Peyton Jones) Date: Thu, 13 Jul 2023 14:32:20 +0100 Subject: Exact-print info in the the HsSyn syntax tree In-Reply-To: References: Message-ID: Thanks Jakob -- but would it be possible to comment *on the ticket*, not here? (I should have said that more clearly.) Simon On Thu, 13 Jul 2023 at 13:31, Jakob Brünker wrote: > Having written the MonadicBang plugin somewhat recently, where I don't > care about the exact-print annotations, I do have some snippets in my code > that look like this: > > AsPat xa name tok pat -> do > tellName name > AsPat xa name tok <$> traverse (liftMaybeT . evacPats) pat > > where the `tok` variable only exists to pass along the exact-print > annotations unchanged. So in that context, I would have a slight preference > for the exact-print annotations being hidden away in the extension points. > However, I think this also illustrates that the cost to clients is quite > manageable. Adding this one variable doesn't make the code unreadable - of > course, that's assuming exact-print annotations remain special and not just > the first in a long list of properties to eventually be added to each node. > > Of course, the cost *is* multiplied by the number of pattern matches on > AST nodes you have, which could be a lot given the amount of constructors > the types have. In my case, it was very few, because I was able to handle > the vast majority of constructors generically via the Data.Data instance. > > Jakob > > On Thu, Jul 13, 2023 at 1:23 PM Simon Peyton Jones < > simon.peytonjones at gmail.com> wrote: > >> Dear GHC developers >> >> Could you please look at #23447 Where should "tokens" live >> ? >> >> In brief, the question is whether we want to have: >> >> data HsExpr p = .... >> | HsLet (XLet p) (HsLocalBinds p) (LHsExpr p) >> or >> >> data HsExpr p = .... >> | HsLet (XLet p) (HsToken "let" p) >> (HsLocalBinds p) (HsToken "in" p) (LHsExpr p) >> >> >> In the former, if a client wants HsTokes to track the precise source >> locations of the "let" and "in" keywords, they'd have to put it in the TTG >> extension field; in the latter, this information is in *every* syntax >> tree. >> >> At the moment we have some of each, which is not satisfactory. We need to >> decide a policy and stick to it. If you use HsSyn, HsExpr, HsPat etc, in >> any way, you should have an opinion. Please do express it. At the moment >> we have only a few voices so we risk deciding without enough evidence and >> use-cases. >> >> Comments with specific use-cases and examples would be particularly >> helpful. >> >> Thanks! >> >> Simon >> >> _______________________________________________ >> 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 jakob.bruenker at gmail.com Thu Jul 13 13:46:43 2023 From: jakob.bruenker at gmail.com (=?UTF-8?Q?Jakob_Br=C3=BCnker?=) Date: Thu, 13 Jul 2023 15:46:43 +0200 Subject: Exact-print info in the the HsSyn syntax tree In-Reply-To: References: Message-ID: Sure, done Jakob On Thu, Jul 13, 2023 at 3:32 PM Simon Peyton Jones < simon.peytonjones at gmail.com> wrote: > Thanks Jakob -- but would it be possible to comment *on the ticket*, not > here? (I should have said that more clearly.) > > Simon > > On Thu, 13 Jul 2023 at 13:31, Jakob Brünker > wrote: > >> Having written the MonadicBang plugin somewhat recently, where I don't >> care about the exact-print annotations, I do have some snippets in my code >> that look like this: >> >> AsPat xa name tok pat -> do >> tellName name >> AsPat xa name tok <$> traverse (liftMaybeT . evacPats) pat >> >> where the `tok` variable only exists to pass along the exact-print >> annotations unchanged. So in that context, I would have a slight preference >> for the exact-print annotations being hidden away in the extension points. >> However, I think this also illustrates that the cost to clients is quite >> manageable. Adding this one variable doesn't make the code unreadable - of >> course, that's assuming exact-print annotations remain special and not just >> the first in a long list of properties to eventually be added to each node. >> >> Of course, the cost *is* multiplied by the number of pattern matches on >> AST nodes you have, which could be a lot given the amount of constructors >> the types have. In my case, it was very few, because I was able to handle >> the vast majority of constructors generically via the Data.Data instance. >> >> Jakob >> >> On Thu, Jul 13, 2023 at 1:23 PM Simon Peyton Jones < >> simon.peytonjones at gmail.com> wrote: >> >>> Dear GHC developers >>> >>> Could you please look at #23447 Where should "tokens" live >>> ? >>> >>> In brief, the question is whether we want to have: >>> >>> data HsExpr p = .... >>> | HsLet (XLet p) (HsLocalBinds p) (LHsExpr p) >>> or >>> >>> data HsExpr p = .... >>> | HsLet (XLet p) (HsToken "let" p) >>> (HsLocalBinds p) (HsToken "in" p) (LHsExpr p) >>> >>> >>> In the former, if a client wants HsTokes to track the precise source >>> locations of the "let" and "in" keywords, they'd have to put it in the TTG >>> extension field; in the latter, this information is in *every* syntax >>> tree. >>> >>> At the moment we have some of each, which is not satisfactory. We need >>> to decide a policy and stick to it. If you use HsSyn, HsExpr, HsPat etc, >>> in any way, you should have an opinion. Please do express it. At the >>> moment we have only a few voices so we risk deciding without enough >>> evidence and use-cases. >>> >>> Comments with specific use-cases and examples would be particularly >>> helpful. >>> >>> Thanks! >>> >>> Simon >>> >>> _______________________________________________ >>> 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 rodrigo.m.mesquita at gmail.com Fri Jul 14 15:30:28 2023 From: rodrigo.m.mesquita at gmail.com (Rodrigo Mesquita) Date: Fri, 14 Jul 2023 16:30:28 +0100 Subject: Why do the reverse binder swap transformation? Message-ID: <9D417485-2AA4-4B02-BABF-303C0BF58318@gmail.com> Dear GHC devs, I’m wondering about the reverse binder swap transformation, the one in which we substitute occurrences of the case binder by occurrences of the scrutinee (when the scrut. is a variable): case x of z { r -> e } ===> case x of z { r -> e[x/z] } My question is: why do we do this transformation? An example in which this transformation is beneficial would be great too. The Note I’ve found about it, Note [Binder-swap during float-out], wasn’t entirely clear to me: 4. Note [Binder-swap during float-out] ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ In the expression case x of wild { p -> ...wild... } we substitute x for wild in the RHS of the case alternatives: case x of wild { p -> ...x... } This means that a sub-expression involving x is not "trapped" inside the RHS. And it's not inconvenient because we already have a substitution. Note that this is EXACTLY BACKWARDS from the what the simplifier does. The simplifier tries to get rid of occurrences of x, in favour of wild, in the hope that there will only be one remaining occurrence of x, namely the scrutinee of the case, and we can inline it. Many thanks, Rodrigo From jaro.reinders at gmail.com Fri Jul 14 15:35:48 2023 From: jaro.reinders at gmail.com (Jaro Reinders) Date: Fri, 14 Jul 2023 17:35:48 +0200 Subject: Why do the reverse binder swap transformation? In-Reply-To: <9D417485-2AA4-4B02-BABF-303C0BF58318@gmail.com> References: <9D417485-2AA4-4B02-BABF-303C0BF58318@gmail.com> Message-ID: This might be an example: https://gitlab.haskell.org/ghc/ghc/-/issues/22902#note_479305 Cheers, Jaro On 14-07-2023 17:30, Rodrigo Mesquita wrote: > Dear GHC devs, > > I’m wondering about the reverse binder swap transformation, the one in which we substitute occurrences of the case binder by occurrences of the scrutinee (when the scrut. is a variable): > > case x of z { r -> e } > ===> > case x of z { r -> e[x/z] } > > My question is: why do we do this transformation? An example in which this transformation is beneficial would be great too. > > The Note I’ve found about it, Note [Binder-swap during float-out], wasn’t entirely clear to me: > > 4. Note [Binder-swap during float-out] > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > In the expression > case x of wild { p -> ...wild... } > we substitute x for wild in the RHS of the case alternatives: > case x of wild { p -> ...x... } > This means that a sub-expression involving x is not "trapped" inside the RHS. > And it's not inconvenient because we already have a substitution. > > Note that this is EXACTLY BACKWARDS from the what the simplifier does. > The simplifier tries to get rid of occurrences of x, in favour of wild, > in the hope that there will only be one remaining occurrence of x, namely > the scrutinee of the case, and we can inline it. > > Many thanks, > Rodrigo > > _______________________________________________ > 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 Fri Jul 14 15:53:24 2023 From: simon.peytonjones at gmail.com (Simon Peyton Jones) Date: Fri, 14 Jul 2023 16:53:24 +0100 Subject: Why do the reverse binder swap transformation? In-Reply-To: <9D417485-2AA4-4B02-BABF-303C0BF58318@gmail.com> References: <9D417485-2AA4-4B02-BABF-303C0BF58318@gmail.com> Message-ID: Consider f x = letrec go y = case x of z { (a,b) -> ...(expensive z)... } in ... If we do the reverse binder-swap we get f x = letrec go y = case x of z { (a,b) -> ...(expensive x)... } in ... and now we can float out: f x = let t = expensive x in letrec go y = case x of z { (a,b) -> ...(t)... } in ... Now (expensive x) is computed once, rather than once each time around the 'go' loop.. Would you like to elaborate the Note to explain this better? Simon On Fri, 14 Jul 2023 at 16:30, Rodrigo Mesquita wrote: > Dear GHC devs, > > I’m wondering about the reverse binder swap transformation, the one in > which we substitute occurrences of the case binder by occurrences of the > scrutinee (when the scrut. is a variable): > > case x of z { r -> e } > ===> > case x of z { r -> e[x/z] } > > My question is: why do we do this transformation? An example in which this > transformation is beneficial would be great too. > > The Note I’ve found about it, Note [Binder-swap during float-out], wasn’t > entirely clear to me: > > 4. Note [Binder-swap during float-out] > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > In the expression > case x of wild { p -> ...wild... } > we substitute x for wild in the RHS of the case alternatives: > case x of wild { p -> ...x... } > This means that a sub-expression involving x is not "trapped" > inside the RHS. > And it's not inconvenient because we already have a > substitution. > > Note that this is EXACTLY BACKWARDS from the what the simplifier > does. > The simplifier tries to get rid of occurrences of x, in favour > of wild, > in the hope that there will only be one remaining occurrence of > x, namely > the scrutinee of the case, and we can inline it. > > Many thanks, > Rodrigo > > _______________________________________________ > 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 rodrigo.m.mesquita at gmail.com Fri Jul 14 16:02:42 2023 From: rodrigo.m.mesquita at gmail.com (Rodrigo Mesquita) Date: Fri, 14 Jul 2023 17:02:42 +0100 Subject: Why do the reverse binder swap transformation? In-Reply-To: References: <9D417485-2AA4-4B02-BABF-303C0BF58318@gmail.com> Message-ID: <8427FCC3-F9C1-4F09-92D0-E2A4B6767421@gmail.com> That’s a great example, it’s much clearer now. I’ve improved the note and added this example to it. It’s !10875. Thanks, Rodrigo > On 14 Jul 2023, at 16:53, Simon Peyton Jones wrote: > > Consider > > f x = letrec go y = case x of z { (a,b) -> ...(expensive z)... } > in ... > > If we do the reverse binder-swap we get > > f x = letrec go y = case x of z { (a,b) -> ...(expensive x)... } > in ... > > and now we can float out: > > f x = let t = expensive x > in letrec go y = case x of z { (a,b) -> ...(t)... } > in ... > > Now (expensive x) is computed once, rather than once each time around the 'go' loop.. > > Would you like to elaborate the Note to explain this better? > > Simon > > > On Fri, 14 Jul 2023 at 16:30, Rodrigo Mesquita > wrote: >> Dear GHC devs, >> >> I’m wondering about the reverse binder swap transformation, the one in which we substitute occurrences of the case binder by occurrences of the scrutinee (when the scrut. is a variable): >> >> case x of z { r -> e } >> ===> >> case x of z { r -> e[x/z] } >> >> My question is: why do we do this transformation? An example in which this transformation is beneficial would be great too. >> >> The Note I’ve found about it, Note [Binder-swap during float-out], wasn’t entirely clear to me: >> >> 4. Note [Binder-swap during float-out] >> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >> In the expression >> case x of wild { p -> ...wild... } >> we substitute x for wild in the RHS of the case alternatives: >> case x of wild { p -> ...x... } >> This means that a sub-expression involving x is not "trapped" inside the RHS. >> And it's not inconvenient because we already have a substitution. >> >> Note that this is EXACTLY BACKWARDS from the what the simplifier does. >> The simplifier tries to get rid of occurrences of x, in favour of wild, >> in the hope that there will only be one remaining occurrence of x, namely >> the scrutinee of the case, and we can inline it. >> >> Many thanks, >> Rodrigo >> >> _______________________________________________ >> 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 mark at ploeh.dk Tue Jul 18 17:44:46 2023 From: mark at ploeh.dk (Mark Seemann) Date: Tue, 18 Jul 2023 17:44:46 +0000 Subject: Request for approval of account Message-ID: Hello I’d like to report a bug in GHC because an error message tells me to do so. In order to do that, I’m trying to follow the guidelines in https://gitlab.haskell.org/ghc/ghc/-/wikis/report-a-bug, so I’ve created an account. The next step, as I understand it, is to use this mailing list to request approval for he account. I’m hereby doing that. TIA Mark Seemann -------------- next part -------------- An HTML attachment was scrubbed... URL: From matthewtpickering at gmail.com Mon Jul 24 11:52:18 2023 From: matthewtpickering at gmail.com (Matthew Pickering) Date: Mon, 24 Jul 2023 12:52:18 +0100 Subject: ghc-9.4.6 is being prepared Message-ID: Hi all, Zubin is preparing the 9.4.6 release so we expect to release it within the next two weeks. The focus of the release ot back-port the quite large number of fixes which are marked for backport to 9.4. https://gitlab.haskell.org/ghc/ghc/-/merge_requests?scope=all&state=opened&label_name[]=backport%20needed%3A9.4 Cheers, Matt From sgraf1337 at gmail.com Mon Jul 24 13:25:50 2023 From: sgraf1337 at gmail.com (Sebastian Graf) Date: Mon, 24 Jul 2023 15:25:50 +0200 Subject: RFC Or patterns syntax: (p1 | p2) vs. (p1; p2) Message-ID: Hi devs, I would like to invite you to provide arguments for or against the Or patterns syntax RFC `(p1; p2)` vs. `(p1 | p2)` over at this GH issue . *In particular, `(p1 | p2)` has a small lead over `(p1; p2)`*, but the latter will steal syntax from a hypothetical guards-in-patterns extension `(p | e)` as described here . I dismissed this point until Vlad made me aware of the fact that `f (a -> b)` *could* mean "a pattern match on the type constructor `(->)`" in a Dependent Haskell future. Apparently, the existence of the hypothetical guards-in-patterns extension was reason enough to exclude view patterns from GHC2021. Of course, `(p1; p2)` has issues of its own. Given how close this vote is, I want to make sure that you, the GHC devs, are aware of this issue and perhaps have a few minutes to formulate a (counter) argument or just leave your vote before we submit the winner in the actual amendment proposal, at which point it will be up to the GHC steering committee to decide. Thanks, Sebastian -------------- next part -------------- An HTML attachment was scrubbed... URL: From adi.obilisetty at gmail.com Mon Jul 24 17:59:13 2023 From: adi.obilisetty at gmail.com (Adithya Kumar) Date: Mon, 24 Jul 2023 23:29:13 +0530 Subject: Coercing a `ByteArray#` into a `MutableByteArray#` Message-ID: Hello all, I have a use-case where I want to convert `ByteArray#` to `MutableByteArray#` without the copy overhead. Is the underlying memory structure of `ByteArray#` and `MutableByteArray#` the same? If I can guarantee that I won't mutate my `MutableByteArray#`, can I use `unsafeCoerce#` on `ByteArray#` and treat it as `MutableByteArray#`? Best, Adithya -------------- next part -------------- An HTML attachment was scrubbed... URL: From chessai1996 at gmail.com Mon Jul 24 18:17:15 2023 From: chessai1996 at gmail.com (chessai) Date: Mon, 24 Jul 2023 13:17:15 -0500 Subject: Coercing a `ByteArray#` into a `MutableByteArray#` In-Reply-To: References: Message-ID: Hi Adithya, The representations are the same. You can do this. I do this somewhat often. Just avoid mutating in places where it could result in funky stuffs. This is usually pretty easy to spot. Cheers, chessai On Mon, Jul 24, 2023, 12:59 Adithya Kumar wrote: > Hello all, > > I have a use-case where I want to convert `ByteArray#` to > `MutableByteArray#` > without the copy overhead. > > Is the underlying memory structure of `ByteArray#` and `MutableByteArray#` > the > same? > > If I can guarantee that I won't mutate my `MutableByteArray#`, can I use > `unsafeCoerce#` on `ByteArray#` and treat it as `MutableByteArray#`? > > Best, > Adithya > _______________________________________________ > 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 sam.derbyshire at gmail.com Mon Jul 24 18:37:28 2023 From: sam.derbyshire at gmail.com (Sam Derbyshire) Date: Mon, 24 Jul 2023 20:37:28 +0200 Subject: Coercing a `ByteArray#` into a `MutableByteArray#` In-Reply-To: References: Message-ID: Indeed, this is what the `primitive` package provides to thaw a `ByteArray#` without copying: https://hackage.haskell.org/package/primitive-0.8.0.0/docs/src/Data.Primitive.ByteArray.html#unsafeThawByteArray On Mon, 24 Jul 2023, 20:17 chessai, wrote: > Hi Adithya, > > The representations are the same. You can do this. I do this somewhat > often. Just avoid mutating in places where it could result in funky stuffs. > This is usually pretty easy to spot. > > Cheers, > chessai > > On Mon, Jul 24, 2023, 12:59 Adithya Kumar > wrote: > >> Hello all, >> >> I have a use-case where I want to convert `ByteArray#` to >> `MutableByteArray#` >> without the copy overhead. >> >> Is the underlying memory structure of `ByteArray#` and >> `MutableByteArray#` the >> same? >> >> If I can guarantee that I won't mutate my `MutableByteArray#`, can I use >> `unsafeCoerce#` on `ByteArray#` and treat it as `MutableByteArray#`? >> >> Best, >> Adithya >> _______________________________________________ >> 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 ben at smart-cactus.org Mon Jul 24 19:21:45 2023 From: ben at smart-cactus.org (Ben Gamari) Date: Mon, 24 Jul 2023 15:21:45 -0400 Subject: Coercing a `ByteArray#` into a `MutableByteArray#` In-Reply-To: References: Message-ID: <87zg3lqfna.fsf@smart-cactus.org> Adithya Kumar writes: > Hello all, > > I have a use-case where I want to convert `ByteArray#` to > `MutableByteArray#` > without the copy overhead. > > Is the underlying memory structure of `ByteArray#` and `MutableByteArray#` > the same? > > If I can guarantee that I won't mutate my `MutableByteArray#`, can I use > `unsafeCoerce#` on `ByteArray#` and treat it as `MutableByteArray#`? > Note that a future release of GHC (IIRC 9.10) will have a (no-op) operation for precisely this purpose. See [1]. Cheers, - Ben [1] https://gitlab.haskell.org/ghc/ghc/-/issues/22710 From ben at well-typed.com Wed Jul 26 01:24:08 2023 From: ben at well-typed.com (Ben Gamari) Date: Tue, 25 Jul 2023 21:24:08 -0400 Subject: GHC 9.8 release status Message-ID: <87r0ovqxc7.fsf@smart-cactus.org> Hi all, As you may have noticed, the GHC 9.8 alpha series is a bit behind the expected schedule due to an unfortunate constellation of CI issues, bugs, and backports. I am currently trying to get a set of releasable artifacts through CI although things are somewhat stalled until we find a way forward in resolving ghc/ci-config#6 [1], caused by a regression in Docker. My hope is that we can have a set of release artifacts by Thursday. When this happens I will make any necessary amendments to the release schedule [2] to account for this delay. Thank you for your patience! Cheers, - Ben [1]: https://gitlab.haskell.org/ghc/ci-config/-/issues/6 [2]: https://gitlab.haskell.org/ghc/ghc/-/milestones/379#tab-issues From benjamin.redelings at gmail.com Wed Jul 26 10:00:29 2023 From: benjamin.redelings at gmail.com (Benjamin Redelings) Date: Wed, 26 Jul 2023 12:00:29 +0200 Subject: NamedDefaults and relaxed defaults? Message-ID: <62f47c2d-2c44-52c4-a45e-5b526c2cb679@gmail.com> Hi, If I understand correctly, the traditional defaulting rules prevent defaulting variables with constraints like (Num a, Convertible a Double), but the NamedDefaults proposal would allow defaulting a ~ Double in this case due to the relaxed defaulting rules in section 2.5 of the proposal: https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0409-exportable-named-default.rst#id2 1. Is there any plan to start implementing NamedDefaults?  I saw the comment from Simon P-J that it would not be fun to implement because it might require orphan default declarations... so perhaps there's no plan to implement this? 2. Would it be worth adding a separate LANGUAGE option that just implements the relaxed defaulting rules in section 2.5? Specifically (a) allowing variables with multiparameter constraints and (b) allowing variables with constraints that are not in the Prelude. 3. Am I correct in assuming that the relaxed defaulting rules require NamedDefaults to be enabled in the importing module, and not just in the imported model? -BenRI From simon.peytonjones at gmail.com Wed Jul 26 10:11:51 2023 From: simon.peytonjones at gmail.com (Simon Peyton Jones) Date: Wed, 26 Jul 2023 11:11:51 +0100 Subject: NamedDefaults and relaxed defaults? In-Reply-To: <62f47c2d-2c44-52c4-a45e-5b526c2cb679@gmail.com> References: <62f47c2d-2c44-52c4-a45e-5b526c2cb679@gmail.com> Message-ID: No: I don't know of anyone planning to implement this proposal -- indeed I had forgotten about it -- so it's waiting for someone to take it on. There are some slightly tricky loose ends around defaulting that it'd be good to nail down first: https://gitlab.haskell.org/ghc/ghc/-/issues/20686 Simon On Wed, 26 Jul 2023 at 11:00, Benjamin Redelings < benjamin.redelings at gmail.com> wrote: > Hi, > > If I understand correctly, the traditional defaulting rules prevent > defaulting variables with constraints like (Num a, Convertible a > Double), but the NamedDefaults proposal would allow defaulting a ~ > Double in this case due to the relaxed defaulting rules in section 2.5 > of the proposal: > > > https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0409-exportable-named-default.rst#id2 > > 1. Is there any plan to start implementing NamedDefaults? I saw the > comment from Simon P-J that it would not be fun to implement because it > might require orphan default declarations... so perhaps there's no plan > to implement this? > > 2. Would it be worth adding a separate LANGUAGE option that just > implements the relaxed defaulting rules in section 2.5? Specifically (a) > allowing variables with multiparameter constraints and (b) allowing > variables with constraints that are not in the Prelude. > > 3. Am I correct in assuming that the relaxed defaulting rules require > NamedDefaults to be enabled in the importing module, and not just in the > imported model? > > -BenRI > _______________________________________________ > 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 benjamin.redelings at gmail.com Wed Jul 26 16:46:07 2023 From: benjamin.redelings at gmail.com (Benjamin Redelings) Date: Wed, 26 Jul 2023 18:46:07 +0200 Subject: NamedDefaults and relaxed defaults? In-Reply-To: References: <62f47c2d-2c44-52c4-a45e-5b526c2cb679@gmail.com> Message-ID: <63519e88-b727-7e85-9cdd-6cd91ff58982@gmail.com> Thanks! It looks like ExtendedDefaultRules already allows default variables that co-occur with multiparameter constraints and non-standard classes.  So maybe that solves my issue with (Num a, Convertible a Double). Does the defaulting for RuntimeRep interact with class defaulting? -BenRI On 7/26/23 12:11 PM, Simon Peyton Jones wrote: > No: I don't know of anyone planning to implement this proposal -- > indeed I had forgotten about it -- so it's waiting for someone to take > it on. > > There are some slightly tricky loose ends around defaulting that it'd > be good to nail down first: > https://gitlab.haskell.org/ghc/ghc/-/issues/20686 > > Simon > > On Wed, 26 Jul 2023 at 11:00, Benjamin Redelings > wrote: > > Hi, > > If I understand correctly, the traditional defaulting rules prevent > defaulting variables with constraints like (Num a, Convertible a > Double), but the NamedDefaults proposal would allow defaulting a ~ > Double in this case due to the relaxed defaulting rules in section > 2.5 > of the proposal: > > https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0409-exportable-named-default.rst#id2 > > 1. Is there any plan to start implementing NamedDefaults?  I saw the > comment from Simon P-J that it would not be fun to implement > because it > might require orphan default declarations... so perhaps there's no > plan > to implement this? > > 2. Would it be worth adding a separate LANGUAGE option that just > implements the relaxed defaulting rules in section 2.5? > Specifically (a) > allowing variables with multiparameter constraints and (b) allowing > variables with constraints that are not in the Prelude. > > 3. Am I correct in assuming that the relaxed defaulting rules require > NamedDefaults to be enabled in the importing module, and not just > in the > imported model? > > -BenRI > _______________________________________________ > 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 benjamin.redelings at gmail.com Wed Jul 26 16:59:48 2023 From: benjamin.redelings at gmail.com (Benjamin Redelings) Date: Wed, 26 Jul 2023 18:59:48 +0200 Subject: NamedDefaults and relaxed defaults? In-Reply-To: <63519e88-b727-7e85-9cdd-6cd91ff58982@gmail.com> References: <62f47c2d-2c44-52c4-a45e-5b526c2cb679@gmail.com> <63519e88-b727-7e85-9cdd-6cd91ff58982@gmail.com> Message-ID: <50fc456b-3fc4-3a70-465b-1921c3958558@gmail.com> On 7/26/23 6:46 PM, Benjamin Redelings wrote: > > Thanks! > > It looks like ExtendedDefaultRules already allows default variables > that co-occur with multiparameter constraints and non-standard > classes.  So maybe that solves my issue with (Num a, Convertible a > Double). > It looks like (Num a, Convertible Double a) would work differently: - with ExtendedDefaultRules, GHC would pick a ~ Integer (ignoring the Convertible constraint) and then complain that Convertible Double Integer has no instance. - with NamedDefaults, GHC would reject a ~ Integer because Convertible Double Integer fails and then choose a ~ Double, which succeeds. -BenRI > Does the defaulting for RuntimeRep interact with class defaulting? > > -BenRI > > On 7/26/23 12:11 PM, Simon Peyton Jones wrote: >> No: I don't know of anyone planning to implement this proposal -- >> indeed I had forgotten about it -- so it's waiting for someone to >> take it on. >> >> There are some slightly tricky loose ends around defaulting that it'd >> be good to nail down first: >> https://gitlab.haskell.org/ghc/ghc/-/issues/20686 >> >> Simon >> >> On Wed, 26 Jul 2023 at 11:00, Benjamin Redelings >> wrote: >> >> Hi, >> >> If I understand correctly, the traditional defaulting rules prevent >> defaulting variables with constraints like (Num a, Convertible a >> Double), but the NamedDefaults proposal would allow defaulting a ~ >> Double in this case due to the relaxed defaulting rules in >> section 2.5 >> of the proposal: >> >> https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0409-exportable-named-default.rst#id2 >> >> 1. Is there any plan to start implementing NamedDefaults?  I saw the >> comment from Simon P-J that it would not be fun to implement >> because it >> might require orphan default declarations... so perhaps there's >> no plan >> to implement this? >> >> 2. Would it be worth adding a separate LANGUAGE option that just >> implements the relaxed defaulting rules in section 2.5? >> Specifically (a) >> allowing variables with multiparameter constraints and (b) allowing >> variables with constraints that are not in the Prelude. >> >> 3. Am I correct in assuming that the relaxed defaulting rules >> require >> NamedDefaults to be enabled in the importing module, and not just >> in the >> imported model? >> >> -BenRI >> _______________________________________________ >> 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 ben at well-typed.com Fri Jul 28 21:59:49 2023 From: ben at well-typed.com (Ben Gamari) Date: Fri, 28 Jul 2023 17:59:49 -0400 Subject: [ANNOUNCE] GHC 9.8.1-alpha1 is now available Message-ID: <87v8e3pui2.fsf@smart-cactus.org> The GHC developers are very pleased to announce the availability of the first alpha prerelease of GHC 9.8.1. Binary distributions, source distributions, and documentation are available at https://downloads.haskell.org/ghc/9.8.1-alpha1 GHC 9.8 will bring a number of new features and improvements, including: * Preliminary support the `TypeApplications` language extension [type-binders], allowing types to be bound in type declarations. * Support for the `ExtendedLiterals` extension, providing syntax for non-word-sized numeric literals in the surface language [extended-literals] * Improved rewrite rule matching behavior, allowing limited matching of higher-order patterns * Better support for user-defined warnings by way of the `WARNING` pragma [warnings] * The introduction of the new `GHC.TypeError.Unsatisfiable` constraint, allowing more predictable user-defined type errors [unsatisfiable] * Implementation of the export deprecation proposal, allowing module exports to be marked with `DEPRECATE` pragmas [deprecated-exports] * The addition of build semaphore support for parallel compilation; with coming support in `cabal-install` this will allow better use of parallelism in multi-package builds [jsem] * More efficient representation of info table provenance information, reducing binary sizes by over 50% in some cases when `-finfo-table-map` is in use A full accounting of changes can be found in the [release notes]. We would like to thank GitHub, IOG, the Zw3rk stake pool, Well-Typed, Tweag I/O, Serokell, Equinix, SimSpace, the Haskell Foundation, and other anonymous contributors whose on-going financial and in-kind support has facilitated GHC maintenance and release management over the years. Finally, this release would not have been possible without the hundreds of open-source contributors whose work comprise this release. As always, do give this release a try and open a [ticket] if you see anything amiss. Happy compiling, ~ Ben [type-binders]: https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0425-decl-invis-binders.rst [extended-literals]: https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0451-sized-literals.rst [unsatisfiable]: https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0433-unsatisfiable.rst [warnings]: https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0541-warning-pragmas-with-categories.rst [deprecated-exports]: https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0134-deprecating-exports-proposal.rst [jsem]: https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0540-jsem.rst [release notes]: https://downloads.haskell.org/ghc/9.8.1-alpha1/docs/users_guide/9.8.1-notes.html [ticket]: https://gitlab.haskell.org/ghc/ghc/-/issues/new From david at haskell.foundation Mon Jul 31 09:05:20 2023 From: david at haskell.foundation (David Christiansen) Date: Mon, 31 Jul 2023 11:05:20 +0200 Subject: Thread on Discourse - HIE file processing Message-ID: Dear GHC devs, I think that having automated security advisory warnings from build tools is important for Haskell adoption in certain industries. This can be done based on build plans, but a package is really the wrong granularity - a large, widely-used package might export a little-used definition that is the subject of an advisory, and it would be good to warn only the users of said definition (cf base and readFloat). Tristan is exploring using HIE files to do this check, but I don't know if you read Discourse, where he posted the question: https://discourse.haskell.org/t/rfc-using-hie-files-to-list-external-declarations-for-cabal-audit/7147 Thanks! David -------------- next part -------------- An HTML attachment was scrubbed... URL: From tdecacqu at redhat.com Mon Jul 31 16:26:43 2023 From: tdecacqu at redhat.com (Tristan Cacqueray) Date: Mon, 31 Jul 2023 16:26:43 +0000 Subject: Thread on Discourse - HIE file processing In-Reply-To: References: Message-ID: <87tttkvygs.tristanC@fedora> On Mon, Jul 31, 2023 at 11:05 David Christiansen via ghc-devs wrote: > Dear GHC devs, > > I think that having automated security advisory warnings from build tools > is important for Haskell adoption in certain industries. This can be done > based on build plans, but a package is really the wrong granularity - a > large, widely-used package might export a little-used definition that is > the subject of an advisory, and it would be good to warn only the users of > said definition (cf base and readFloat). > > Tristan is exploring using HIE files to do this check, but I don't know if > you read Discourse, where he posted the question: > https://discourse.haskell.org/t/rfc-using-hie-files-to-list-external-declarations-for-cabal-audit/7147 > Thank you David for bringing this up here. One thing to note is that we would need hie files for ghc libraries, as proposed in: https://gitlab.haskell.org/ghc/ghc/-/merge_requests/1337 Cheers, -Tristan -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 515 bytes Desc: not available URL: