From diegorosario2013 at gmail.com Fri Aug 1 03:17:39 2025 From: diegorosario2013 at gmail.com (Diego Antonio Rosario Palomino) Date: Thu, 31 Jul 2025 22:17:39 -0500 Subject: Proposal: Roundtrip serialization of Cmm (parser-compatible pretty-printer output) In-Reply-To: References: Message-ID: Very related GHC gitlab issue : https://gitlab.haskell.org/ghc/ghc/-/issues/23989 El lun, 28 jul 2025 a la(s) 7:39 p.m., Diego Antonio Rosario Palomino ( diegorosario2013 at gmail.com) escribió: > >Hi Diego, > > >In the future it would make things easier if you could use one of the > >common email quoting conventions (i.e. starting lines with >). It is > >otherwise a bit hard to distinguish your replies from the questions > >you are responding to. > > I am sorry, Ben Gamari. I am not used to working in mailing lists. > > I also messed up the formatting in my last reply. I accidentally created a > second topic (but this comment uses the original topic). > > Please tell me if this comment uses an appropriate format so I can proceed > to answer the rest of your reply. > > Btw, some months back my first topic on this mailing list just linked to > the corresponding Discourse post: > https://discourse.haskell.org/t/gsoc-2025-documenting-and-improving-cmm/11870/15 > > Would it be acceptable to use Discourse for my next topic regarding this > project? (Maybe with a link here, on this mailing list.) > > Diego Antonio Rosario Palomino > -------------- next part -------------- An HTML attachment was scrubbed... URL: From wolfgang at well-typed.com Sat Aug 2 13:16:23 2025 From: wolfgang at well-typed.com (Wolfgang Jeltsch) Date: Sat, 02 Aug 2025 16:16:23 +0300 Subject: Generating fresh names in a source plugin Message-ID: <784803a01075d640cd534b235266e61c13e0e9a9.camel@well-typed.com> [Since it seems that `glasgow-haskell-users at haskell.org` is essentially an announcements-only mailing list these days, I’m re-sending my recent e-mail to that mailing list here.] Hello! I want to generate AST fragments in a source plugin, and for this I need to generate fresh (local) names. My current approach is to use `mkSystemName`, but it, like many of the other name-generating operations, needs a value of type `Unique`. How can I generate such values? It seems that the `Hsc` monad doesn’t carry a value of type `UniqueSupply` with it. All the best, Wolfgang From wolfgang at well-typed.com Sat Aug 2 17:08:10 2025 From: wolfgang at well-typed.com (Wolfgang Jeltsch) Date: Sat, 02 Aug 2025 20:08:10 +0300 Subject: Generating fresh names in a source plugin In-Reply-To: <784803a01075d640cd534b235266e61c13e0e9a9.camel@well-typed.com> References: <784803a01075d640cd534b235266e61c13e0e9a9.camel@well-typed.com> Message-ID: <98aefac996afb9c5e6b07d5025388b98ae4b3523.camel@well-typed.com> Hello, again! After some more digging, I came to the conclusion that `uniqFromTag` is likely what I should use. However, what exactly is the tag for? The note „Uniques and tags“ only says the following: > The tag […] is typically used to make it easier to distinguish uniques > constructed by different parts of the compiler. Who distinguishes uniques using tags: the compiler, compiler developers when reading debugging output, or end users? Does the choice of tag influence the behavior of the compiler other than with respect to messages? The documentation of `mkSplitUniqSupply` says that the tag “is mostly cosmetic”. If it is only *mostly* cosmetic, what aspects of it are not cosmetic? In the end, how do I choose a tag for uniques generated by a plugin? Is the choice essentially irrelevant? Do I have to prevent clashes with tags used by GHC or other plugins? Looking forward to insights. 🙂 All the best, Wolfgang Am Samstag, dem 02.08.2025 um 16:16 +0300 schrieb Wolfgang Jeltsch: > Hello! > > I want to generate AST fragments in a source plugin, and for this I > need to generate fresh (local) names. My current approach is to use > `mkSystemName`, but it, like many of the other name-generating > operations, needs a value of type `Unique`. How can I generate such > values? It seems that the `Hsc` monad doesn’t carry a value of type > `UniqueSupply` with it. > > All the best, > Wolfgang From stu126209 at mail.uni-kiel.de Sun Aug 3 15:25:02 2025 From: stu126209 at mail.uni-kiel.de (Kai Prott) Date: Sun, 03 Aug 2025 17:25:02 +0200 Subject: Generating fresh names in a source plugin In-Reply-To: <98aefac996afb9c5e6b07d5025388b98ae4b3523.camel@well-typed.com> References: <784803a01075d640cd534b235266e61c13e0e9a9.camel@well-typed.com> <98aefac996afb9c5e6b07d5025388b98ae4b3523.camel@well-typed.com> Message-ID: <3020D236-1B6F-4B23-97CB-A6DC456B8D55@mail.uni-kiel.de> Hi, what I have used In the past (and that I am fairly confident works) is exactly what you say: use `uniqFromTag` or `mkSplitUniqSupply`. According to the documentation, "the payload part of the Uniques allocated from this UniqSupply are guaranteed distinct wrt all other supplies, regardless of their 'tag'." (Assuming the unique does not overflow it's number of bits) As far as I know, end users should not get to see a unique and it should not influence compilation, so the Tag is only relevant for plugin/GHC devs for debugging. Also just curious: why do you need to construct a unique? Before the GHC renamer a plugin can get away with generating essentially strings that are "unique" and use them in `mkUnqual` or similar. Most of the time, I just generate a `RdrName` with a prefix that would not be allowed in source code with an incrementing suffix that I manage myself. I have not checked if a plugin-generated name has to be a valid Haskell name nowadays. However, it worked in the past. And just for completeness if someone else stumbles across this: After the GHC renamer in `CoreM`, `TcM` (and others) one can just use `getUniqueM` or `getUniqueSupplyM`. Best wishes, Kai Prott On August 2, 2025 7:08:10 PM GMT+02:00, Wolfgang Jeltsch wrote: >Hello, again! > >After some more digging, I came to the conclusion that `uniqFromTag` is >likely what I should use. However, what exactly is the tag for? > >The note „Uniques and tags“ only says the following: > >> The tag […] is typically used to make it easier to distinguish uniques >> constructed by different parts of the compiler. > >Who distinguishes uniques using tags: the compiler, compiler developers >when reading debugging output, or end users? Does the choice of tag >influence the behavior of the compiler other than with respect to >messages? > >The documentation of `mkSplitUniqSupply` says that the tag “is mostly >cosmetic”. If it is only *mostly* cosmetic, what aspects of it are not >cosmetic? > >In the end, how do I choose a tag for uniques generated by a plugin? Is >the choice essentially irrelevant? Do I have to prevent clashes with >tags used by GHC or other plugins? > >Looking forward to insights. 🙂 > >All the best, >Wolfgang > >Am Samstag, dem 02.08.2025 um 16:16 +0300 schrieb Wolfgang Jeltsch: >> Hello! >> >> I want to generate AST fragments in a source plugin, and for this I >> need to generate fresh (local) names. My current approach is to use >> `mkSystemName`, but it, like many of the other name-generating >> operations, needs a value of type `Unique`. How can I generate such >> values? It seems that the `Hsc` monad doesn’t carry a value of type >> `UniqueSupply` with it. >> >> All the best, >> Wolfgang >_______________________________________________ >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 Mon Aug 4 10:44:23 2025 From: simon.peytonjones at gmail.com (Simon Peyton Jones) Date: Mon, 4 Aug 2025 11:44:23 +0100 Subject: Generating fresh names in a source plugin In-Reply-To: <784803a01075d640cd534b235266e61c13e0e9a9.camel@well-typed.com> References: <784803a01075d640cd534b235266e61c13e0e9a9.camel@well-typed.com> Message-ID: What about calling this function? GHC.Tc.Plugin.newUnique :: TcPluginM Unique The module GHC.Tc.Plugin provides facilities to plugins. More generally, here is the manual page for plugins . Is it adequate? I notice that - it mentions the module GHC.Plugins (but only in code fragments) - it does not mention GHC.Tc.Plugins; neither does GHC.Plugins re-export GHC.Tc.Plugins It would be great if some plugin authors felt able to offer patches to improve. Maybe open a GHC ticket? Simon On Sat, 2 Aug 2025 at 14:16, Wolfgang Jeltsch wrote: > [Since it seems that `glasgow-haskell-users at haskell.org` is essentially > an announcements-only mailing list these days, I’m re-sending my recent > e-mail to that mailing list here.] > > Hello! > > I want to generate AST fragments in a source plugin, and for this I need > to generate fresh (local) names. My current approach is to use > `mkSystemName`, but it, like many of the other name-generating > operations, needs a value of type `Unique`. How can I generate such > values? It seems that the `Hsc` monad doesn’t carry a value of type > `UniqueSupply` with it. > > All the best, > Wolfgang > _______________________________________________ > 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 Mon Aug 4 14:12:38 2025 From: klebinger.andreas at gmx.at (Andreas Klebinger) Date: Mon, 4 Aug 2025 16:12:38 +0200 Subject: Generating fresh names in a source plugin In-Reply-To: <3020D236-1B6F-4B23-97CB-A6DC456B8D55@mail.uni-kiel.de> References: <784803a01075d640cd534b235266e61c13e0e9a9.camel@well-typed.com> <98aefac996afb9c5e6b07d5025388b98ae4b3523.camel@well-typed.com> <3020D236-1B6F-4B23-97CB-A6DC456B8D55@mail.uni-kiel.de> Message-ID: Some slight additions to Kais message: On 03/08/2025 17:25, Kai Prott wrote: > Hi, > > what I have used In the past (and that I am fairly confident works) is > exactly what you say: use `uniqFromTag` or `mkSplitUniqSupply`. > > According to the documentation, "the payload part of the Uniques > allocated from this UniqSupply are guaranteed distinct wrt all other > supplies, regardless of their 'tag'." > (Assuming the unique does not overflow it's number of bits) If you read on the docs refer to an edge case in the next lines. GHC contains a (limited) number of fixed/"built in"  uniques. GHC itself never creates uniques with the same tag as those fixed ones on the fly so there is no risk of collision. However if you explicitly use this tag it could happen and then compilation could go wrong. Outside of this that is correct. > > As far as I know, end users should not get to see a unique and it > should not influence compilation, so the Tag is only relevant for > plugin/GHC devs for debugging. Uniques influence code generation slightly, as they are part of internal symbol names. They should however not affect the behaviour of the program. This doesn't matter often, but when it does it really does. > > Also just curious: why do you need to construct a unique? Before the > GHC renamer a plugin can get away with generating essentially strings > that are "unique" and use them in `mkUnqual` or similar. > Most of the time, I just generate a `RdrName` with a prefix that would > not be allowed in source code with an incrementing suffix that I > manage myself. > I have not checked if a plugin-generated name has to be a valid > Haskell name nowadays. However, it worked in the past. > > And just for completeness if someone else stumbles across this: After > the GHC renamer in `CoreM`, `TcM` (and others) one can just use > `getUniqueM` or `getUniqueSupplyM`. > > Best wishes, > Kai Prott > > > On August 2, 2025 7:08:10 PM GMT+02:00, Wolfgang Jeltsch > wrote: > > Hello, again! After some more digging, I came to the conclusion > that `uniqFromTag` is likely what I should use. However, what > exactly is the tag for? The note „Uniques and tags“ only says the > following: > > The tag […] is typically used to make it easier to distinguish > uniques constructed by different parts of the compiler. > > Who distinguishes uniques using tags: the compiler, compiler > developers when reading debugging output, or end users? Does the > choice of tag influence the behavior of the compiler other than > with respect to messages? The documentation of `mkSplitUniqSupply` > says that the tag “is mostly cosmetic”. If it is only *mostly* > cosmetic, what aspects of it are not cosmetic? In the end, how do > I choose a tag for uniques generated by a plugin? Is the choice > essentially irrelevant? Do I have to prevent clashes with tags > used by GHC or other plugins? Looking forward to insights. 🙂 All > the best, Wolfgang Am Samstag, dem 02.08.2025 um 16:16 +0300 > schrieb Wolfgang Jeltsch: > > Hello! I want to generate AST fragments in a source plugin, > and for this I need to generate fresh (local) names. My > current approach is to use `mkSystemName`, but it, like many > of the other name-generating operations, needs a value of type > `Unique`. How can I generate such values? It seems that the > `Hsc` monad doesn’t carry a value of type `UniqueSupply` with > it. All the best, Wolfgang > > ------------------------------------------------------------------------ > 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 Mon Aug 4 14:16:46 2025 From: simon.peytonjones at gmail.com (Simon Peyton Jones) Date: Mon, 4 Aug 2025 15:16:46 +0100 Subject: Generating fresh names in a source plugin In-Reply-To: References: <784803a01075d640cd534b235266e61c13e0e9a9.camel@well-typed.com> Message-ID: Ugh. I realise that you were talking about *source* plugins, which work in the Hsc monad, which indeed has no obvious way to generate uniques. I have created https://gitlab.haskell.org/ghc/ghc/-/issues/26264 to document my learning journey. Simon On Mon, 4 Aug 2025 at 11:44, Simon Peyton Jones wrote: > What about calling this function? > > GHC.Tc.Plugin.newUnique :: TcPluginM Unique > > The module GHC.Tc.Plugin provides facilities to plugins. > > More generally, here is the manual page for plugins > . > Is it adequate? > > I notice that > > - it mentions the module GHC.Plugins (but only in code fragments) > - it does not mention GHC.Tc.Plugins; neither does GHC.Plugins > re-export GHC.Tc.Plugins > > It would be great if some plugin authors felt able to offer patches to > improve. Maybe open a GHC ticket? > > Simon > > > > On Sat, 2 Aug 2025 at 14:16, Wolfgang Jeltsch > wrote: > >> [Since it seems that `glasgow-haskell-users at haskell.org` is essentially >> an announcements-only mailing list these days, I’m re-sending my recent >> e-mail to that mailing list here.] >> >> Hello! >> >> I want to generate AST fragments in a source plugin, and for this I need >> to generate fresh (local) names. My current approach is to use >> `mkSystemName`, but it, like many of the other name-generating >> operations, needs a value of type `Unique`. How can I generate such >> values? It seems that the `Hsc` monad doesn’t carry a value of type >> `UniqueSupply` with it. >> >> All the best, >> Wolfgang >> _______________________________________________ >> 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 Aug 4 18:28:48 2025 From: ben at smart-cactus.org (Ben Gamari) Date: Mon, 04 Aug 2025 14:28:48 -0400 Subject: Proposal: Roundtrip serialization of Cmm (parser-compatible pretty-printer output) In-Reply-To: References: Message-ID: <8734a7aqlg.fsf@smart-cactus.org> Diego Antonio Rosario Palomino writes: >>Hi Diego, > >>In the future it would make things easier if you could use one of the >>common email quoting conventions (i.e. starting lines with >). It is >>otherwise a bit hard to distinguish your replies from the questions >>you are responding to. > > I am sorry, Ben Gamari. I am not used to working in mailing lists. > > I also messed up the formatting in my last reply. I accidentally created a > second topic (but this comment uses the original topic). > > Please tell me if this comment uses an appropriate format so I can proceed > to answer the rest of your reply. > Yes, this is fine. > Would it be acceptable to use Discourse for my next topic regarding this > project? (Maybe with a link here, on this mailing list.) > Yes, but do try to leave a link here as well to ensure that your post is seen. Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 255 bytes Desc: not available URL: From wolfgang at well-typed.com Mon Aug 4 21:55:32 2025 From: wolfgang at well-typed.com (Wolfgang Jeltsch) Date: Tue, 05 Aug 2025 00:55:32 +0300 Subject: Generating fresh names in a source plugin In-Reply-To: <3020D236-1B6F-4B23-97CB-A6DC456B8D55@mail.uni-kiel.de> References: <784803a01075d640cd534b235266e61c13e0e9a9.camel@well-typed.com> <98aefac996afb9c5e6b07d5025388b98ae4b3523.camel@well-typed.com> <3020D236-1B6F-4B23-97CB-A6DC456B8D55@mail.uni-kiel.de> Message-ID: Am Sonntag, dem 03.08.2025 um 17:25 +0200 schrieb Kai Prott: > Also just curious: why do you need to construct a unique? Before the > GHC renamer a plugin can get away with generating essentially strings > that are "unique" and use them in `mkUnqual` or similar. > > Most of the time, I just generate a `RdrName` with a prefix that would > not be allowed in source code with an incrementing suffix that I > manage myself. I have not checked if a plugin-generated name has to be > a valid Haskell name nowadays. However, it worked in the past. I briefly considered this approach but then rejected it, because I couldn’t be sure that syntactically incorrect names are accepted and because there would be a slim possibility that another plugin picks names that my plugin picks. All the best, Wolfgang From wolfgang at well-typed.com Mon Aug 4 22:06:48 2025 From: wolfgang at well-typed.com (Wolfgang Jeltsch) Date: Tue, 05 Aug 2025 01:06:48 +0300 Subject: Generating fresh names in a source plugin In-Reply-To: References: <784803a01075d640cd534b235266e61c13e0e9a9.camel@well-typed.com> <98aefac996afb9c5e6b07d5025388b98ae4b3523.camel@well-typed.com> <3020D236-1B6F-4B23-97CB-A6DC456B8D55@mail.uni-kiel.de> Message-ID: <53097091b46088544ac05847ad2554ea453da635.camel@well-typed.com> Am Montag, dem 04.08.2025 um 16:12 +0200 schrieb Andreas Klebinger: > On 03/08/2025 17:25, Kai Prott wrote: > > According to the documentation, "the payload part of the Uniques > > allocated from this UniqSupply are guaranteed distinct wrt all other > > supplies, regardless of their 'tag'." (Assuming the unique does not > > overflow it's number of bits) > > If you read on the docs refer to an edge case in the next lines. GHC > contains a (limited) number of fixed/"built in" uniques. GHC itself > never creates uniques with the same tag as those fixed ones on the fly > so there is no risk of collision. However if you explicitly use this > tag it could happen and then compilation could go wrong. Outside of > this that is correct. I think there is at least another tag that is treated specially: `f`, having to do with type families, from what I remember. The fact that some tags do cause special compiler behavior makes the situation quite tricky. It may seem that a plugin author should pick a tag that isn’t used by GHC. This is already difficult, because you can’t reliably tell what tags GHC uses and what tags it may use in the future. However, what if the tags of the uniques that the plugin generates *need* special treatment? For example, you may want to create uniques for local variables that your plugin introduces, and GHC may use a tag for uniques of local names that causes necessary special compiler behavior. In the end, I used `grep` and my own eyes to check potentially the whole GHC codebase for tag use. My conclusion is that likely no specially treated tag is used for local variables, which are what I want the uniques for. Therefore, I probably should pick a tag that GHC surely doesn’t use and won’t ever use. I guess I’ll go for some ASCII control character. All the best, Wolfgang From wolfgang at well-typed.com Mon Aug 4 22:11:39 2025 From: wolfgang at well-typed.com (Wolfgang Jeltsch) Date: Tue, 05 Aug 2025 01:11:39 +0300 Subject: Generating fresh names in a source plugin In-Reply-To: References: <784803a01075d640cd534b235266e61c13e0e9a9.camel@well-typed.com> Message-ID: <48c272a9fcec47f733e119d4c8c1c308996dbf50.camel@well-typed.com> Am Montag, dem 04.08.2025 um 15:16 +0100 schrieb Simon Peyton Jones: > I have created https://gitlab.haskell.org/ghc/ghc/-/issues/26264 to > document my learning journey. Thank you for this. I find the reference to `takeUniqFromNameCache` interesting. I understand that the name cache that a `Hsc` environment contains, stores a tag that is to be used for generating uniques of names that will be put into this cache. I guess that for generating my own names I may use this very tag. All the best, Wolfgang From simon.peytonjones at gmail.com Mon Aug 4 22:18:38 2025 From: simon.peytonjones at gmail.com (Simon Peyton Jones) Date: Mon, 4 Aug 2025 23:18:38 +0100 Subject: Generating fresh names in a source plugin In-Reply-To: <53097091b46088544ac05847ad2554ea453da635.camel@well-typed.com> References: <784803a01075d640cd534b235266e61c13e0e9a9.camel@well-typed.com> <98aefac996afb9c5e6b07d5025388b98ae4b3523.camel@well-typed.com> <3020D236-1B6F-4B23-97CB-A6DC456B8D55@mail.uni-kiel.de> <53097091b46088544ac05847ad2554ea453da635.camel@well-typed.com> Message-ID: > > think there is at least another tag that is treated specially: `f`, > having to do with type families, from what I remember. The fact that some > tags do cause special compiler behavior makes the situation quite tricky. If you believe that the tag has significance beyond debugging etc, you may be right -- *but can you point to any evidence? *Perhaps you can record what you learn on #26264? It may seem that a plugin author should pick a > tag that isn’t used by GHC. This is already difficult, because you can’t > reliably tell what tags GHC uses and what tags it may use in the future. > However, what if the tags of the uniques that the plugin generates > *need* special treatment? For example, you may want to create uniques > for local variables that your plugin introduces, and GHC may use a tag > for uniques of local names that causes necessary special compiler > behavior. Once again, I know of no "special compiler behaviour" but I may be wrong. > you can’t > reliably tell what tags GHC uses and what tags it may use in the future. > In the end, I used `grep` and my own eyes to check potentially the whole > GHC codebase for tag use. Indeed this is bad. Can you record the list of tags you discovered, and where they are born, in #26264? Thanks! Simon On Mon, 4 Aug 2025 at 23:06, Wolfgang Jeltsch wrote: > Am Montag, dem 04.08.2025 um 16:12 +0200 schrieb Andreas Klebinger: > > On 03/08/2025 17:25, Kai Prott wrote: > > > According to the documentation, "the payload part of the Uniques > > > allocated from this UniqSupply are guaranteed distinct wrt all other > > > supplies, regardless of their 'tag'." (Assuming the unique does not > > > overflow it's number of bits) > > > > If you read on the docs refer to an edge case in the next lines. GHC > > contains a (limited) number of fixed/"built in" uniques. GHC itself > > never creates uniques with the same tag as those fixed ones on the fly > > so there is no risk of collision. However if you explicitly use this > > tag it could happen and then compilation could go wrong. Outside of > > this that is correct. > > I think there is at least another tag that is treated specially: `f`, > having to do with type families, from what I remember. > > The fact that some tags do cause special compiler behavior makes the > situation quite tricky. It may seem that a plugin author should pick a > tag that isn’t used by GHC. This is already difficult, because you can’t > reliably tell what tags GHC uses and what tags it may use in the future. > However, what if the tags of the uniques that the plugin generates > *need* special treatment? For example, you may want to create uniques > for local variables that your plugin introduces, and GHC may use a tag > for uniques of local names that causes necessary special compiler > behavior. > > In the end, I used `grep` and my own eyes to check potentially the whole > GHC codebase for tag use. My conclusion is that likely no specially > treated tag is used for local variables, which are what I want the > uniques for. Therefore, I probably should pick a tag that GHC surely > doesn’t use and won’t ever use. I guess I’ll go for some ASCII control > character. > > All the best, > Wolfgang > _______________________________________________ > 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 allbery.b at gmail.com Mon Aug 4 22:37:51 2025 From: allbery.b at gmail.com (Brandon Allbery) Date: Mon, 4 Aug 2025 18:37:51 -0400 Subject: Generating fresh names in a source plugin In-Reply-To: References: <784803a01075d640cd534b235266e61c13e0e9a9.camel@well-typed.com> <98aefac996afb9c5e6b07d5025388b98ae4b3523.camel@well-typed.com> <3020D236-1B6F-4B23-97CB-A6DC456B8D55@mail.uni-kiel.de> <53097091b46088544ac05847ad2554ea453da635.camel@well-typed.com> Message-ID: There's supposed to be one already, IIRC. And indeed, there is `Note [Uniques for wired-in prelude things and known tags]` in compiler/GHC/Builtin/Uniques.hs. If you've found more, they should probably be added there. On Mon, Aug 4, 2025 at 6:19 PM Simon Peyton Jones < simon.peytonjones at gmail.com> wrote: > think there is at least another tag that is treated specially: `f`, >> having to do with type families, from what I remember. The fact that >> some tags do cause special compiler behavior makes the situation quite >> tricky. > > > If you believe that the tag has significance beyond debugging etc, you may > be right -- *but can you point to any evidence? *Perhaps you can record > what you learn on #26264? > > It may seem that a plugin author should pick a >> tag that isn’t used by GHC. This is already difficult, because you can’t >> reliably tell what tags GHC uses and what tags it may use in the future. >> However, what if the tags of the uniques that the plugin generates >> *need* special treatment? For example, you may want to create uniques >> for local variables that your plugin introduces, and GHC may use a tag >> for uniques of local names that causes necessary special compiler >> behavior. > > > Once again, I know of no "special compiler behaviour" but I may be wrong. > > > >> you can’t >> reliably tell what tags GHC uses and what tags it may use in the future. >> In the end, I used `grep` and my own eyes to check potentially the whole >> GHC codebase for tag use. > > > Indeed this is bad. Can you record the list of tags you discovered, and > where they are born, in #26264? > > Thanks! > > Simon > > On Mon, 4 Aug 2025 at 23:06, Wolfgang Jeltsch > wrote: > >> Am Montag, dem 04.08.2025 um 16:12 +0200 schrieb Andreas Klebinger: >> > On 03/08/2025 17:25, Kai Prott wrote: >> > > According to the documentation, "the payload part of the Uniques >> > > allocated from this UniqSupply are guaranteed distinct wrt all other >> > > supplies, regardless of their 'tag'." (Assuming the unique does not >> > > overflow it's number of bits) >> > >> > If you read on the docs refer to an edge case in the next lines. GHC >> > contains a (limited) number of fixed/"built in" uniques. GHC itself >> > never creates uniques with the same tag as those fixed ones on the fly >> > so there is no risk of collision. However if you explicitly use this >> > tag it could happen and then compilation could go wrong. Outside of >> > this that is correct. >> >> I think there is at least another tag that is treated specially: `f`, >> having to do with type families, from what I remember. >> >> The fact that some tags do cause special compiler behavior makes the >> situation quite tricky. It may seem that a plugin author should pick a >> tag that isn’t used by GHC. This is already difficult, because you can’t >> reliably tell what tags GHC uses and what tags it may use in the future. >> However, what if the tags of the uniques that the plugin generates >> *need* special treatment? For example, you may want to create uniques >> for local variables that your plugin introduces, and GHC may use a tag >> for uniques of local names that causes necessary special compiler >> behavior. >> >> In the end, I used `grep` and my own eyes to check potentially the whole >> GHC codebase for tag use. My conclusion is that likely no specially >> treated tag is used for local variables, which are what I want the >> uniques for. Therefore, I probably should pick a tag that GHC surely >> doesn’t use and won’t ever use. I guess I’ll go for some ASCII control >> character. >> >> All the best, >> Wolfgang >> _______________________________________________ >> 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 > -- brandon s allbery kf8nh allbery.b at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From wolfgang at well-typed.com Tue Aug 5 14:18:31 2025 From: wolfgang at well-typed.com (Wolfgang Jeltsch) Date: Tue, 05 Aug 2025 17:18:31 +0300 Subject: Generating fresh names in a source plugin In-Reply-To: References: <784803a01075d640cd534b235266e61c13e0e9a9.camel@well-typed.com> <98aefac996afb9c5e6b07d5025388b98ae4b3523.camel@well-typed.com> <3020D236-1B6F-4B23-97CB-A6DC456B8D55@mail.uni-kiel.de> <53097091b46088544ac05847ad2554ea453da635.camel@well-typed.com> Message-ID: <10a80b51dbcefa08188b30017c266612ea428dc3.camel@well-typed.com> Am Montag, dem 04.08.2025 um 23:18 +0100 schrieb Simon Peyton Jones: > > > you can’t reliably tell what tags GHC uses and what tags it may use > > in the future. In the end, I used `grep` and my own eyes to check > > potentially the whole GHC codebase for tag use. > > Indeed this is bad.  Can you record the list of tags you discovered, > and where they are born, in #26264? If I’d only remember what they were. I think I remember at least how I performed this check. I may perform it again once I’ll find the time. All the best, Wolfgang From wolfgang at well-typed.com Tue Aug 5 14:26:09 2025 From: wolfgang at well-typed.com (Wolfgang Jeltsch) Date: Tue, 05 Aug 2025 17:26:09 +0300 Subject: Generating fresh names in a source plugin In-Reply-To: References: <784803a01075d640cd534b235266e61c13e0e9a9.camel@well-typed.com> <98aefac996afb9c5e6b07d5025388b98ae4b3523.camel@well-typed.com> <3020D236-1B6F-4B23-97CB-A6DC456B8D55@mail.uni-kiel.de> <53097091b46088544ac05847ad2554ea453da635.camel@well-typed.com> Message-ID: <92bb5388dccbdd2f74981f4a346993e33adcd283.camel@well-typed.com> Am Montag, dem 04.08.2025 um 18:37 -0400 schrieb Brandon Allbery: > And indeed, there is `Note [Uniques for wired-in prelude things and > known tags]` in compiler/GHC/Builtin/Uniques.hs. This doesn’t list which tags cause special compiler behavior, only which ones are used by GHC in general. Also, it is by no means clear that this list is comprehensive. It seems that its authors were partly even unsure about tag meaning: the entry for tag `a` has a question mark. Finally, this list leaves questions open. It sometimes only mentions compiler components to which certain tags are related but not for what kinds of uniques they are actually used (and not even whether said uniques are introduced or used by the mentioned compiler components). All the best, Wolfgang From wolfgang at well-typed.com Tue Aug 5 14:42:41 2025 From: wolfgang at well-typed.com (Wolfgang Jeltsch) Date: Tue, 05 Aug 2025 17:42:41 +0300 Subject: Generating fresh names in a source plugin In-Reply-To: <10a80b51dbcefa08188b30017c266612ea428dc3.camel@well-typed.com> References: <784803a01075d640cd534b235266e61c13e0e9a9.camel@well-typed.com> <98aefac996afb9c5e6b07d5025388b98ae4b3523.camel@well-typed.com> <3020D236-1B6F-4B23-97CB-A6DC456B8D55@mail.uni-kiel.de> <53097091b46088544ac05847ad2554ea453da635.camel@well-typed.com> <10a80b51dbcefa08188b30017c266612ea428dc3.camel@well-typed.com> Message-ID: Am Dienstag, dem 05.08.2025 um 17:18 +0300 schrieb Wolfgang Jeltsch: > Am Montag, dem 04.08.2025 um 23:18 +0100 schrieb Simon Peyton Jones: > > > > > you can’t reliably tell what tags GHC uses and what tags it may > > > use > > > in the future. In the end, I used `grep` and my own eyes to check > > > potentially the whole GHC codebase for tag use. > > > > Indeed this is bad.  Can you record the list of tags you discovered, > > and where they are born, in #26264? > > If I’d only remember what they were. I think I remember at least how I > performed this check. I may perform it again once I’ll find the time. I pretended that I had time immediately and searched again. The results are at https://gitlab.haskell.org/ghc/ghc/-/issues/26264#note_630286 and in the follow-up comments of mine. All the best, Wolfgang From allbery.b at gmail.com Tue Aug 5 14:55:14 2025 From: allbery.b at gmail.com (Brandon Allbery) Date: Tue, 5 Aug 2025 10:55:14 -0400 Subject: Generating fresh names in a source plugin In-Reply-To: <92bb5388dccbdd2f74981f4a346993e33adcd283.camel@well-typed.com> References: <784803a01075d640cd534b235266e61c13e0e9a9.camel@well-typed.com> <98aefac996afb9c5e6b07d5025388b98ae4b3523.camel@well-typed.com> <3020D236-1B6F-4B23-97CB-A6DC456B8D55@mail.uni-kiel.de> <53097091b46088544ac05847ad2554ea453da635.camel@well-typed.com> <92bb5388dccbdd2f74981f4a346993e33adcd283.camel@well-typed.com> Message-ID: Right, so I'm suggesting that any changes or additions should be recorded in that Note so it can be the primary source of information on tags that it apparently wanted to be. And perhaps it deserves special mention in the Commentary as such. On Tue, Aug 5, 2025 at 10:26 AM Wolfgang Jeltsch wrote: > Am Montag, dem 04.08.2025 um 18:37 -0400 schrieb Brandon Allbery: > > And indeed, there is `Note [Uniques for wired-in prelude things and > > known tags]` in compiler/GHC/Builtin/Uniques.hs. > > This doesn’t list which tags cause special compiler behavior, only which > ones are used by GHC in general. > > Also, it is by no means clear that this list is comprehensive. It seems > that its authors were partly even unsure about tag meaning: the entry > for tag `a` has a question mark. > > Finally, this list leaves questions open. It sometimes only mentions > compiler components to which certain tags are related but not for what > kinds of uniques they are actually used (and not even whether said > uniques are introduced or used by the mentioned compiler components). > > All the best, > Wolfgang > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > -- brandon s allbery kf8nh allbery.b at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From zubin at well-typed.com Wed Aug 6 10:20:57 2025 From: zubin at well-typed.com (Zubin Duggal) Date: Wed, 6 Aug 2025 15:50:57 +0530 Subject: GHC 9.10.3-rc2 is now available Message-ID: <2pvhnbxa5lneok2e3ohskt3tcntqpoclxmptdk2qoquack5ovy@ofgaqxjmynll> The GHC developers are very pleased to announce the availability of the second release candidate for GHC 9.10.3. Binary distributions, source distributions, and documentation are available at [downloads.haskell.org][] and via [GHCup](https://www.haskell.org/ghcup/). GHC 9.10.3 is a bug-fix release fixing over 50 issues of a variety of severities and scopes. A full accounting of these fixes can be found in the [release notes][]. As always, GHC's release status, including planned future releases, can be found on the GHC Wiki [status][]. The changes from the first release candidate are: - Bumping the text submodule to 2.1.3 - Reverting a bug fix (!14291) that restricted previously allowed namespace specifiers (#26250) - Reverting the bump of the deepseq submodule to 1.5.2.0 (#26251) This release candidate will have a two-week testing period. If all goes well the final release will be available the week of 19 August 2025. We would like to thank Well-Typed, Tweag I/O, Juspay, QBayLogic, Channable, Serokell, 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. [release notes]: https://gitlab.haskell.org/ghc/ghc/-/blob/ghc-9.10/docs/users_guide/9.10.3-notes.rst?ref_type=heads&plain=1 [status]: https://gitlab.haskell.org/ghc/ghc/-/wikis/GHC-status [downloads.haskell.org]: https://downloads.haskell.org/ghc/9.10.3-rc2 [ticket]: https://gitlab.haskell.org/ghc/ghc/-/issues/new -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: not available URL: From ietf-dane at dukhovni.org Thu Aug 7 17:54:51 2025 From: ietf-dane at dukhovni.org (Viktor Dukhovni) Date: Fri, 8 Aug 2025 03:54:51 +1000 Subject: Type variable scope in typed Template Haskell splices? Message-ID: With the code below my signature as "Splice.hs", three nearly identical splices are defined: `good1`, `good2` and `bad`. They differ in how conversion of Int to/from Word is orchestrated around a call to the typed splice `go` whose underlying type is: Code m (Unsigned a -> Unsigned a) In the "good" variants, either the input conversion (a -> Unsigned a) or the output conversion (Unsigned a -> a) is done via a class method of `IntLike a`, the converse conversion just uses `fromIntegral`. In the "bad" variant, both use `fromIntegral`. The module compiles, but there are type inference isssues when attempting to use `bad` as a splice, that don't occur with either of the "bad" variants. Is this to be expected? $ ghci -v0 -XTemplateHaskell Splice.hs λ> :t good1 good1 :: (IntLike a, Lift a, Lift (Unsigned a), Quote m) => a -> Code m (a -> a) λ> :t good2 good2 :: (IntLike a, Lift a, Lift (Unsigned a), Quote m) => a -> Code m (a -> a) λ> :t bad bad :: (IntLike a, IntLike (Unsigned a), Lift a, Lift (Unsigned a), Quote m) => a -> Code m (a -> a) λ> f :: Word -> Word; f = $$(good1 42) λ> g :: Word -> Word; g = $$(good2 42) λ> h :: Word -> Word; h = $$(bad 42) :6:26: error: [GHC-39999] • Ambiguous type variable ‘a0’ arising from a use of ‘meth’ prevents the constraint ‘(WordLike a0)’ from being solved. Relevant bindings include w_a2MX :: a0 (bound at :6:26) Probable fix: use a type annotation to specify what ‘a0’ should be. Potentially matching instances: instance WordLike Int -- Defined at Splice.hs:7:10 instance WordLike Word -- Defined at Splice.hs:6:10 • In the expression: meth (fromIntegral 42) w_a2MX In the first argument of ‘($)’, namely ‘(\ w_a2MX -> meth (fromIntegral 42) w_a2MX)’ In the second argument of ‘($)’, namely ‘((\ w_a2MX -> meth (fromIntegral 42) w_a2MX) $ fromIntegral i_a2MW)’ Why does the `bad` splice fail to capture the full context of the `go` method, which one might expect to restrict the `fromIntegral` instance to be either `a -> Unsigned a` or `Unsigned a -> a` just like the `a2w` and `w2a` methods? It seems that despite "ScopedTypeVariables" and the explicit type signature go :: Code m (Unsigned a -> Unsigned a) the $$(go) splice is not tied to the same `a` as one might naïvely expect. I can write: bad i = [|| \(i :: a) -> fromIntegral $ $$(go) $ fromIntegral @a @(Unsigned a) i ||] and though that compiles, runs and produces correct results, it elicits warnings: Splice.hs:30:20: warning: [GHC-86357] [-Wbadly-staged-types] Badly staged type: a is bound at stage 1 but used at stage 2 | 30 | bad i = [|| \(i :: a) -> fromIntegral $ $$(go) $ fromIntegral @a @(Unsigned a) i ||] | ^ Splice.hs:30:64: warning: [GHC-86357] [-Wbadly-staged-types] Badly staged type: a is bound at stage 1 but used at stage 2 | 30 | bad i = [|| \(i :: a) -> fromIntegral $ $$(go) $ fromIntegral @a @(Unsigned a) i ||] | ^ Splice.hs:30:77: warning: [GHC-86357] [-Wbadly-staged-types] Badly staged type: a is bound at stage 1 but used at stage 2 | 30 | bad i = [|| \(i :: a) -> fromIntegral $ $$(go) $ fromIntegral @a @(Unsigned a) i ||] | ^ In a benchmark module with a somewhat fancier splice of the "bad" sort, the use-site only compiles if both the "ScopedTypeVariables" and "TypeApplications" extensions are enabled at that the use-site, and the warnings are still produced when compiling the module that defines the splice. -- Viktor. 🇺🇦 Слава Україні! {-# LANGUAGE ScopedTypeVariables , TemplateHaskellQuotes, TypeFamilies #-} module Splice(good1, good2, bad) where import Language.Haskell.TH.Syntax class (Integral a) => WordLike a where meth :: a -> a -> a instance WordLike Word where meth = (+) instance WordLike Int where meth = (+) class (WordLike (Unsigned a), WordLike a) => IntLike a where type Unsigned a w2a :: Unsigned a -> a a2w :: a -> Unsigned a instance IntLike Word where { type Unsigned _ = Word; w2a = id; a2w = id } instance IntLike Int where { type Unsigned _ = Word; w2a = fromIntegral; a2w = fromIntegral } good1 :: forall a m. (IntLike a, Lift a, Lift (Unsigned a), Quote m) => a -> Code m (a -> a) good1 i = [|| \i -> w2a $ $$(go) $ fromIntegral i ||] where go :: Code m (Unsigned a -> Unsigned a) go = [|| \w -> meth (fromIntegral i) w ||] good2 :: forall a m. (IntLike a, Lift a, Lift (Unsigned a), Quote m) => a -> Code m (a -> a) good2 i = [|| \i -> fromIntegral $ $$(go) $ a2w i ||] where go :: Code m (Unsigned a -> Unsigned a) go = [|| \w -> meth (fromIntegral i) w ||] bad :: forall a m. (IntLike a, IntLike (Unsigned a), Lift a, Lift (Unsigned a), Quote m) => a -> Code m (a -> a) bad i = [|| \i -> fromIntegral $ $$(go) $ fromIntegral i ||] where go :: Code m (Unsigned a -> Unsigned a) go = [|| \w -> meth (fromIntegral i) w ||] From zubin at well-typed.com Fri Aug 8 12:32:26 2025 From: zubin at well-typed.com (Zubin Duggal) Date: Fri, 8 Aug 2025 18:02:26 +0530 Subject: GHC 9.10.3-rc3 is now available Message-ID: The GHC developers are very pleased to announce the availability of the third release candidate for GHC 9.10.3. Binary distributions, source distributions, and documentation are available at [downloads.haskell.org][] and via [GHCup](https://www.haskell.org/ghcup/). GHC 9.10.3 is a bug-fix release fixing over 50 issues of a variety of severities and scopes. A full accounting of these fixes can be found in the [release notes][]. As always, GHC's release status, including planned future releases, can be found on the GHC Wiki [status][]. The changes from the second release candidate are: - Reverting a change the exports of the `Backtrace` constructor in the base library that was backported due to confusion on CLC approvals (!14587) - Reverting a change to the configure script (!14324) that dropped probing for ld.gold This release candidate will have a two-week testing period. If all goes well the final release will be available the week of 22 August 2025. We would like to thank Well-Typed, Tweag I/O, Juspay, QBayLogic, Channable, Serokell, 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. [release notes]: https://gitlab.haskell.org/ghc/ghc/-/blob/ghc-9.10/docs/users_guide/9.10.3-notes.rst?ref_type=heads&plain=1 [status]: https://gitlab.haskell.org/ghc/ghc/-/wikis/GHC-status [downloads.haskell.org]: https://downloads.haskell.org/ghc/9.10.3-rc3 [ticket]: https://gitlab.haskell.org/ghc/ghc/-/issues/new -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: not available URL: From ietf-dane at dukhovni.org Fri Aug 8 12:44:26 2025 From: ietf-dane at dukhovni.org (Viktor Dukhovni) Date: Fri, 8 Aug 2025 22:44:26 +1000 Subject: GHC 9.10.3-rc3 is now available In-Reply-To: References: Message-ID: On Fri, Aug 08, 2025 at 06:02:26PM +0530, Zubin Duggal wrote: > The GHC developers are very pleased to announce the availability > of the third release candidate for GHC 9.10.3. Binary distributions, source > distributions, and documentation are available at [downloads.haskell.org][] and > via [GHCup](https://www.haskell.org/ghcup/). > > GHC 9.10.3 is a bug-fix release fixing over 50 issues of a variety of > severities and scopes. A full accounting of these fixes can be found in the > [release notes][]. As always, GHC's release status, including planned future > releases, can be found on the GHC Wiki [status][]. Is there an associated git tag? Even after "git fetch origin", all I see are: $ git tag -l | grep 'ghc-9.10\>' ghc-9.10.1-alpha1 ghc-9.10.1-alpha2 ghc-9.10.1-alpha3 ghc-9.10.1-rc1 ghc-9.10.1-release ghc-9.10.2-rc1 ghc-9.10.2-release ghc-9.10.3-rc1 ghc-9.10.3-rc2 -- Viktor. 🇺🇦 Слава Україні! From zubin at well-typed.com Fri Aug 8 17:15:40 2025 From: zubin at well-typed.com (Zubin) Date: Fri, 08 Aug 2025 22:45:40 +0530 Subject: GHC 9.10.3-rc3 is now available In-Reply-To: References: Message-ID: Sorry, I just pushed the tag. On 8 August 2025 6:14:26 pm IST, Viktor Dukhovni wrote: >On Fri, Aug 08, 2025 at 06:02:26PM +0530, Zubin Duggal wrote: > >> The GHC developers are very pleased to announce the availability >> of the third release candidate for GHC 9.10.3. Binary distributions, source >> distributions, and documentation are available at [downloads.haskell.org][] and >> via [GHCup](https://www.haskell.org/ghcup/). >> >> GHC 9.10.3 is a bug-fix release fixing over 50 issues of a variety of >> severities and scopes. A full accounting of these fixes can be found in the >> [release notes][]. As always, GHC's release status, including planned future >> releases, can be found on the GHC Wiki [status][]. > >Is there an associated git tag? Even after "git fetch origin", all I >see are: > > $ git tag -l | grep 'ghc-9.10\>' > ghc-9.10.1-alpha1 > ghc-9.10.1-alpha2 > ghc-9.10.1-alpha3 > ghc-9.10.1-rc1 > ghc-9.10.1-release > ghc-9.10.2-rc1 > ghc-9.10.2-release > ghc-9.10.3-rc1 > ghc-9.10.3-rc2 > >-- > Viktor. 🇺🇦 Слава Україні! >_______________________________________________ >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 diegorosario2013 at gmail.com Mon Aug 11 01:04:08 2025 From: diegorosario2013 at gmail.com (Diego Antonio Rosario Palomino) Date: Sun, 10 Aug 2025 20:04:08 -0500 Subject: Proposal: Roundtrip serialization of Cmm (parser-compatible pretty-printer output) In-Reply-To: <8734a7aqlg.fsf@smart-cactus.org> References: <8734a7aqlg.fsf@smart-cactus.org> Message-ID: Thanks I opened a discourse thread about this https://discourse.haskell.org/t/the-differences-between-cmm-parser-and-pretty-printer/12673 El lun, 4 ago 2025 a la(s) 1:28 p.m., Ben Gamari (ben at smart-cactus.org) escribió: > Diego Antonio Rosario Palomino writes: > > >>Hi Diego, > > > >>In the future it would make things easier if you could use one of the > >>common email quoting conventions (i.e. starting lines with >). It is > >>otherwise a bit hard to distinguish your replies from the questions > >>you are responding to. > > > > I am sorry, Ben Gamari. I am not used to working in mailing lists. > > > > I also messed up the formatting in my last reply. I accidentally created > a > > second topic (but this comment uses the original topic). > > > > Please tell me if this comment uses an appropriate format so I can > proceed > > to answer the rest of your reply. > > > Yes, this is fine. > > > > Would it be acceptable to use Discourse for my next topic regarding this > > project? (Maybe with a link here, on this mailing list.) > > > Yes, but do try to leave a link here as well to ensure that your post is > seen. > > Cheers, > > - Ben > -------------- next part -------------- An HTML attachment was scrubbed... URL: From klebinger.andreas at gmx.at Tue Aug 12 11:25:27 2025 From: klebinger.andreas at gmx.at (Andreas Klebinger) Date: Tue, 12 Aug 2025 13:25:27 +0200 Subject: 9.14 progress update Message-ID: I'm merely forwarding this from ghc-releases for those not following there: Hi all, A brief update on the GHC 9.14 release status. As noted last time, the release process has been held up by a few significant bodies of on-going work: - the upgrade of the Windows toolchain which has revealed a number of linking issues, - enabling support for LLVM 20 (#26267), along with the resolution of a few correctness issues which were uncovered in the process (#26109) - the resolution to #23109, a rather invasive correctness fix which we want to ensure is adequately tested prior to the release, At this point we have resolved, or are close to resolving, all of these issues. We expect that #23109 will land today, with the resolution to #26109 hopefully landing shortly thereafter. One wrinkle here is a late request for a boot library bump (#26268) which has had a number of knock-on effects. We are still trying to land this in `master`; we tentatively plan to backport but given how the state of the release process we will not delay the release if things do not go smoothly. Once the above has happened we will backport to `ghc-9.14` and begin preparation of the first alpha release. This may happen as soon as Thursday. Cheers, - Ben -------------- next part -------------- An HTML attachment was scrubbed... URL: From matthewtpickering at gmail.com Tue Aug 12 11:27:31 2025 From: matthewtpickering at gmail.com (Matthew Pickering) Date: Tue, 12 Aug 2025 12:27:31 +0100 Subject: 9.14 progress update In-Reply-To: References: Message-ID: Hi, Thanks for the update Ben. Can you clarify the timeline now? It seems that there is a plan to merge !10479 into the 9.14 branch. https://gitlab.haskell.org/ghc/ghc/-/merge_requests/10479 !10479 appears to be a very significant patch which touches many sensitive areas of the compiler. I believe regressions will be reported due to this patch. It also will be merged two months after the merge deadline for the branch and the release schedule seems to have already slipped significantly. Therefore, I believe it would be prudent to delay merging this one until the 9.16 release so that regressions can be discovered and fixed before it is released to users. Cheers, Matt On Tue, Aug 12, 2025 at 12:25 PM Andreas Klebinger via ghc-devs wrote: > > I'm merely forwarding this from ghc-releases for those not following there: > > Hi all, > > A brief update on the GHC 9.14 release status. As noted last time, the > release process has been held up by a few significant bodies of on-going > work: > > - the upgrade of the Windows toolchain which has revealed a number of > linking issues, > > - enabling support for LLVM 20 (#26267), along with the resolution of > a few correctness issues which were uncovered in the process (#26109) > > - the resolution to #23109, a rather invasive correctness fix which we > want to ensure is adequately tested prior to the release, > > At this point we have resolved, or are close to resolving, all of these > issues. We expect that #23109 will land today, with the resolution to > #26109 hopefully landing shortly thereafter. > > One wrinkle here is a late request for a boot library bump (#26268) > which has had a number of knock-on effects. We are still trying to > land this in `master`; we tentatively plan to backport but given how > the state of the release process we will not delay the release if things > do not go smoothly. > > Once the above has happened we will backport to `ghc-9.14` and begin > preparation of the first alpha release. This may happen as soon as > Thursday. > > Cheers, > > - Ben > > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs From klebinger.andreas at gmx.at Tue Aug 12 16:29:42 2025 From: klebinger.andreas at gmx.at (Andreas Klebinger) Date: Tue, 12 Aug 2025 18:29:42 +0200 Subject: 9.14 progress update In-Reply-To: References: Message-ID: I will leave it to Ben to expand on the timeline. As for !10479 the decision to merge this in 9.14 has been made on 15th of July. Since 9.14 is going to be an LTS release, ultimately the choice was between: * A increased workload for many backports over the next years by pushing it to 9.16.    Accompanied by a further delay of resolving bugs related to polymorphic specialisation. * The risk of introducing bugs through landing it now and a potential delay of 9.16 While bugs are always a risk, pushing it to 9.16 is unlikely to meaningfully reduce the number of bugs landing this will incur. In the end those bugs will need to be fixed, be that in 9.14.2 or 9.16.2. It's not uncommon to identify *some* bugs in patches on master. However with !10479 there has been more testing than usual on the MR pre-merge. Including not just head.hackage but also other packages. Reducing the risk associated with this somewhat. With 9.14 having a planned lifetime of potentially three years, backporting through this change would add up to a fairly high cost over time. Which is the main argument for landing this patch in 9.14. This was discussed in the GHC call and ultimately we came to the conclusion that given the resources available, and the state and nature of the patch landing it for 9.14 is the preferable option. Since then not much has changed. While pushing the MR back to 9.16 *now* would be possible, it's unclear this would change the release date meaningfully. After all there are other unresolved blockers for the first alpha for 9.14. It's also worth pointing out that most of the delays on 9.14 had to do with toolchain issues and were not related to this patch being included at all. Should !10479 become the sole blocker for a number of days, or should a large number of issues be discovered that can be traced back to it during the alpha it would make sense to reevaluate this decision. We have never ruled out this option completely. However today I still believe going forward with !10479 being included in 9.14 is in the best interest of the GHC project. Especially because it will reduce the cost of maintaining the LTS branch going forward. Cheers Andreas On 12/08/2025 13:27, Matthew Pickering wrote: > Hi, > > Thanks for the update Ben. Can you clarify the timeline now? > > It seems that there is a plan to merge !10479 into the 9.14 branch. > > https://gitlab.haskell.org/ghc/ghc/-/merge_requests/10479 > > !10479 appears to be a very significant patch which touches many > sensitive areas of the compiler. I believe regressions will be > reported due to this patch. > > It also will be merged two months after the merge deadline for the > branch and the release schedule seems to have already slipped > significantly. > > Therefore, I believe it would be prudent to delay merging this one > until the 9.16 release so that regressions can be discovered and fixed > before it is released to users. > > Cheers, > > Matt > > On Tue, Aug 12, 2025 at 12:25 PM Andreas Klebinger via ghc-devs > wrote: >> I'm merely forwarding this from ghc-releases for those not following there: >> >> Hi all, >> >> A brief update on the GHC 9.14 release status. As noted last time, the >> release process has been held up by a few significant bodies of on-going >> work: >> >> - the upgrade of the Windows toolchain which has revealed a number of >> linking issues, >> >> - enabling support for LLVM 20 (#26267), along with the resolution of >> a few correctness issues which were uncovered in the process (#26109) >> >> - the resolution to #23109, a rather invasive correctness fix which we >> want to ensure is adequately tested prior to the release, >> >> At this point we have resolved, or are close to resolving, all of these >> issues. We expect that #23109 will land today, with the resolution to >> #26109 hopefully landing shortly thereafter. >> >> One wrinkle here is a late request for a boot library bump (#26268) >> which has had a number of knock-on effects. We are still trying to >> land this in `master`; we tentatively plan to backport but given how >> the state of the release process we will not delay the release if things >> do not go smoothly. >> >> Once the above has happened we will backport to `ghc-9.14` and begin >> preparation of the first alpha release. This may happen as soon as >> Thursday. >> >> Cheers, >> >> - Ben >> >> >> _______________________________________________ >> ghc-devs mailing list >> ghc-devs at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs From ben at well-typed.com Tue Aug 12 18:17:14 2025 From: ben at well-typed.com (Ben Gamari) Date: Tue, 12 Aug 2025 14:17:14 -0400 Subject: 9.14 progress update In-Reply-To: References: Message-ID: <87ectg76c8.fsf@smart-cactus.org> Matthew Pickering writes: > Hi, > > Thanks for the update Ben. Can you clarify the timeline now? > Sure, As of today we three blocking patches away from having a branch we can cut a prerelease from: * !10479 * !14620 In addition, there are a few not-quite-blockers which I am aiming to merge: * !14644 * !14600 * !14609 My hope is that these can be merged by Thursday, at which point we may be able have a release pipeline ready by Friday evening (15 Aug) or Monday (18 Aug). This will be the first alpha. Beyond that, the tentative plan is that the second alpha will follow three weeks after the first (e.g. 5 Sept). The release candidate will following three weeks after that (26 Sept), with the final release coming two weeks later (10 Oct). This is a bit more condensed than the usual release schedule, but ultimately we would rather avoid prolonging the process too far beyond the original plan. Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 255 bytes Desc: not available URL: