From arnaud.spiwack at tweag.io Thu Jan 9 06:31:00 2025 From: arnaud.spiwack at tweag.io (Arnaud Spiwack) Date: Thu, 9 Jan 2025 15:31:00 +0900 Subject: [ghc-steering-committee] #682: Explicit Level Imports, recommendation: accept Message-ID: Mathew Pickering, Rodrigo Mesquita, and our own Adam Gundry put forward a new proposal for the perenial problem of dependencies and Template Haskell https://github.com/ghc-proposals/ghc-proposals/pull/682 I've got to be honest, I'm not fully convinced by the proposal. More on that in a minute, but it learns a lesson from previous attempts at the same problem by solving the absolute minimal problem, but this leads to a somewhat fork-like situation for which it isn't clear whether it will be resolved in the future. That being said, it solves a real problem which has plagued GHC compilation forever. And I'm inclined to believe that we can't really do much better. But I'm getting ahead of myself. The problem is that when you have -XTemplateHaskell in a file, all the dependencies' compiled code must suddenly be available for typechecking. This breaks `-fno-code` and wounds recompilation avoidance. This is probably the main reason why it's a widely held belief that Template Haskell is slow: you use Template Haskell in a few modules, and suddenly your IDE is much less responsive and you recompile more files. Yay? Anyway, the general gist of the solution is clear: we must be able to specify that we don't want to import a module for Template Haskell (there is subtleties in this too as you will want a little more control than that for cross-compilation reasons which I'm not competent about to comment on). But the devil is in the many details. There's this thing called implicit cross-stage persistence which says that anything you import not-for-template-haskell is going to be available in quotes and splices anyway. Sigh… So you have to turn this off. This is what the proposal does. And pretty much only. They introduce a new extension-XNoImplicitStagePersistence which disables that, and a little bit of syntax to specify the stage of imports. That's it. But it comes with severe limitations, most importantly: you can't ever use a symbol defined in the current module in a quote or splice of this current module, typed template Haskell is turned off. For these situations, the proposal kind of advertises using `-XImplicitStagePersistence`. Which does seem like a fork-like situation to me. Not cool. Yet… yet Template Haskell is a big messy ball of yarn, and I don't think it's fair to ask of any proposal to entangle it completely. The failure of past attempts seem to support this case. And I believe the authors are correct when they claim that this proposal, in practice, covers a vast majority of the uses of Template Haskell out there. So maybe we can see that as a new foundation for Template Haskell. I'm not thrilled about it, but it's probably the most reasonable way forward. The real problem with this sort of proposal is that then I get to write way too long an email to the committee. Hopefully this didn't deter you. Read the proposal, and let's vote. -- Arnaud Spiwack Director, Research at https://moduscreate.com and https://tweag.io. -------------- next part -------------- An HTML attachment was scrubbed... URL: From arnaud.spiwack at tweag.io Thu Jan 9 06:34:33 2025 From: arnaud.spiwack at tweag.io (Arnaud Spiwack) Date: Thu, 9 Jan 2025 15:34:33 +0900 Subject: [ghc-steering-committee] #682: Explicit Level Imports, recommendation: accept In-Reply-To: References: Message-ID: I forgot: there's a bunch of alternative syntax, so if you don't like the proposed syntax, please let us know which alternative you prefer. On Thu, 9 Jan 2025 at 15:31, Arnaud Spiwack wrote: > > Mathew Pickering, Rodrigo Mesquita, and our own Adam Gundry put forward a > new proposal for the perenial problem of dependencies and Template Haskell > https://github.com/ghc-proposals/ghc-proposals/pull/682 > > I've got to be honest, I'm not fully convinced by the proposal. More on > that in a minute, but it learns a lesson from previous attempts at the same > problem by solving the absolute minimal problem, but this leads to a > somewhat fork-like situation for which it isn't clear whether it will be > resolved in the future. That being said, it solves a real problem which has > plagued GHC compilation forever. And I'm inclined to believe that we can't > really do much better. > > But I'm getting ahead of myself. The problem is that when you have > -XTemplateHaskell in a file, all the dependencies' compiled code must > suddenly be available for typechecking. This breaks `-fno-code` and wounds > recompilation avoidance. This is probably the main reason why it's a widely > held belief that Template Haskell is slow: you use Template Haskell in a > few modules, and suddenly your IDE is much less responsive and you > recompile more files. Yay? > > Anyway, the general gist of the solution is clear: we must be able to > specify that we don't want to import a module for Template Haskell (there > is subtleties in this too as you will want a little more control than that > for cross-compilation reasons which I'm not competent about to comment on). > But the devil is in the many details. There's this thing called implicit > cross-stage persistence which says that anything you import > not-for-template-haskell is going to be available in quotes and splices > anyway. Sigh… So you have to turn this off. This is what the proposal does. > And pretty much only. > > They introduce a new extension-XNoImplicitStagePersistence which disables > that, and a little bit of syntax to specify the stage of imports. That's it. > > But it comes with severe limitations, most importantly: you can't ever use > a symbol defined in the current module in a quote or splice of this current > module, typed template Haskell is turned off. > > For these situations, the proposal kind of advertises using > `-XImplicitStagePersistence`. Which does seem like a fork-like situation to > me. Not cool. Yet… yet Template Haskell is a big messy ball of yarn, and I > don't think it's fair to ask of any proposal to entangle it completely. The > failure of past attempts seem to support this case. And I believe the > authors are correct when they claim that this proposal, in practice, covers > a vast majority of the uses of Template Haskell out there. So maybe we can > see that as a new foundation for Template Haskell. I'm not thrilled about > it, but it's probably the most reasonable way forward. > > The real problem with this sort of proposal is that then I get to write > way too long an email to the committee. Hopefully this didn't deter you. > Read the proposal, and let's vote. > > -- > Arnaud Spiwack > Director, Research at https://moduscreate.com and https://tweag.io. > -- Arnaud Spiwack Director, Research at https://moduscreate.com and https://tweag.io. -------------- next part -------------- An HTML attachment was scrubbed... URL: From adam at well-typed.com Fri Jan 10 09:18:49 2025 From: adam at well-typed.com (Adam Gundry) Date: Fri, 10 Jan 2025 09:18:49 +0000 Subject: [ghc-steering-committee] #682: Explicit Level Imports, recommendation: accept In-Reply-To: References: Message-ID: <0b6b01fb-d79b-45cf-847b-a6aeb63ee514@well-typed.com> Thanks Arnaud! With my "proposal co-author" hat on, I'd like to make a few points inline... On 09/01/2025 06:34, Arnaud Spiwack wrote: > > On Thu, 9 Jan 2025 at 15:31, Arnaud Spiwack > wrote: > > [...] > > They introduce a new extension-XNoImplicitStagePersistence which > disables that, and a little bit of syntax to specify the stage of > imports. That's it. > > But it comes with severe limitations, most importantly: you can't > ever use a symbol defined in the current module in a quote or splice > of this current module, typed template Haskell is turned off. Regarding typed TH, the proposal currently grants a bit of flexibility to the implementation in suggesting that TTH might not be supported at all, primarily because TTH has some existing unresolved issues around constraints. We could alternately say that TTH remains available (but also remains somewhat broken, because fixing it is out of scope of the implementation of this proposal). > For these situations, the proposal kind of advertises using > `-XImplicitStagePersistence`. Which does seem like a fork-like > situation to me. Not cool. Rather than seeing ImplicitStagePersistence as creating a language fork, I see it as necessary for backwards compatibility, but with the intention that in the long term NoImplicitStagePersistence is the way to go. This may still be difficult in some cases (e.g. codebases that make heavy use of Lift), but the idea is to start with a simple, restrictive baseline (NoImplicitStagePersistence) and then gradually add features relaxing this as needed (ExplicitLevelImports being the first of these, but perhaps later something for multiple levels within a single file). Cheers, Adam -- Adam Gundry, Haskell Consultant Well-Typed LLP, https://www.well-typed.com/ Registered in England & Wales, OC335890 27 Old Gloucester Street, London WC1N 3AX, England From moritz.angermann at gmail.com Fri Jan 10 11:19:39 2025 From: moritz.angermann at gmail.com (Moritz Angermann) Date: Fri, 10 Jan 2025 20:19:39 +0900 Subject: [ghc-steering-committee] #682: Explicit Level Imports, recommendation: accept In-Reply-To: <0b6b01fb-d79b-45cf-847b-a6aeb63ee514@well-typed.com> References: <0b6b01fb-d79b-45cf-847b-a6aeb63ee514@well-typed.com> Message-ID: Hi all, I'm generally in support of this proposal. As many of you know, I strongly believe TemplateHaskell is a major wart that Haskell has, for many reasons. This proposal tries to address at least one of those: adding more clarity and explicitness about dependencies. It may help with cross compilation in that we have a clearer idea of what we exactly need to load in iserv (alternatives where we implicit link a runnable for target evaluation, can rely on dead code elimination for this, but having this from the start would already be helpful). I've recently been looking a lot at Zig's comptime, as they seem to have gone down almost the same route. Maybe there's some inspiration to be drawn from Zig's solution in the future. It is, however, WAY more restrictive than what we currently have in the form of TemplateHaskell. +1 on this one. Best, Moritz On Fri, 10 Jan 2025 at 18:19, Adam Gundry wrote: > Thanks Arnaud! With my "proposal co-author" hat on, I'd like to make a > few points inline... > > > On 09/01/2025 06:34, Arnaud Spiwack wrote: > > > > On Thu, 9 Jan 2025 at 15:31, Arnaud Spiwack > > wrote: > > > > [...] > > > > They introduce a new extension-XNoImplicitStagePersistence which > > disables that, and a little bit of syntax to specify the stage of > > imports. That's it. > > > > But it comes with severe limitations, most importantly: you can't > > ever use a symbol defined in the current module in a quote or splice > > of this current module, typed template Haskell is turned off. > > Regarding typed TH, the proposal currently grants a bit of flexibility > to the implementation in suggesting that TTH might not be supported at > all, primarily because TTH has some existing unresolved issues around > constraints. We could alternately say that TTH remains available (but > also remains somewhat broken, because fixing it is out of scope of the > implementation of this proposal). > > > > For these situations, the proposal kind of advertises using > > `-XImplicitStagePersistence`. Which does seem like a fork-like > > situation to me. Not cool. > > Rather than seeing ImplicitStagePersistence as creating a language fork, > I see it as necessary for backwards compatibility, but with the > intention that in the long term NoImplicitStagePersistence is the way to > go. This may still be difficult in some cases (e.g. codebases that make > heavy use of Lift), but the idea is to start with a simple, restrictive > baseline (NoImplicitStagePersistence) and then gradually add features > relaxing this as needed (ExplicitLevelImports being the first of these, > but perhaps later something for multiple levels within a single file). > > Cheers, > > Adam > > > -- > Adam Gundry, Haskell Consultant > Well-Typed LLP, https://www.well-typed.com/ > > Registered in England & Wales, OC335890 > 27 Old Gloucester Street, London WC1N 3AX, England > > _______________________________________________ > ghc-steering-committee mailing list > ghc-steering-committee at haskell.org > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sgraf1337 at gmail.com Mon Jan 13 08:27:11 2025 From: sgraf1337 at gmail.com (Sebastian Graf) Date: Mon, 13 Jan 2025 09:27:11 +0100 Subject: [ghc-steering-committee] #682: Explicit Level Imports, recommendation: accept In-Reply-To: References: <0b6b01fb-d79b-45cf-847b-a6aeb63ee514@well-typed.com> Message-ID: Hi, I vote to accept this proposal. I would have liked to see a clear specification of what gets compiled when with -XImplicitStagePersistence, but I see that this isn't strictly necessary to describe the extension in terms of the Haskell-the-language, plus it's quite complicated. I attempted to do so at the end of this post . I don't agree that -XNoImplicitStagePersistence is a fork. After all, users are not forced to use `-XNoImplicitStagePersistence` just because one of its imports uses it. Cheers, Sebastian Am Fr., 10. Jan. 2025 um 12:20 Uhr schrieb Moritz Angermann < moritz.angermann at gmail.com>: > Hi all, > > I'm generally in support of this proposal. As many of you know, I strongly > believe TemplateHaskell is a major wart that Haskell has, for many > reasons. This proposal tries to address at least one of those: adding more > clarity and explicitness about dependencies. It may help with > cross compilation in that we have a clearer idea of what we exactly need > to load in iserv (alternatives where we implicit link a runnable for > target evaluation, can rely on dead code elimination for this, but having > this from the start would already be helpful). > > I've recently been looking a lot at Zig's comptime, as they seem to have > gone down almost the same route. Maybe there's some inspiration to > be drawn from Zig's solution in the future. It is, however, WAY more > restrictive than what we currently have in the form of TemplateHaskell. > > +1 on this one. > > Best, > Moritz > > On Fri, 10 Jan 2025 at 18:19, Adam Gundry wrote: > >> Thanks Arnaud! With my "proposal co-author" hat on, I'd like to make a >> few points inline... >> >> >> On 09/01/2025 06:34, Arnaud Spiwack wrote: >> > >> > On Thu, 9 Jan 2025 at 15:31, Arnaud Spiwack > > > wrote: >> > >> > [...] >> > >> > They introduce a new extension-XNoImplicitStagePersistence which >> > disables that, and a little bit of syntax to specify the stage of >> > imports. That's it. >> > >> > But it comes with severe limitations, most importantly: you can't >> > ever use a symbol defined in the current module in a quote or splice >> > of this current module, typed template Haskell is turned off. >> >> Regarding typed TH, the proposal currently grants a bit of flexibility >> to the implementation in suggesting that TTH might not be supported at >> all, primarily because TTH has some existing unresolved issues around >> constraints. We could alternately say that TTH remains available (but >> also remains somewhat broken, because fixing it is out of scope of the >> implementation of this proposal). >> >> >> > For these situations, the proposal kind of advertises using >> > `-XImplicitStagePersistence`. Which does seem like a fork-like >> > situation to me. Not cool. >> >> Rather than seeing ImplicitStagePersistence as creating a language fork, >> I see it as necessary for backwards compatibility, but with the >> intention that in the long term NoImplicitStagePersistence is the way to >> go. This may still be difficult in some cases (e.g. codebases that make >> heavy use of Lift), but the idea is to start with a simple, restrictive >> baseline (NoImplicitStagePersistence) and then gradually add features >> relaxing this as needed (ExplicitLevelImports being the first of these, >> but perhaps later something for multiple levels within a single file). >> >> Cheers, >> >> Adam >> >> >> -- >> Adam Gundry, Haskell Consultant >> Well-Typed LLP, https://www.well-typed.com/ >> >> Registered in England & Wales, OC335890 >> 27 Old Gloucester Street, London WC1N 3AX, England >> >> _______________________________________________ >> ghc-steering-committee mailing list >> ghc-steering-committee at haskell.org >> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee >> > _______________________________________________ > ghc-steering-committee mailing list > ghc-steering-committee at haskell.org > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mpg at mpg.is Mon Jan 13 13:30:51 2025 From: mpg at mpg.is (=?UTF-8?Q?Matth=C3=ADas_P=C3=A1ll_Gissurarson?=) Date: Mon, 13 Jan 2025 14:30:51 +0100 Subject: [ghc-steering-committee] #682: Explicit Level Imports, recommendation: accept In-Reply-To: References: <0b6b01fb-d79b-45cf-847b-a6aeb63ee514@well-typed.com> Message-ID: I vote accept. The proposal itself is well written, and clarifies the concepts involved and the issue at hand. I am on the fence with the syntax itself. I like the one presented in the proposal, it's very clean. I was a bit worried at first with having to import the same module multiple times at different levels, but I guess that cannot really be avoided. I like Richard's comment on having different sections, a `splice` section, a level 0 section and `quote` section. I'm also not against the `{-# SPLICE #-}` syntax if we decide to go down that route, but it's a bit grittier than the keywords. On Mon, 13 Jan 2025 at 09:27, Sebastian Graf wrote: > Hi, > > I vote to accept this proposal. > > I would have liked to see a clear specification of what gets compiled when > with -XImplicitStagePersistence, but I see that this isn't strictly > necessary to describe the extension in terms of the Haskell-the-language, > plus it's quite complicated. I attempted to do so at the end of this post > > . > > I don't agree that -XNoImplicitStagePersistence is a fork. After all, > users are not forced to use `-XNoImplicitStagePersistence` just because one > of its imports uses it. > > Cheers, > Sebastian > > Am Fr., 10. Jan. 2025 um 12:20 Uhr schrieb Moritz Angermann < > moritz.angermann at gmail.com>: > >> Hi all, >> >> I'm generally in support of this proposal. As many of you know, I >> strongly believe TemplateHaskell is a major wart that Haskell has, for many >> reasons. This proposal tries to address at least one of those: adding >> more clarity and explicitness about dependencies. It may help with >> cross compilation in that we have a clearer idea of what we exactly need >> to load in iserv (alternatives where we implicit link a runnable for >> target evaluation, can rely on dead code elimination for this, but having >> this from the start would already be helpful). >> >> I've recently been looking a lot at Zig's comptime, as they seem to have >> gone down almost the same route. Maybe there's some inspiration to >> be drawn from Zig's solution in the future. It is, however, WAY more >> restrictive than what we currently have in the form of TemplateHaskell. >> >> +1 on this one. >> >> Best, >> Moritz >> >> On Fri, 10 Jan 2025 at 18:19, Adam Gundry wrote: >> >>> Thanks Arnaud! With my "proposal co-author" hat on, I'd like to make a >>> few points inline... >>> >>> >>> On 09/01/2025 06:34, Arnaud Spiwack wrote: >>> > >>> > On Thu, 9 Jan 2025 at 15:31, Arnaud Spiwack >> > > wrote: >>> > >>> > [...] >>> > >>> > They introduce a new extension-XNoImplicitStagePersistence which >>> > disables that, and a little bit of syntax to specify the stage of >>> > imports. That's it. >>> > >>> > But it comes with severe limitations, most importantly: you can't >>> > ever use a symbol defined in the current module in a quote or >>> splice >>> > of this current module, typed template Haskell is turned off. >>> >>> Regarding typed TH, the proposal currently grants a bit of flexibility >>> to the implementation in suggesting that TTH might not be supported at >>> all, primarily because TTH has some existing unresolved issues around >>> constraints. We could alternately say that TTH remains available (but >>> also remains somewhat broken, because fixing it is out of scope of the >>> implementation of this proposal). >>> >>> >>> > For these situations, the proposal kind of advertises using >>> > `-XImplicitStagePersistence`. Which does seem like a fork-like >>> > situation to me. Not cool. >>> >>> Rather than seeing ImplicitStagePersistence as creating a language fork, >>> I see it as necessary for backwards compatibility, but with the >>> intention that in the long term NoImplicitStagePersistence is the way to >>> go. This may still be difficult in some cases (e.g. codebases that make >>> heavy use of Lift), but the idea is to start with a simple, restrictive >>> baseline (NoImplicitStagePersistence) and then gradually add features >>> relaxing this as needed (ExplicitLevelImports being the first of these, >>> but perhaps later something for multiple levels within a single file). >>> >>> Cheers, >>> >>> Adam >>> >>> >>> -- >>> Adam Gundry, Haskell Consultant >>> Well-Typed LLP, https://www.well-typed.com/ >>> >>> Registered in England & Wales, OC335890 >>> 27 Old Gloucester Street, London WC1N 3AX, England >>> >>> _______________________________________________ >>> ghc-steering-committee mailing list >>> ghc-steering-committee at haskell.org >>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee >>> >> _______________________________________________ >> ghc-steering-committee mailing list >> ghc-steering-committee at haskell.org >> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee >> > _______________________________________________ > ghc-steering-committee mailing list > ghc-steering-committee at haskell.org > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee > -- -- Matthías Páll Gissurarson -------------- next part -------------- An HTML attachment was scrubbed... URL: From arnaud.spiwack at tweag.io Tue Jan 14 07:42:18 2025 From: arnaud.spiwack at tweag.io (Arnaud Spiwack) Date: Tue, 14 Jan 2025 16:42:18 +0900 Subject: [ghc-steering-committee] #682: Explicit Level Imports, recommendation: accept In-Reply-To: References: <0b6b01fb-d79b-45cf-847b-a6aeb63ee514@well-typed.com> Message-ID: Sebastian writes: > I don't agree that -XNoImplicitStagePersistence is a fork. After all, users are not forced to use `-XNoImplicitStagePersistence` just because one of its imports uses it. This isn't what we mean by forklike in our guidelines. We mean to avoid situations where the same code means different things depending on the extensions turned on and/or needing different modules having incompatible sets of extensions. Our README reads: By a "fork" we mean - It fails the test "Is this extension something that most people would be happy to enable, even if they don't want to use it?"; - And it also fails the test "Do we think there's a reasonable chance this extension will make it into a future language standard?"; that is, the proposal reflects the stylistic preferences of a subset of the Haskell community, rather than a consensus about the direction that (in the committee's judgement) we want to push the whole language. The idea is that unless we can see a path to a point where everyone has the extension turned on, we're left with different groups of people using incompatible dialects of the language. A similar problem arises with extensions that are mutually incompatible. I don't think this passes the first test, but it does pass the second (though that future is probably quite far!). And I think that the proposition that there's no way to make what we want of Template Haskell without breaking the first test is reasonable (see also Adam's email above). But still, this does create a forky situation for us, which I wouldn't be doing my job as a shepherd if I wasn't pointing it out. /Arnaud On Mon, 13 Jan 2025 at 22:31, Matthías Páll Gissurarson wrote: > I vote accept. > > The proposal itself is well written, and clarifies the concepts involved > and the issue at hand. > > I am on the fence with the syntax itself. I like the one presented in the > proposal, it's very clean. I was a bit worried at first with having to > import the same module multiple times at different levels, but I guess that > cannot really be avoided. > I like Richard's comment on having different sections, a `splice` section, > a level 0 section and `quote` section. I'm also not against the `{-# SPLICE > #-}` syntax if we decide to go down that route, but it's a bit grittier > than the keywords. > > > > On Mon, 13 Jan 2025 at 09:27, Sebastian Graf wrote: > >> Hi, >> >> I vote to accept this proposal. >> >> I would have liked to see a clear specification of what gets compiled >> when with -XImplicitStagePersistence, but I see that this isn't strictly >> necessary to describe the extension in terms of the Haskell-the-language, >> plus it's quite complicated. I attempted to do so at the end of this post >> >> . >> >> I don't agree that -XNoImplicitStagePersistence is a fork. After all, >> users are not forced to use `-XNoImplicitStagePersistence` just because one >> of its imports uses it. >> >> Cheers, >> Sebastian >> >> Am Fr., 10. Jan. 2025 um 12:20 Uhr schrieb Moritz Angermann < >> moritz.angermann at gmail.com>: >> >>> Hi all, >>> >>> I'm generally in support of this proposal. As many of you know, I >>> strongly believe TemplateHaskell is a major wart that Haskell has, for many >>> reasons. This proposal tries to address at least one of those: adding >>> more clarity and explicitness about dependencies. It may help with >>> cross compilation in that we have a clearer idea of what we exactly need >>> to load in iserv (alternatives where we implicit link a runnable for >>> target evaluation, can rely on dead code elimination for this, but >>> having this from the start would already be helpful). >>> >>> I've recently been looking a lot at Zig's comptime, as they seem to have >>> gone down almost the same route. Maybe there's some inspiration to >>> be drawn from Zig's solution in the future. It is, however, WAY more >>> restrictive than what we currently have in the form of TemplateHaskell. >>> >>> +1 on this one. >>> >>> Best, >>> Moritz >>> >>> On Fri, 10 Jan 2025 at 18:19, Adam Gundry wrote: >>> >>>> Thanks Arnaud! With my "proposal co-author" hat on, I'd like to make a >>>> few points inline... >>>> >>>> >>>> On 09/01/2025 06:34, Arnaud Spiwack wrote: >>>> > >>>> > On Thu, 9 Jan 2025 at 15:31, Arnaud Spiwack >>> > > wrote: >>>> > >>>> > [...] >>>> > >>>> > They introduce a new extension-XNoImplicitStagePersistence which >>>> > disables that, and a little bit of syntax to specify the stage of >>>> > imports. That's it. >>>> > >>>> > But it comes with severe limitations, most importantly: you can't >>>> > ever use a symbol defined in the current module in a quote or >>>> splice >>>> > of this current module, typed template Haskell is turned off. >>>> >>>> Regarding typed TH, the proposal currently grants a bit of flexibility >>>> to the implementation in suggesting that TTH might not be supported at >>>> all, primarily because TTH has some existing unresolved issues around >>>> constraints. We could alternately say that TTH remains available (but >>>> also remains somewhat broken, because fixing it is out of scope of the >>>> implementation of this proposal). >>>> >>>> >>>> > For these situations, the proposal kind of advertises using >>>> > `-XImplicitStagePersistence`. Which does seem like a fork-like >>>> > situation to me. Not cool. >>>> >>>> Rather than seeing ImplicitStagePersistence as creating a language >>>> fork, >>>> I see it as necessary for backwards compatibility, but with the >>>> intention that in the long term NoImplicitStagePersistence is the way >>>> to >>>> go. This may still be difficult in some cases (e.g. codebases that make >>>> heavy use of Lift), but the idea is to start with a simple, restrictive >>>> baseline (NoImplicitStagePersistence) and then gradually add features >>>> relaxing this as needed (ExplicitLevelImports being the first of these, >>>> but perhaps later something for multiple levels within a single file). >>>> >>>> Cheers, >>>> >>>> Adam >>>> >>>> >>>> -- >>>> Adam Gundry, Haskell Consultant >>>> Well-Typed LLP, https://www.well-typed.com/ >>>> >>>> Registered in England & Wales, OC335890 >>>> 27 Old Gloucester Street, London WC1N 3AX, England >>>> >>>> _______________________________________________ >>>> ghc-steering-committee mailing list >>>> ghc-steering-committee at haskell.org >>>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee >>>> >>> _______________________________________________ >>> ghc-steering-committee mailing list >>> ghc-steering-committee at haskell.org >>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee >>> >> _______________________________________________ >> ghc-steering-committee mailing list >> ghc-steering-committee at haskell.org >> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee >> > > > -- > -- Matthías Páll Gissurarson > _______________________________________________ > ghc-steering-committee mailing list > ghc-steering-committee at haskell.org > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee > -- Arnaud Spiwack Director, Research at https://moduscreate.com and https://tweag.io. -------------- next part -------------- An HTML attachment was scrubbed... URL: From sgraf1337 at gmail.com Tue Jan 14 08:42:43 2025 From: sgraf1337 at gmail.com (Sebastian Graf) Date: Tue, 14 Jan 2025 09:42:43 +0100 Subject: [ghc-steering-committee] #682: Explicit Level Imports, recommendation: accept In-Reply-To: References: <0b6b01fb-d79b-45cf-847b-a6aeb63ee514@well-typed.com> Message-ID: Thanks. Indeed, considering -XNoImplicitStagePersistence a fork is reasonable by that definition. Although I guess I was having trouble with interpreting "most" and "happy" in that statement of the first test... I would think that "most" people do not write Template Haskell splice functions or quote definitions (well, yet) in which case I don't think their code would be affected at all and thus would be "happy" to activate it. Regardless, I think the benefits of this proposal far outweigh the mildly forking behavior, which could be further remedied as per Adam's response. Sebastian Am Di., 14. Jan. 2025 um 08:42 Uhr schrieb Arnaud Spiwack < arnaud.spiwack at tweag.io>: > Sebastian writes: > > > I don't agree that -XNoImplicitStagePersistence is a fork. After all, > users are not forced to use `-XNoImplicitStagePersistence` just because one > of its imports uses it. > > This isn't what we mean by forklike in our guidelines. We mean to avoid > situations where the same code means different things depending on the > extensions turned on and/or needing different modules having incompatible > sets of extensions. Our README reads: > > By a "fork" we mean > > - It fails the test "Is this extension something that most people > would be happy to enable, even if they don't want to use it?"; > - And it also fails the test "Do we think there's a reasonable chance > this extension will make it into a future language standard?"; that is, the > proposal reflects the stylistic preferences of a subset of the Haskell > community, rather than a consensus about the direction that (in the > committee's judgement) we want to push the whole language. > > The idea is that unless we can see a path to a point where everyone has > the extension turned on, we're left with different groups of people using > incompatible dialects of the language. A similar problem arises with > extensions that are mutually incompatible. > > I don't think this passes the first test, but it does pass the second > (though that future is probably quite far!). And I think that the > proposition that there's no way to make what we want of Template Haskell > without breaking the first test is reasonable (see also Adam's email > above). But still, this does create a forky situation for us, which I > wouldn't be doing my job as a shepherd if I wasn't pointing it out. > /Arnaud > > On Mon, 13 Jan 2025 at 22:31, Matthías Páll Gissurarson > wrote: > >> I vote accept. >> >> The proposal itself is well written, and clarifies the concepts involved >> and the issue at hand. >> >> I am on the fence with the syntax itself. I like the one presented in the >> proposal, it's very clean. I was a bit worried at first with having to >> import the same module multiple times at different levels, but I guess that >> cannot really be avoided. >> I like Richard's comment on having different sections, a `splice` >> section, a level 0 section and `quote` section. I'm also not against the >> `{-# SPLICE #-}` syntax if we decide to go down that route, but it's a bit >> grittier than the keywords. >> >> >> >> On Mon, 13 Jan 2025 at 09:27, Sebastian Graf wrote: >> >>> Hi, >>> >>> I vote to accept this proposal. >>> >>> I would have liked to see a clear specification of what gets compiled >>> when with -XImplicitStagePersistence, but I see that this isn't strictly >>> necessary to describe the extension in terms of the Haskell-the-language, >>> plus it's quite complicated. I attempted to do so at the end of this >>> post >>> >>> . >>> >>> I don't agree that -XNoImplicitStagePersistence is a fork. After all, >>> users are not forced to use `-XNoImplicitStagePersistence` just because one >>> of its imports uses it. >>> >>> Cheers, >>> Sebastian >>> >>> Am Fr., 10. Jan. 2025 um 12:20 Uhr schrieb Moritz Angermann < >>> moritz.angermann at gmail.com>: >>> >>>> Hi all, >>>> >>>> I'm generally in support of this proposal. As many of you know, I >>>> strongly believe TemplateHaskell is a major wart that Haskell has, for many >>>> reasons. This proposal tries to address at least one of those: adding >>>> more clarity and explicitness about dependencies. It may help with >>>> cross compilation in that we have a clearer idea of what we exactly >>>> need to load in iserv (alternatives where we implicit link a runnable for >>>> target evaluation, can rely on dead code elimination for this, but >>>> having this from the start would already be helpful). >>>> >>>> I've recently been looking a lot at Zig's comptime, as they seem to >>>> have gone down almost the same route. Maybe there's some inspiration to >>>> be drawn from Zig's solution in the future. It is, however, WAY more >>>> restrictive than what we currently have in the form of TemplateHaskell. >>>> >>>> +1 on this one. >>>> >>>> Best, >>>> Moritz >>>> >>>> On Fri, 10 Jan 2025 at 18:19, Adam Gundry wrote: >>>> >>>>> Thanks Arnaud! With my "proposal co-author" hat on, I'd like to make a >>>>> few points inline... >>>>> >>>>> >>>>> On 09/01/2025 06:34, Arnaud Spiwack wrote: >>>>> > >>>>> > On Thu, 9 Jan 2025 at 15:31, Arnaud Spiwack >>>> > > wrote: >>>>> > >>>>> > [...] >>>>> > >>>>> > They introduce a new extension-XNoImplicitStagePersistence which >>>>> > disables that, and a little bit of syntax to specify the stage of >>>>> > imports. That's it. >>>>> > >>>>> > But it comes with severe limitations, most importantly: you can't >>>>> > ever use a symbol defined in the current module in a quote or >>>>> splice >>>>> > of this current module, typed template Haskell is turned off. >>>>> >>>>> Regarding typed TH, the proposal currently grants a bit of flexibility >>>>> to the implementation in suggesting that TTH might not be supported at >>>>> all, primarily because TTH has some existing unresolved issues around >>>>> constraints. We could alternately say that TTH remains available (but >>>>> also remains somewhat broken, because fixing it is out of scope of the >>>>> implementation of this proposal). >>>>> >>>>> >>>>> > For these situations, the proposal kind of advertises using >>>>> > `-XImplicitStagePersistence`. Which does seem like a fork-like >>>>> > situation to me. Not cool. >>>>> >>>>> Rather than seeing ImplicitStagePersistence as creating a language >>>>> fork, >>>>> I see it as necessary for backwards compatibility, but with the >>>>> intention that in the long term NoImplicitStagePersistence is the way >>>>> to >>>>> go. This may still be difficult in some cases (e.g. codebases that >>>>> make >>>>> heavy use of Lift), but the idea is to start with a simple, >>>>> restrictive >>>>> baseline (NoImplicitStagePersistence) and then gradually add features >>>>> relaxing this as needed (ExplicitLevelImports being the first of >>>>> these, >>>>> but perhaps later something for multiple levels within a single file). >>>>> >>>>> Cheers, >>>>> >>>>> Adam >>>>> >>>>> >>>>> -- >>>>> Adam Gundry, Haskell Consultant >>>>> Well-Typed LLP, https://www.well-typed.com/ >>>>> >>>>> Registered in England & Wales, OC335890 >>>>> 27 Old Gloucester Street, London WC1N 3AX, England >>>>> >>>>> _______________________________________________ >>>>> ghc-steering-committee mailing list >>>>> ghc-steering-committee at haskell.org >>>>> >>>>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee >>>>> >>>> _______________________________________________ >>>> ghc-steering-committee mailing list >>>> ghc-steering-committee at haskell.org >>>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee >>>> >>> _______________________________________________ >>> ghc-steering-committee mailing list >>> ghc-steering-committee at haskell.org >>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee >>> >> >> >> -- >> -- Matthías Páll Gissurarson >> _______________________________________________ >> ghc-steering-committee mailing list >> ghc-steering-committee at haskell.org >> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee >> > > > -- > Arnaud Spiwack > Director, Research at https://moduscreate.com and https://tweag.io. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jakob.bruenker at gmail.com Tue Jan 14 22:45:18 2025 From: jakob.bruenker at gmail.com (=?UTF-8?Q?Jakob_Br=C3=BCnker?=) Date: Tue, 14 Jan 2025 23:45:18 +0100 Subject: [ghc-steering-committee] #621: Linear constraints, recommendation: accept Message-ID: Dear committee, Arnaud Spiwack and Jack Hughes propose to introduce linear constraints. These work analogously to linear functions - as can be seen with the new syntax, which is %1 =>, reflecting the existing %1 ->. The motivation is that these constraints make it possible to design linearly typed APIs that are more convenient to use: Without the linear constraints, tokens would have to be passed manually into each function in these cases. The proposal also introduces dupable classes, which can be used multiple times even when they appear in a linear context, but cannot be passed to an unrestricted function. This is necessary to make some API designs work, see the proposal for details. To me, it seems that this proposal or something like it is necessary to unlock the full potential of linear types. The proposal lays out why monadic API designs don't provide the same benefits, and while there are potential future GHC developments that could make using it even more convenient (existential types, strict let improvements; see proposal), I believe it would already be sufficiently useful with today's GHC to be a valuable addition. Thus, I recommend acceptance. Please read through the proposal and voice your opinions. Best, Jakob -------------- next part -------------- An HTML attachment was scrubbed... URL: From arnaud.spiwack at tweag.io Wed Jan 15 05:58:14 2025 From: arnaud.spiwack at tweag.io (Arnaud Spiwack) Date: Wed, 15 Jan 2025 14:58:14 +0900 Subject: [ghc-steering-committee] #682: Explicit Level Imports, recommendation: accept In-Reply-To: References: <0b6b01fb-d79b-45cf-847b-a6aeb63ee514@well-typed.com> Message-ID: I want to add something. If we accept this (and I think we should), then we should strive to consider this a new beginning for Template Haskell, and what we consider the future of Template Haskell to be. It means that (as much as reasonable) every Template Haskell proposal will now be meant to primarily extend this one. In particular it'll be fine if a new proposal is incompatible with `-XImplictStagePersistence`, but not if it is incompatible with `-XNoImplicitPersistence`. I think that it's what we must be ready to commit to. -------------- next part -------------- An HTML attachment was scrubbed... URL: From moritz.angermann at gmail.com Wed Jan 15 06:11:22 2025 From: moritz.angermann at gmail.com (Moritz Angermann) Date: Wed, 15 Jan 2025 15:11:22 +0900 Subject: [ghc-steering-committee] #682: Explicit Level Imports, recommendation: accept In-Reply-To: References: <0b6b01fb-d79b-45cf-847b-a6aeb63ee514@well-typed.com> Message-ID: This is very easy for me to commit to. On Wed, Jan 15, 2025 at 2:58 PM Arnaud Spiwack wrote: > I want to add something. If we accept this (and I think we should), then > we should strive to consider this a new beginning for Template Haskell, and > what we consider the future of Template Haskell to be. It means that (as > much as reasonable) every Template Haskell proposal will now be meant to > primarily extend this one. In particular it'll be fine if a new proposal is > incompatible with `-XImplictStagePersistence`, but not if it is > incompatible with `-XNoImplicitPersistence`. I think that it's what we must > be ready to commit to. > _______________________________________________ > ghc-steering-committee mailing list > ghc-steering-committee at haskell.org > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee > -------------- next part -------------- An HTML attachment was scrubbed... URL: From malte.ott at maralorn.de Fri Jan 17 17:07:20 2025 From: malte.ott at maralorn.de (Malte Ott) Date: Fri, 17 Jan 2025 18:07:20 +0100 Subject: [ghc-steering-committee] #682: Explicit Level Imports, recommendation: accept In-Reply-To: References: <0b6b01fb-d79b-45cf-847b-a6aeb63ee514@well-typed.com> Message-ID: I am in favor of this proposal. As a side note: I think it is a bit sad that we need to burden the user with these complexities. While I will gladly turn the extension on and will specify the stages; this is one thing more to learn for new users of TemplateHaskell. I would prefer if we could infer the import stages, even though this hurts the "imports can be inferred from the header" rule. I made a small remark for clarification on GitHub. Regarding the open syntax question I feel like the most natural thing would be to put the "splice" next to the qualified. i.e. with QualifiedPost we put it post, and with out we put it pre. I would also be fine with allowing both or with always demanding post. My personal taste is that I would dislike to have only pre, but I mainly want the syntax selection process to be efficient and am fine either way. Best, Malte On 2025-01-10 20:19, Moritz Angermann wrote: > Hi all, > > I'm generally in support of this proposal. As many of you know, I > strongly believe TemplateHaskell is a major wart that Haskell has, for > many > reasons. This proposal tries to address at least one of those: adding > more clarity and explicitness about dependencies. It may help with > cross compilation in that we have a clearer idea of what we exactly > need to load in iserv (alternatives where we implicit link a runnable > for > target evaluation, can rely on dead code elimination for this, but > having this from the start would already be helpful). > > I've recently been looking a lot at Zig's comptime, as they seem to > have gone down almost the same route. Maybe there's some inspiration to > be drawn from Zig's solution in the future. It is, however, WAY more > restrictive than what we currently have in the form of TemplateHaskell. > > +1 on this one. > > Best, > Moritz > > On Fri, 10 Jan 2025 at 18:19, Adam Gundry <[1]adam at well-typed.com> > wrote: > > Thanks Arnaud! With my "proposal co-author" hat on, I'd like to make > a > few points inline... > > On 09/01/2025 06:34, Arnaud Spiwack wrote: > > > > On Thu, 9 Jan 2025 at 15:31, Arnaud Spiwack > <[2]arnaud.spiwack at tweag.io > > > wrote: > > > > [...] > > > > They introduce a new extension-XNoImplicitStagePersistence > which > > disables that, and a little bit of syntax to specify the stage > of > > imports. That's it. > > > > But it comes with severe limitations, most importantly: you > can't > > ever use a symbol defined in the current module in a quote or > splice > > of this current module, typed template Haskell is turned off. > > Regarding typed TH, the proposal currently grants a bit of > flexibility > to the implementation in suggesting that TTH might not be supported > at > all, primarily because TTH has some existing unresolved issues > around > constraints. We could alternately say that TTH remains available > (but > also remains somewhat broken, because fixing it is out of scope of > the > implementation of this proposal). > > > For these situations, the proposal kind of advertises using > > `-XImplicitStagePersistence`. Which does seem like a fork-like > > situation to me. Not cool. > > Rather than seeing ImplicitStagePersistence as creating a language > fork, > I see it as necessary for backwards compatibility, but with the > intention that in the long term NoImplicitStagePersistence is the > way to > go. This may still be difficult in some cases (e.g. codebases that > make > heavy use of Lift), but the idea is to start with a simple, > restrictive > baseline (NoImplicitStagePersistence) and then gradually add > features > relaxing this as needed (ExplicitLevelImports being the first of > these, > but perhaps later something for multiple levels within a single > file). > > Cheers, > > Adam > > -- > Adam Gundry, Haskell Consultant > Well-Typed LLP, [4]https://www.well-typed.com/ > > Registered in England & Wales, OC335890 > 27 Old Gloucester Street, London WC1N 3AX, England > > _______________________________________________ > ghc-steering-committee mailing list > [5]ghc-steering-committee at haskell.org > [6]https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-co > mmittee > > References > > 1. mailto:adam at well-typed.com > 2. mailto:arnaud.spiwack at tweag.io > 3. mailto:arnaud.spiwack at tweag.io > 4. https://www.well-typed.com/ > 5. mailto:ghc-steering-committee at haskell.org > 6. https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee > _______________________________________________ > ghc-steering-committee mailing list > ghc-steering-committee at haskell.org > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee From erikd at mega-nerd.com Sat Jan 18 10:14:50 2025 From: erikd at mega-nerd.com (Erik de Castro Lopo) Date: Sat, 18 Jan 2025 21:14:50 +1100 Subject: [ghc-steering-committee] #682: Explicit Level Imports, recommendation: accept In-Reply-To: References: <0b6b01fb-d79b-45cf-847b-a6aeb63ee514@well-typed.com> Message-ID: <20250118211450.ed38d89badfe51e7c09bf11a@mega-nerd.com> Like Moritz, I am not a huge fan of TH, but do recognize its usefulness. Any improvement to TH that impriove its clarity has my support. +1 Cheers, Erik Moritz Angermann wrote: > Hi all, > > I'm generally in support of this proposal. As many of you know, I strongly > believe TemplateHaskell is a major wart that Haskell has, for many > reasons. This proposal tries to address at least one of those: adding more > clarity and explicitness about dependencies. It may help with > cross compilation in that we have a clearer idea of what we exactly need to > load in iserv (alternatives where we implicit link a runnable for > target evaluation, can rely on dead code elimination for this, but having > this from the start would already be helpful). > > I've recently been looking a lot at Zig's comptime, as they seem to have > gone down almost the same route. Maybe there's some inspiration to > be drawn from Zig's solution in the future. It is, however, WAY more > restrictive than what we currently have in the form of TemplateHaskell. > > +1 on this one. > > Best, > Moritz > > On Fri, 10 Jan 2025 at 18:19, Adam Gundry wrote: > > > Thanks Arnaud! With my "proposal co-author" hat on, I'd like to make a > > few points inline... > > > > > > On 09/01/2025 06:34, Arnaud Spiwack wrote: > > > > > > On Thu, 9 Jan 2025 at 15:31, Arnaud Spiwack > > > wrote: > > > > > > [...] > > > > > > They introduce a new extension-XNoImplicitStagePersistence which > > > disables that, and a little bit of syntax to specify the stage of > > > imports. That's it. > > > > > > But it comes with severe limitations, most importantly: you can't > > > ever use a symbol defined in the current module in a quote or splice > > > of this current module, typed template Haskell is turned off. > > > > Regarding typed TH, the proposal currently grants a bit of flexibility > > to the implementation in suggesting that TTH might not be supported at > > all, primarily because TTH has some existing unresolved issues around > > constraints. We could alternately say that TTH remains available (but > > also remains somewhat broken, because fixing it is out of scope of the > > implementation of this proposal). > > > > > > > For these situations, the proposal kind of advertises using > > > `-XImplicitStagePersistence`. Which does seem like a fork-like > > > situation to me. Not cool. > > > > Rather than seeing ImplicitStagePersistence as creating a language fork, > > I see it as necessary for backwards compatibility, but with the > > intention that in the long term NoImplicitStagePersistence is the way to > > go. This may still be difficult in some cases (e.g. codebases that make > > heavy use of Lift), but the idea is to start with a simple, restrictive > > baseline (NoImplicitStagePersistence) and then gradually add features > > relaxing this as needed (ExplicitLevelImports being the first of these, > > but perhaps later something for multiple levels within a single file). > > > > Cheers, > > > > Adam > > > > > > -- > > Adam Gundry, Haskell Consultant > > Well-Typed LLP, https://www.well-typed.com/ > > > > Registered in England & Wales, OC335890 > > 27 Old Gloucester Street, London WC1N 3AX, England > > > > _______________________________________________ > > ghc-steering-committee mailing list > > ghc-steering-committee at haskell.org > > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee > > -- ---------------------------------------------------------------------- Erik de Castro Lopo http://www.mega-nerd.com/ From sgraf1337 at gmail.com Mon Jan 20 09:22:07 2025 From: sgraf1337 at gmail.com (Sebastian Graf) Date: Mon, 20 Jan 2025 10:22:07 +0100 Subject: [ghc-steering-committee] #621: Linear constraints, recommendation: accept In-Reply-To: References: Message-ID: I vote to return the proposal for revision. I listed my feedback in the thread , but the gist is: While I am sympathetic to the goal of introducing linearity annotations to > constraints, simply because it is a logical extension of -XLinearTypes, I > am afraid I do not feel motivated after having considered the examples in > the proposal. > In fact, I think the examples overpromise on the utility of linear > constraints and the problems it solves have simpler, more direct solutions. Cheers, Sebastian Am Di., 14. Jan. 2025 um 23:45 Uhr schrieb Jakob Brünker < jakob.bruenker at gmail.com>: > Dear committee, > > Arnaud Spiwack and Jack Hughes propose to introduce linear constraints. > > These work analogously to linear functions - as can be seen with the new > syntax, which is %1 =>, reflecting the existing %1 ->. The motivation is > that these constraints make it possible to design linearly typed APIs that > are more convenient to use: Without the linear constraints, tokens would > have to be passed manually into each function in these cases. > > The proposal also introduces dupable classes, which can be used multiple > times even when they appear in a linear context, but cannot be passed to an > unrestricted function. This is necessary to make some API designs work, see > the proposal for details. > > > To me, it seems that this proposal or something like it is necessary to > unlock the full potential of linear types. The proposal lays out why > monadic API designs don't provide the same benefits, and while there are > potential future GHC developments that could make using it even more > convenient (existential types, strict let improvements; see proposal), I > believe it would already be sufficiently useful with today's GHC to be a > valuable addition. Thus, I recommend acceptance. > > Please read through the proposal and voice your opinions. > > Best, > Jakob > _______________________________________________ > ghc-steering-committee mailing list > ghc-steering-committee at haskell.org > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee > -------------- next part -------------- An HTML attachment was scrubbed... URL: From marlowsd at gmail.com Mon Jan 20 13:19:47 2025 From: marlowsd at gmail.com (Simon Marlow) Date: Mon, 20 Jan 2025 13:19:47 +0000 Subject: [ghc-steering-committee] #682: Explicit Level Imports, recommendation: accept In-Reply-To: References: Message-ID: Seems reasonable and the impact seems minimal in practice (I like the pandoc example). In fact in our Buck2 build system at Meta we already have a similar distinction between compile-time and runtime dependencies but it doesn't have the corresponding language support, so getting the build system settings wrong can lead to weird compile errors - well, compile-time link errors typically. +1 Simon On Thu, 9 Jan 2025 at 06:31, Arnaud Spiwack wrote: > > Mathew Pickering, Rodrigo Mesquita, and our own Adam Gundry put forward a > new proposal for the perenial problem of dependencies and Template Haskell > https://github.com/ghc-proposals/ghc-proposals/pull/682 > > I've got to be honest, I'm not fully convinced by the proposal. More on > that in a minute, but it learns a lesson from previous attempts at the same > problem by solving the absolute minimal problem, but this leads to a > somewhat fork-like situation for which it isn't clear whether it will be > resolved in the future. That being said, it solves a real problem which has > plagued GHC compilation forever. And I'm inclined to believe that we can't > really do much better. > > But I'm getting ahead of myself. The problem is that when you have > -XTemplateHaskell in a file, all the dependencies' compiled code must > suddenly be available for typechecking. This breaks `-fno-code` and wounds > recompilation avoidance. This is probably the main reason why it's a widely > held belief that Template Haskell is slow: you use Template Haskell in a > few modules, and suddenly your IDE is much less responsive and you > recompile more files. Yay? > > Anyway, the general gist of the solution is clear: we must be able to > specify that we don't want to import a module for Template Haskell (there > is subtleties in this too as you will want a little more control than that > for cross-compilation reasons which I'm not competent about to comment on). > But the devil is in the many details. There's this thing called implicit > cross-stage persistence which says that anything you import > not-for-template-haskell is going to be available in quotes and splices > anyway. Sigh… So you have to turn this off. This is what the proposal does. > And pretty much only. > > They introduce a new extension-XNoImplicitStagePersistence which disables > that, and a little bit of syntax to specify the stage of imports. That's it. > > But it comes with severe limitations, most importantly: you can't ever use > a symbol defined in the current module in a quote or splice of this current > module, typed template Haskell is turned off. > > For these situations, the proposal kind of advertises using > `-XImplicitStagePersistence`. Which does seem like a fork-like situation to > me. Not cool. Yet… yet Template Haskell is a big messy ball of yarn, and I > don't think it's fair to ask of any proposal to entangle it completely. The > failure of past attempts seem to support this case. And I believe the > authors are correct when they claim that this proposal, in practice, covers > a vast majority of the uses of Template Haskell out there. So maybe we can > see that as a new foundation for Template Haskell. I'm not thrilled about > it, but it's probably the most reasonable way forward. > > The real problem with this sort of proposal is that then I get to write > way too long an email to the committee. Hopefully this didn't deter you. > Read the proposal, and let's vote. > > -- > Arnaud Spiwack > Director, Research at https://moduscreate.com and https://tweag.io. > _______________________________________________ > ghc-steering-committee mailing list > ghc-steering-committee at haskell.org > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee > -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.peytonjones at gmail.com Mon Jan 20 17:42:55 2025 From: simon.peytonjones at gmail.com (Simon Peyton Jones) Date: Mon, 20 Jan 2025 17:42:55 +0000 Subject: [ghc-steering-committee] #682: Explicit Level Imports, recommendation: accept In-Reply-To: References: Message-ID: Arnaud I have responded with a lot of feedback on the Github thread . TL:DR: I like the direction of travel but have too many questions of detail to be ready to accept it just yet. I have arranged a call with Matthew. Simon On Thu, 9 Jan 2025 at 06:31, Arnaud Spiwack wrote: > > Mathew Pickering, Rodrigo Mesquita, and our own Adam Gundry put forward a > new proposal for the perenial problem of dependencies and Template Haskell > https://github.com/ghc-proposals/ghc-proposals/pull/682 > > I've got to be honest, I'm not fully convinced by the proposal. More on > that in a minute, but it learns a lesson from previous attempts at the same > problem by solving the absolute minimal problem, but this leads to a > somewhat fork-like situation for which it isn't clear whether it will be > resolved in the future. That being said, it solves a real problem which has > plagued GHC compilation forever. And I'm inclined to believe that we can't > really do much better. > > But I'm getting ahead of myself. The problem is that when you have > -XTemplateHaskell in a file, all the dependencies' compiled code must > suddenly be available for typechecking. This breaks `-fno-code` and wounds > recompilation avoidance. This is probably the main reason why it's a widely > held belief that Template Haskell is slow: you use Template Haskell in a > few modules, and suddenly your IDE is much less responsive and you > recompile more files. Yay? > > Anyway, the general gist of the solution is clear: we must be able to > specify that we don't want to import a module for Template Haskell (there > is subtleties in this too as you will want a little more control than that > for cross-compilation reasons which I'm not competent about to comment on). > But the devil is in the many details. There's this thing called implicit > cross-stage persistence which says that anything you import > not-for-template-haskell is going to be available in quotes and splices > anyway. Sigh… So you have to turn this off. This is what the proposal does. > And pretty much only. > > They introduce a new extension-XNoImplicitStagePersistence which disables > that, and a little bit of syntax to specify the stage of imports. That's it. > > But it comes with severe limitations, most importantly: you can't ever use > a symbol defined in the current module in a quote or splice of this current > module, typed template Haskell is turned off. > > For these situations, the proposal kind of advertises using > `-XImplicitStagePersistence`. Which does seem like a fork-like situation to > me. Not cool. Yet… yet Template Haskell is a big messy ball of yarn, and I > don't think it's fair to ask of any proposal to entangle it completely. The > failure of past attempts seem to support this case. And I believe the > authors are correct when they claim that this proposal, in practice, covers > a vast majority of the uses of Template Haskell out there. So maybe we can > see that as a new foundation for Template Haskell. I'm not thrilled about > it, but it's probably the most reasonable way forward. > > The real problem with this sort of proposal is that then I get to write > way too long an email to the committee. Hopefully this didn't deter you. > Read the proposal, and let's vote. > > -- > Arnaud Spiwack > Director, Research at https://moduscreate.com and https://tweag.io. > _______________________________________________ > ghc-steering-committee mailing list > ghc-steering-committee at haskell.org > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee > -------------- next part -------------- An HTML attachment was scrubbed... URL: