From adam at well-typed.com Mon Feb 3 20:45:10 2025 From: adam at well-typed.com (Adam Gundry) Date: Mon, 3 Feb 2025 20:45:10 +0000 Subject: [ghc-steering-committee] #682: Explicit Level Imports, recommendation: accept In-Reply-To: References: Message-ID: I'm (unsurprisingly) in favour of acceptance, and I vote for two extensions. As I commented on the GitHub thread: > We shouldn't unnecessarily conflate a syntactic extension (ExplicitLevelImports) with a semantic one (NoImplicitStagePersistence) just because the common case is to want both and we want to keep the number of extensions lower. If there are reasons why having two extensions is actually problematic, I'd like to hear them. Also, at the risk of opening another avenue of discussion, we also need to resolve the syntax question (see https://github.com/ghc-proposals/ghc-proposals/pull/682#discussion_r1849123243). I don't have a very strong opinion here, but given that some people do, perhaps we should make ImportQualifiedPost affect splice imports so we have import splice qualified A -- By default import A splice qualified -- Under ImportQualifiedPost In any case, please do vote! It would be good to get this proposal done. Cheers, Adam On 27/01/2025 11:52, Simon Peyton Jones wrote: > Arnaud > > OK, following my call and some further iteration, the proposal is much > improved. See here > .   Please read > the new "Proposed Change Specification" which has had a large rewrite. > >  I vote to accept. > > BUT there is one point that the committee must resolve: *one extension > of two?*  It's just a judgement call and I lay out the choices in this > post > .    I doubt that we'll get much community feedback.  I suggest that we just vote.  I vote for one, not two.  As does Sebastian. > > Over to you Arnaud.  Let's get this one done. Matthew is busy > implementing it for a customer and it has been on our to-do list for > some time now.  (Partly my fault.) > > Simon > > On Tue, 21 Jan 2025 at 10:48, Simon Peyton Jones > > wrote: > > Matthew and I had a good conversation. Some notes here > . > > He's going to work on a revision to the proposal which I'll iterate > with him. > > Simon > > On Tue, 21 Jan 2025 at 07:37, Arnaud Spiwack > > wrote: > > Then, let's wait until your call with Matthew and decide how to > act then. > > On Tue, 21 Jan 2025 at 02:43, Simon Peyton Jones > > wrote: > > 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 > . -- 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 simon.peytonjones at gmail.com Mon Feb 3 22:13:04 2025 From: simon.peytonjones at gmail.com (Simon Peyton Jones) Date: Mon, 3 Feb 2025 22:13:04 +0000 Subject: [ghc-steering-committee] #682: Explicit Level Imports, recommendation: accept In-Reply-To: References: Message-ID: Yes: all members of the steering committee, please vote. Evaluating proposals is what we all signed up to do! Thanks Simon On Mon, 3 Feb 2025 at 20:45, Adam Gundry wrote: > I'm (unsurprisingly) in favour of acceptance, and I vote for two > extensions. As I commented on the GitHub thread: > > > We shouldn't unnecessarily conflate a syntactic extension > (ExplicitLevelImports) with a semantic one (NoImplicitStagePersistence) > just because the common case is to want both and we want to keep the > number of extensions lower. > > If there are reasons why having two extensions is actually problematic, > I'd like to hear them. > > Also, at the risk of opening another avenue of discussion, we also need > to resolve the syntax question (see > > https://github.com/ghc-proposals/ghc-proposals/pull/682#discussion_r1849123243). > > I don't have a very strong opinion here, but given that some people do, > perhaps we should make ImportQualifiedPost affect splice imports so we have > > import splice qualified A -- By default > import A splice qualified -- Under ImportQualifiedPost > > In any case, please do vote! It would be good to get this proposal done. > > Cheers, > > Adam > > > > On 27/01/2025 11:52, Simon Peyton Jones wrote: > > Arnaud > > > > OK, following my call and some further iteration, the proposal is much > > improved. See here > > . Please > read > > the new "Proposed Change Specification" which has had a large rewrite. > > > > I vote to accept. > > > > BUT there is one point that the committee must resolve: *one extension > > of two?* It's just a judgement call and I lay out the choices in this > > post > > < > https://github.com/ghc-proposals/ghc-proposals/pull/682#issuecomment-2609199731>. > I doubt that we'll get much community feedback. I suggest that we just > vote. I vote for one, not two. As does Sebastian. > > > > Over to you Arnaud. Let's get this one done. Matthew is busy > > implementing it for a customer and it has been on our to-do list for > > some time now. (Partly my fault.) > > > > Simon > > > > On Tue, 21 Jan 2025 at 10:48, Simon Peyton Jones > > > > wrote: > > > > Matthew and I had a good conversation. Some notes here > > < > https://docs.google.com/document/d/1dEMPIHpbN19xYZymGCxO0BpQR58RPhk5MslruY7yXD0/edit?usp=sharing > >. > > > > He's going to work on a revision to the proposal which I'll iterate > > with him. > > > > Simon > > > > On Tue, 21 Jan 2025 at 07:37, Arnaud Spiwack > > > wrote: > > > > Then, let's wait until your call with Matthew and decide how to > > act then. > > > > On Tue, 21 Jan 2025 at 02:43, Simon Peyton Jones > > > > wrote: > > > > Arnaud > > > > I have responded with a lot of feedback on the Github thread > > < > https://github.com/ghc-proposals/ghc-proposals/pull/682#pullrequestreview-2562175116 > >. > > > > 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 > > . > > > -- > 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 arnaud.spiwack at tweag.io Wed Feb 5 06:20:32 2025 From: arnaud.spiwack at tweag.io (Arnaud Spiwack) Date: Wed, 5 Feb 2025 15:20:32 +0900 Subject: [ghc-steering-committee] #682: Explicit Level Imports, recommendation: accept In-Reply-To: References: Message-ID: Sorry I disappeared for a while. I second Simon's call, let's vote. Let me repost a link to Simon's pro and cons post https://github.com/ghc-proposals/ghc-proposals/pull/682#issuecomment-2609199731 So far, we have the following votes - Simon: 1 extension - Adam: 2 extension (feels quite strongly about it) - Sebastian: 1 extension (on the Github thread, but I'll count it as a vote anyway) Eric, Moritz, Malta, Matthías, Erik, Jakob: what do you think? --- Beyond that we have a single piece of community feedback on the Github thread. It's from Michael Peyton Jones who is in favour of 2 extensions, find it here https://github.com/ghc-proposals/ghc-proposals/pull/682#issuecomment-2609583126 --- For the record, I hadn't commented about it in my recommendation, despite my well-known and desperately public distaste for micro extensions. I have a couple of reasons: - I dislike micro-extensions less now that we are doing the GHC20XX (the last one was very modest, I'm in favour, by the way, of doing a much more ambitious language edition soon, otherwise my distaste will come back with a vengeance) - While I consider every proposal with several extensions in it with suspicion, the authors did argue for their second extension, I found the argument mildly convincing, and thought it wasn't worth fighting against. Now, even like this my preference is mildly for one extension. Adam says that it's easier to implement warnings with both the new syntax on and implicit stage persistence left turned on, than to implement errors when implicit stage persistence is turned off. It may be so, but I don't think we can avoid implementing the errors anyway, so I don't feel that it's a particularly compelling argument. I don't feel strongly. But that's presumably where my vote goes. On Tue, 4 Feb 2025 at 07:13, Simon Peyton Jones wrote: > Yes: all members of the steering committee, please vote. Evaluating > proposals is what we all signed up to do! > > Thanks > > Simon > > On Mon, 3 Feb 2025 at 20:45, Adam Gundry wrote: > >> I'm (unsurprisingly) in favour of acceptance, and I vote for two >> extensions. As I commented on the GitHub thread: >> >> > We shouldn't unnecessarily conflate a syntactic extension >> (ExplicitLevelImports) with a semantic one (NoImplicitStagePersistence) >> just because the common case is to want both and we want to keep the >> number of extensions lower. >> >> If there are reasons why having two extensions is actually problematic, >> I'd like to hear them. >> >> Also, at the risk of opening another avenue of discussion, we also need >> to resolve the syntax question (see >> >> https://github.com/ghc-proposals/ghc-proposals/pull/682#discussion_r1849123243). >> >> I don't have a very strong opinion here, but given that some people do, >> perhaps we should make ImportQualifiedPost affect splice imports so we >> have >> >> import splice qualified A -- By default >> import A splice qualified -- Under ImportQualifiedPost >> >> In any case, please do vote! It would be good to get this proposal done. >> >> Cheers, >> >> Adam >> >> >> >> On 27/01/2025 11:52, Simon Peyton Jones wrote: >> > Arnaud >> > >> > OK, following my call and some further iteration, the proposal is much >> > improved. See here >> > . Please >> read >> > the new "Proposed Change Specification" which has had a large rewrite. >> > >> > I vote to accept. >> > >> > BUT there is one point that the committee must resolve: *one extension >> > of two?* It's just a judgement call and I lay out the choices in this >> > post >> > < >> https://github.com/ghc-proposals/ghc-proposals/pull/682#issuecomment-2609199731>. >> I doubt that we'll get much community feedback. I suggest that we just >> vote. I vote for one, not two. As does Sebastian. >> > >> > Over to you Arnaud. Let's get this one done. Matthew is busy >> > implementing it for a customer and it has been on our to-do list for >> > some time now. (Partly my fault.) >> > >> > Simon >> > >> > On Tue, 21 Jan 2025 at 10:48, Simon Peyton Jones >> > > >> wrote: >> > >> > Matthew and I had a good conversation. Some notes here >> > < >> https://docs.google.com/document/d/1dEMPIHpbN19xYZymGCxO0BpQR58RPhk5MslruY7yXD0/edit?usp=sharing >> >. >> > >> > He's going to work on a revision to the proposal which I'll iterate >> > with him. >> > >> > Simon >> > >> > On Tue, 21 Jan 2025 at 07:37, Arnaud Spiwack >> > > wrote: >> > >> > Then, let's wait until your call with Matthew and decide how to >> > act then. >> > >> > On Tue, 21 Jan 2025 at 02:43, Simon Peyton Jones >> > > > > wrote: >> > >> > Arnaud >> > >> > I have responded with a lot of feedback on the Github thread >> > < >> https://github.com/ghc-proposals/ghc-proposals/pull/682#pullrequestreview-2562175116 >> >. >> > >> > 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 >> > < >> 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 >> > . >> >> >> -- >> 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 > -- Arnaud Spiwack Director, Research at https://moduscreate.com and https://tweag.io. -------------- next part -------------- An HTML attachment was scrubbed... URL: From erikd at mega-nerd.com Wed Feb 5 08:16:43 2025 From: erikd at mega-nerd.com (Erik de Castro Lopo) Date: Wed, 5 Feb 2025 19:16:43 +1100 Subject: [ghc-steering-committee] #682: Explicit Level Imports, recommendation: accept In-Reply-To: References: Message-ID: <20250205191643.60ec5f23d8b4571b8cf14ece@mega-nerd.com> Hi, I have read through the proposal, but there is something I am still unsure of. For the LANGUAGE pragma's is there any utility in using one separately form the other? It seems there isn't. In any one file you would use either one or the other. Thanks, Erik Arnaud Spiwack wrote: > Sorry I disappeared for a while. I second Simon's call, let's vote. Let me > repost a link to Simon's pro and cons post > https://github.com/ghc-proposals/ghc-proposals/pull/682#issuecomment-2609199731 > > So far, we have the following votes > > - Simon: 1 extension > - Adam: 2 extension (feels quite strongly about it) > - Sebastian: 1 extension (on the Github thread, but I'll count it as a vote > anyway) > > Eric, Moritz, Malta, Matthías, Erik, Jakob: what do you think? > > --- > > Beyond that we have a single piece of community feedback on the Github > thread. It's from Michael Peyton Jones who is in favour of 2 extensions, > find it here > https://github.com/ghc-proposals/ghc-proposals/pull/682#issuecomment-2609583126 > > --- > > For the record, I hadn't commented about it in my recommendation, despite > my well-known and desperately public distaste for micro extensions. I have > a couple of reasons: > - I dislike micro-extensions less now that we are doing the GHC20XX (the > last one was very modest, I'm in favour, by the way, of doing a much more > ambitious language edition soon, otherwise my distaste will come back with > a vengeance) > - While I consider every proposal with several extensions in it with > suspicion, the authors did argue for their second extension, I found the > argument mildly convincing, and thought it wasn't worth fighting against. > > Now, even like this my preference is mildly for one extension. Adam says > that it's easier to implement warnings with both the new syntax on and > implicit stage persistence left turned on, than to implement errors when > implicit stage persistence is turned off. It may be so, but I don't think > we can avoid implementing the errors anyway, so I don't feel that it's a > particularly compelling argument. I don't feel strongly. But that's > presumably where my vote goes. > > On Tue, 4 Feb 2025 at 07:13, Simon Peyton Jones > wrote: > > > Yes: all members of the steering committee, please vote. Evaluating > > proposals is what we all signed up to do! > > > > Thanks > > > > Simon > > > > On Mon, 3 Feb 2025 at 20:45, Adam Gundry wrote: > > > >> I'm (unsurprisingly) in favour of acceptance, and I vote for two > >> extensions. As I commented on the GitHub thread: > >> > >> > We shouldn't unnecessarily conflate a syntactic extension > >> (ExplicitLevelImports) with a semantic one (NoImplicitStagePersistence) > >> just because the common case is to want both and we want to keep the > >> number of extensions lower. > >> > >> If there are reasons why having two extensions is actually problematic, > >> I'd like to hear them. > >> > >> Also, at the risk of opening another avenue of discussion, we also need > >> to resolve the syntax question (see > >> > >> https://github.com/ghc-proposals/ghc-proposals/pull/682#discussion_r1849123243). > >> > >> I don't have a very strong opinion here, but given that some people do, > >> perhaps we should make ImportQualifiedPost affect splice imports so we > >> have > >> > >> import splice qualified A -- By default > >> import A splice qualified -- Under ImportQualifiedPost > >> > >> In any case, please do vote! It would be good to get this proposal done. > >> > >> Cheers, > >> > >> Adam > >> > >> > >> > >> On 27/01/2025 11:52, Simon Peyton Jones wrote: > >> > Arnaud > >> > > >> > OK, following my call and some further iteration, the proposal is much > >> > improved. See here > >> > . Please > >> read > >> > the new "Proposed Change Specification" which has had a large rewrite. > >> > > >> > I vote to accept. > >> > > >> > BUT there is one point that the committee must resolve: *one extension > >> > of two?* It's just a judgement call and I lay out the choices in this > >> > post > >> > < > >> https://github.com/ghc-proposals/ghc-proposals/pull/682#issuecomment-2609199731>. > >> I doubt that we'll get much community feedback. I suggest that we just > >> vote. I vote for one, not two. As does Sebastian. > >> > > >> > Over to you Arnaud. Let's get this one done. Matthew is busy > >> > implementing it for a customer and it has been on our to-do list for > >> > some time now. (Partly my fault.) > >> > > >> > Simon > >> > > >> > On Tue, 21 Jan 2025 at 10:48, Simon Peyton Jones > >> > > > >> wrote: > >> > > >> > Matthew and I had a good conversation. Some notes here > >> > < > >> https://docs.google.com/document/d/1dEMPIHpbN19xYZymGCxO0BpQR58RPhk5MslruY7yXD0/edit?usp=sharing > >> >. > >> > > >> > He's going to work on a revision to the proposal which I'll iterate > >> > with him. > >> > > >> > Simon > >> > > >> > On Tue, 21 Jan 2025 at 07:37, Arnaud Spiwack > >> > > wrote: > >> > > >> > Then, let's wait until your call with Matthew and decide how to > >> > act then. > >> > > >> > On Tue, 21 Jan 2025 at 02:43, Simon Peyton Jones > >> > >> > > wrote: > >> > > >> > Arnaud > >> > > >> > I have responded with a lot of feedback on the Github thread > >> > < > >> https://github.com/ghc-proposals/ghc-proposals/pull/682#pullrequestreview-2562175116 > >> >. > >> > > >> > 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 > >> > < > >> 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 > >> > . > >> > >> > >> -- > >> 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 > > > > > -- > Arnaud Spiwack > Director, Research at https://moduscreate.com and https://tweag.io. -- ---------------------------------------------------------------------- Erik de Castro Lopo http://www.mega-nerd.com/ From marlowsd at gmail.com Wed Feb 5 15:37:11 2025 From: marlowsd at gmail.com (Simon Marlow) Date: Wed, 5 Feb 2025 15:37:11 +0000 Subject: [ghc-steering-committee] #682: Explicit Level Imports, recommendation: accept In-Reply-To: <20250205191643.60ec5f23d8b4571b8cf14ece@mega-nerd.com> References: <20250205191643.60ec5f23d8b4571b8cf14ece@mega-nerd.com> Message-ID: I don't feel strongly about 1 vs 2 extensions, because I think the direction of travel is away from recommending individual extensions as a way to interact with the compiler and towards GHC20xx instead. And in GHC20xx I think we would enable either both or neither of these extensions, correct? Cheers Simon On Wed, 5 Feb 2025 at 08:16, Erik de Castro Lopo wrote: > Hi, > > I have read through the proposal, but there is something I am still unsure > of. For the LANGUAGE pragma's is there any utility in using one separately > form the other? It seems there isn't. In any one file you would use either > one or the other. > > Thanks, > Erik > > Arnaud Spiwack wrote: > > > Sorry I disappeared for a while. I second Simon's call, let's vote. Let > me > > repost a link to Simon's pro and cons post > > > https://github.com/ghc-proposals/ghc-proposals/pull/682#issuecomment-2609199731 > > > > So far, we have the following votes > > > > - Simon: 1 extension > > - Adam: 2 extension (feels quite strongly about it) > > - Sebastian: 1 extension (on the Github thread, but I'll count it as a > vote > > anyway) > > > > Eric, Moritz, Malta, Matthías, Erik, Jakob: what do you think? > > > > --- > > > > Beyond that we have a single piece of community feedback on the Github > > thread. It's from Michael Peyton Jones who is in favour of 2 extensions, > > find it here > > > https://github.com/ghc-proposals/ghc-proposals/pull/682#issuecomment-2609583126 > > > > --- > > > > For the record, I hadn't commented about it in my recommendation, despite > > my well-known and desperately public distaste for micro extensions. I > have > > a couple of reasons: > > - I dislike micro-extensions less now that we are doing the GHC20XX (the > > last one was very modest, I'm in favour, by the way, of doing a much more > > ambitious language edition soon, otherwise my distaste will come back > with > > a vengeance) > > - While I consider every proposal with several extensions in it with > > suspicion, the authors did argue for their second extension, I found the > > argument mildly convincing, and thought it wasn't worth fighting against. > > > > Now, even like this my preference is mildly for one extension. Adam says > > that it's easier to implement warnings with both the new syntax on and > > implicit stage persistence left turned on, than to implement errors when > > implicit stage persistence is turned off. It may be so, but I don't think > > we can avoid implementing the errors anyway, so I don't feel that it's a > > particularly compelling argument. I don't feel strongly. But that's > > presumably where my vote goes. > > > > On Tue, 4 Feb 2025 at 07:13, Simon Peyton Jones < > simon.peytonjones at gmail.com> > > wrote: > > > > > Yes: all members of the steering committee, please vote. Evaluating > > > proposals is what we all signed up to do! > > > > > > Thanks > > > > > > Simon > > > > > > On Mon, 3 Feb 2025 at 20:45, Adam Gundry wrote: > > > > > >> I'm (unsurprisingly) in favour of acceptance, and I vote for two > > >> extensions. As I commented on the GitHub thread: > > >> > > >> > We shouldn't unnecessarily conflate a syntactic extension > > >> (ExplicitLevelImports) with a semantic one > (NoImplicitStagePersistence) > > >> just because the common case is to want both and we want to keep the > > >> number of extensions lower. > > >> > > >> If there are reasons why having two extensions is actually > problematic, > > >> I'd like to hear them. > > >> > > >> Also, at the risk of opening another avenue of discussion, we also > need > > >> to resolve the syntax question (see > > >> > > >> > https://github.com/ghc-proposals/ghc-proposals/pull/682#discussion_r1849123243 > ). > > >> > > >> I don't have a very strong opinion here, but given that some people > do, > > >> perhaps we should make ImportQualifiedPost affect splice imports so we > > >> have > > >> > > >> import splice qualified A -- By default > > >> import A splice qualified -- Under ImportQualifiedPost > > >> > > >> In any case, please do vote! It would be good to get this proposal > done. > > >> > > >> Cheers, > > >> > > >> Adam > > >> > > >> > > >> > > >> On 27/01/2025 11:52, Simon Peyton Jones wrote: > > >> > Arnaud > > >> > > > >> > OK, following my call and some further iteration, the proposal is > much > > >> > improved. See here > > >> > . Please > > >> read > > >> > the new "Proposed Change Specification" which has had a large > rewrite. > > >> > > > >> > I vote to accept. > > >> > > > >> > BUT there is one point that the committee must resolve: *one > extension > > >> > of two?* It's just a judgement call and I lay out the choices in > this > > >> > post > > >> > < > > >> > https://github.com/ghc-proposals/ghc-proposals/pull/682#issuecomment-2609199731 > >. > > >> I doubt that we'll get much community feedback. I suggest that we > just > > >> vote. I vote for one, not two. As does Sebastian. > > >> > > > >> > Over to you Arnaud. Let's get this one done. Matthew is busy > > >> > implementing it for a customer and it has been on our to-do list for > > >> > some time now. (Partly my fault.) > > >> > > > >> > Simon > > >> > > > >> > On Tue, 21 Jan 2025 at 10:48, Simon Peyton Jones > > >> > > > > >> wrote: > > >> > > > >> > Matthew and I had a good conversation. Some notes here > > >> > < > > >> > https://docs.google.com/document/d/1dEMPIHpbN19xYZymGCxO0BpQR58RPhk5MslruY7yXD0/edit?usp=sharing > > >> >. > > >> > > > >> > He's going to work on a revision to the proposal which I'll > iterate > > >> > with him. > > >> > > > >> > Simon > > >> > > > >> > On Tue, 21 Jan 2025 at 07:37, Arnaud Spiwack > > >> > > > wrote: > > >> > > > >> > Then, let's wait until your call with Matthew and decide > how to > > >> > act then. > > >> > > > >> > On Tue, 21 Jan 2025 at 02:43, Simon Peyton Jones > > >> > > >> > > wrote: > > >> > > > >> > Arnaud > > >> > > > >> > I have responded with a lot of feedback on the Github > thread > > >> > < > > >> > https://github.com/ghc-proposals/ghc-proposals/pull/682#pullrequestreview-2562175116 > > >> >. > > >> > > > >> > 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 > > >> > arnaud.spiwack at tweag.io>> > > >> > 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 > > >> > < > > >> 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 > > >> > . > > >> > > >> > > >> -- > > >> 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 > > > > > > > > > -- > > Arnaud Spiwack > > Director, Research at https://moduscreate.com and https://tweag.io. > > > -- > ---------------------------------------------------------------------- > Erik de Castro Lopo > http://www.mega-nerd.com/ > _______________________________________________ > 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 arnaud.spiwack at tweag.io Thu Feb 6 07:26:17 2025 From: arnaud.spiwack at tweag.io (Arnaud Spiwack) Date: Thu, 6 Feb 2025 16:26:17 +0900 Subject: [ghc-steering-committee] #682: Explicit Level Imports, recommendation: accept In-Reply-To: References: <20250205191643.60ec5f23d8b4571b8cf14ece@mega-nerd.com> Message-ID: Simon M: I'm pretty we would enable either both or neither in editions, yes. --- Erik: See the argument summarized by Simon PJ here https://github.com/ghc-proposals/ghc-proposals/pull/682#issuecomment-2609199731 , and the handful of comment below, these are the arguments which have been laid down so far for either side of this conversation. My summary of the summary is that there are two envisioned use-case for turning on ExplicitLevelImports while leaving ImplicitStagePersistence on: - Migration (this help compile a project, but progressively follow warnings to prepare a project for NoImplicitStagePersistence) - Exceptional ImplicitStagePersistence: in the current state of the library, it seems that you will sometimes need to use ImplicitStagePersistence (to define Lift function, perhaps, or in a module where you define a bunch of Template Haskell: not every problem has been solved). But because you are in a project which uses ExplicitLevelImport everywhere, you may want to still mark your imports consistently with the rest of the project, as being imports for slices, quotes, or neither. On Thu, 6 Feb 2025 at 00:37, Simon Marlow wrote: > I don't feel strongly about 1 vs 2 extensions, because I think the > direction of travel is away from recommending individual extensions as a > way to interact with the compiler and towards GHC20xx instead. And in > GHC20xx I think we would enable either both or neither of these extensions, > correct? > > Cheers > Simon > > On Wed, 5 Feb 2025 at 08:16, Erik de Castro Lopo > wrote: > >> Hi, >> >> I have read through the proposal, but there is something I am still unsure >> of. For the LANGUAGE pragma's is there any utility in using one separately >> form the other? It seems there isn't. In any one file you would use either >> one or the other. >> >> Thanks, >> Erik >> >> Arnaud Spiwack wrote: >> >> > Sorry I disappeared for a while. I second Simon's call, let's vote. Let >> me >> > repost a link to Simon's pro and cons post >> > >> https://github.com/ghc-proposals/ghc-proposals/pull/682#issuecomment-2609199731 >> > >> > So far, we have the following votes >> > >> > - Simon: 1 extension >> > - Adam: 2 extension (feels quite strongly about it) >> > - Sebastian: 1 extension (on the Github thread, but I'll count it as a >> vote >> > anyway) >> > >> > Eric, Moritz, Malta, Matthías, Erik, Jakob: what do you think? >> > >> > --- >> > >> > Beyond that we have a single piece of community feedback on the Github >> > thread. It's from Michael Peyton Jones who is in favour of 2 extensions, >> > find it here >> > >> https://github.com/ghc-proposals/ghc-proposals/pull/682#issuecomment-2609583126 >> > >> > --- >> > >> > For the record, I hadn't commented about it in my recommendation, >> despite >> > my well-known and desperately public distaste for micro extensions. I >> have >> > a couple of reasons: >> > - I dislike micro-extensions less now that we are doing the GHC20XX (the >> > last one was very modest, I'm in favour, by the way, of doing a much >> more >> > ambitious language edition soon, otherwise my distaste will come back >> with >> > a vengeance) >> > - While I consider every proposal with several extensions in it with >> > suspicion, the authors did argue for their second extension, I found the >> > argument mildly convincing, and thought it wasn't worth fighting >> against. >> > >> > Now, even like this my preference is mildly for one extension. Adam says >> > that it's easier to implement warnings with both the new syntax on and >> > implicit stage persistence left turned on, than to implement errors when >> > implicit stage persistence is turned off. It may be so, but I don't >> think >> > we can avoid implementing the errors anyway, so I don't feel that it's a >> > particularly compelling argument. I don't feel strongly. But that's >> > presumably where my vote goes. >> > >> > On Tue, 4 Feb 2025 at 07:13, Simon Peyton Jones < >> simon.peytonjones at gmail.com> >> > wrote: >> > >> > > Yes: all members of the steering committee, please vote. Evaluating >> > > proposals is what we all signed up to do! >> > > >> > > Thanks >> > > >> > > Simon >> > > >> > > On Mon, 3 Feb 2025 at 20:45, Adam Gundry wrote: >> > > >> > >> I'm (unsurprisingly) in favour of acceptance, and I vote for two >> > >> extensions. As I commented on the GitHub thread: >> > >> >> > >> > We shouldn't unnecessarily conflate a syntactic extension >> > >> (ExplicitLevelImports) with a semantic one >> (NoImplicitStagePersistence) >> > >> just because the common case is to want both and we want to keep the >> > >> number of extensions lower. >> > >> >> > >> If there are reasons why having two extensions is actually >> problematic, >> > >> I'd like to hear them. >> > >> >> > >> Also, at the risk of opening another avenue of discussion, we also >> need >> > >> to resolve the syntax question (see >> > >> >> > >> >> https://github.com/ghc-proposals/ghc-proposals/pull/682#discussion_r1849123243 >> ). >> > >> >> > >> I don't have a very strong opinion here, but given that some people >> do, >> > >> perhaps we should make ImportQualifiedPost affect splice imports so >> we >> > >> have >> > >> >> > >> import splice qualified A -- By default >> > >> import A splice qualified -- Under ImportQualifiedPost >> > >> >> > >> In any case, please do vote! It would be good to get this proposal >> done. >> > >> >> > >> Cheers, >> > >> >> > >> Adam >> > >> >> > >> >> > >> >> > >> On 27/01/2025 11:52, Simon Peyton Jones wrote: >> > >> > Arnaud >> > >> > >> > >> > OK, following my call and some further iteration, the proposal is >> much >> > >> > improved. See here >> > >> > . >> Please >> > >> read >> > >> > the new "Proposed Change Specification" which has had a large >> rewrite. >> > >> > >> > >> > I vote to accept. >> > >> > >> > >> > BUT there is one point that the committee must resolve: *one >> extension >> > >> > of two?* It's just a judgement call and I lay out the choices in >> this >> > >> > post >> > >> > < >> > >> >> https://github.com/ghc-proposals/ghc-proposals/pull/682#issuecomment-2609199731 >> >. >> > >> I doubt that we'll get much community feedback. I suggest that we >> just >> > >> vote. I vote for one, not two. As does Sebastian. >> > >> > >> > >> > Over to you Arnaud. Let's get this one done. Matthew is busy >> > >> > implementing it for a customer and it has been on our to-do list >> for >> > >> > some time now. (Partly my fault.) >> > >> > >> > >> > Simon >> > >> > >> > >> > On Tue, 21 Jan 2025 at 10:48, Simon Peyton Jones >> > >> > > >> > >> wrote: >> > >> > >> > >> > Matthew and I had a good conversation. Some notes here >> > >> > < >> > >> >> https://docs.google.com/document/d/1dEMPIHpbN19xYZymGCxO0BpQR58RPhk5MslruY7yXD0/edit?usp=sharing >> > >> >. >> > >> > >> > >> > He's going to work on a revision to the proposal which I'll >> iterate >> > >> > with him. >> > >> > >> > >> > Simon >> > >> > >> > >> > On Tue, 21 Jan 2025 at 07:37, Arnaud Spiwack >> > >> > > >> wrote: >> > >> > >> > >> > Then, let's wait until your call with Matthew and decide >> how to >> > >> > act then. >> > >> > >> > >> > On Tue, 21 Jan 2025 at 02:43, Simon Peyton Jones >> > >> > > > >> > > wrote: >> > >> > >> > >> > Arnaud >> > >> > >> > >> > I have responded with a lot of feedback on the Github >> thread >> > >> > < >> > >> >> https://github.com/ghc-proposals/ghc-proposals/pull/682#pullrequestreview-2562175116 >> > >> >. >> > >> > >> > >> > 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 >> > >> > > arnaud.spiwack at tweag.io>> >> > >> > 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 >> > >> > < >> > >> 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 >> > >> > . >> > >> >> > >> >> > >> -- >> > >> 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 >> > > >> > >> > >> > -- >> > Arnaud Spiwack >> > Director, Research at https://moduscreate.com and https://tweag.io. >> >> >> -- >> ---------------------------------------------------------------------- >> Erik de Castro Lopo >> http://www.mega-nerd.com/ >> _______________________________________________ >> 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 mpg at mpg.is Thu Feb 6 16:57:22 2025 From: mpg at mpg.is (=?UTF-8?Q?Matth=C3=ADas_P=C3=A1ll_Gissurarson?=) Date: Thu, 6 Feb 2025 17:57:22 +0100 Subject: [ghc-steering-committee] #682: Explicit Level Imports, recommendation: accept In-Reply-To: References: <20250205191643.60ec5f23d8b4571b8cf14ece@mega-nerd.com> Message-ID: Sorry for the late reply! After reading the thread, I'm slightly in favor of having 2 extensions. While I agree that we already have too many extensions, the case for having two extensions is convincing. As Arnaud mentioned, extensions are often used in a long list in the .cabal file, and being able to have ExplicitLevelImports enabled during refactoring seems to be a win. We want to keep migration costs minimal. The subtle case of the list of extensions being order-dependent (as Richard mentioned) is a bit troubling, but I agree that that should be left to another proposal. On Thu, 6 Feb 2025 at 08:26, Arnaud Spiwack wrote: > Simon M: I'm pretty we would enable either both or neither in editions, > yes. > > --- > > Erik: See the argument summarized by Simon PJ here > https://github.com/ghc-proposals/ghc-proposals/pull/682#issuecomment-2609199731 > , and the handful of comment below, these are the arguments which have been > laid down so far for either side of this conversation. My summary of the > summary is that there are two envisioned use-case for turning on > ExplicitLevelImports while leaving ImplicitStagePersistence on: > > - Migration (this help compile a project, but progressively follow > warnings to prepare a project for NoImplicitStagePersistence) > - Exceptional ImplicitStagePersistence: in the current state of the > library, it seems that you will sometimes need to use > ImplicitStagePersistence (to define Lift function, perhaps, or in a module > where you define a bunch of Template Haskell: not every problem has been > solved). But because you are in a project which uses ExplicitLevelImport > everywhere, you may want to still mark your imports consistently with the > rest of the project, as being imports for slices, quotes, or neither. > > On Thu, 6 Feb 2025 at 00:37, Simon Marlow wrote: > >> I don't feel strongly about 1 vs 2 extensions, because I think the >> direction of travel is away from recommending individual extensions as a >> way to interact with the compiler and towards GHC20xx instead. And in >> GHC20xx I think we would enable either both or neither of these extensions, >> correct? >> >> Cheers >> Simon >> >> On Wed, 5 Feb 2025 at 08:16, Erik de Castro Lopo >> wrote: >> >>> Hi, >>> >>> I have read through the proposal, but there is something I am still >>> unsure >>> of. For the LANGUAGE pragma's is there any utility in using one >>> separately >>> form the other? It seems there isn't. In any one file you would use >>> either >>> one or the other. >>> >>> Thanks, >>> Erik >>> >>> Arnaud Spiwack wrote: >>> >>> > Sorry I disappeared for a while. I second Simon's call, let's vote. >>> Let me >>> > repost a link to Simon's pro and cons post >>> > >>> https://github.com/ghc-proposals/ghc-proposals/pull/682#issuecomment-2609199731 >>> > >>> > So far, we have the following votes >>> > >>> > - Simon: 1 extension >>> > - Adam: 2 extension (feels quite strongly about it) >>> > - Sebastian: 1 extension (on the Github thread, but I'll count it as a >>> vote >>> > anyway) >>> > >>> > Eric, Moritz, Malta, Matthías, Erik, Jakob: what do you think? >>> > >>> > --- >>> > >>> > Beyond that we have a single piece of community feedback on the Github >>> > thread. It's from Michael Peyton Jones who is in favour of 2 >>> extensions, >>> > find it here >>> > >>> https://github.com/ghc-proposals/ghc-proposals/pull/682#issuecomment-2609583126 >>> > >>> > --- >>> > >>> > For the record, I hadn't commented about it in my recommendation, >>> despite >>> > my well-known and desperately public distaste for micro extensions. I >>> have >>> > a couple of reasons: >>> > - I dislike micro-extensions less now that we are doing the GHC20XX >>> (the >>> > last one was very modest, I'm in favour, by the way, of doing a much >>> more >>> > ambitious language edition soon, otherwise my distaste will come back >>> with >>> > a vengeance) >>> > - While I consider every proposal with several extensions in it with >>> > suspicion, the authors did argue for their second extension, I found >>> the >>> > argument mildly convincing, and thought it wasn't worth fighting >>> against. >>> > >>> > Now, even like this my preference is mildly for one extension. Adam >>> says >>> > that it's easier to implement warnings with both the new syntax on and >>> > implicit stage persistence left turned on, than to implement errors >>> when >>> > implicit stage persistence is turned off. It may be so, but I don't >>> think >>> > we can avoid implementing the errors anyway, so I don't feel that it's >>> a >>> > particularly compelling argument. I don't feel strongly. But that's >>> > presumably where my vote goes. >>> > >>> > On Tue, 4 Feb 2025 at 07:13, Simon Peyton Jones < >>> simon.peytonjones at gmail.com> >>> > wrote: >>> > >>> > > Yes: all members of the steering committee, please vote. Evaluating >>> > > proposals is what we all signed up to do! >>> > > >>> > > Thanks >>> > > >>> > > Simon >>> > > >>> > > On Mon, 3 Feb 2025 at 20:45, Adam Gundry >>> wrote: >>> > > >>> > >> I'm (unsurprisingly) in favour of acceptance, and I vote for two >>> > >> extensions. As I commented on the GitHub thread: >>> > >> >>> > >> > We shouldn't unnecessarily conflate a syntactic extension >>> > >> (ExplicitLevelImports) with a semantic one >>> (NoImplicitStagePersistence) >>> > >> just because the common case is to want both and we want to keep the >>> > >> number of extensions lower. >>> > >> >>> > >> If there are reasons why having two extensions is actually >>> problematic, >>> > >> I'd like to hear them. >>> > >> >>> > >> Also, at the risk of opening another avenue of discussion, we also >>> need >>> > >> to resolve the syntax question (see >>> > >> >>> > >> >>> https://github.com/ghc-proposals/ghc-proposals/pull/682#discussion_r1849123243 >>> ). >>> > >> >>> > >> I don't have a very strong opinion here, but given that some people >>> do, >>> > >> perhaps we should make ImportQualifiedPost affect splice imports so >>> we >>> > >> have >>> > >> >>> > >> import splice qualified A -- By default >>> > >> import A splice qualified -- Under ImportQualifiedPost >>> > >> >>> > >> In any case, please do vote! It would be good to get this proposal >>> done. >>> > >> >>> > >> Cheers, >>> > >> >>> > >> Adam >>> > >> >>> > >> >>> > >> >>> > >> On 27/01/2025 11:52, Simon Peyton Jones wrote: >>> > >> > Arnaud >>> > >> > >>> > >> > OK, following my call and some further iteration, the proposal is >>> much >>> > >> > improved. See here >>> > >> > . >>> Please >>> > >> read >>> > >> > the new "Proposed Change Specification" which has had a large >>> rewrite. >>> > >> > >>> > >> > I vote to accept. >>> > >> > >>> > >> > BUT there is one point that the committee must resolve: *one >>> extension >>> > >> > of two?* It's just a judgement call and I lay out the choices in >>> this >>> > >> > post >>> > >> > < >>> > >> >>> https://github.com/ghc-proposals/ghc-proposals/pull/682#issuecomment-2609199731 >>> >. >>> > >> I doubt that we'll get much community feedback. I suggest that we >>> just >>> > >> vote. I vote for one, not two. As does Sebastian. >>> > >> > >>> > >> > Over to you Arnaud. Let's get this one done. Matthew is busy >>> > >> > implementing it for a customer and it has been on our to-do list >>> for >>> > >> > some time now. (Partly my fault.) >>> > >> > >>> > >> > Simon >>> > >> > >>> > >> > On Tue, 21 Jan 2025 at 10:48, Simon Peyton Jones >>> > >> > >> >> >>> > >> wrote: >>> > >> > >>> > >> > Matthew and I had a good conversation. Some notes here >>> > >> > < >>> > >> >>> https://docs.google.com/document/d/1dEMPIHpbN19xYZymGCxO0BpQR58RPhk5MslruY7yXD0/edit?usp=sharing >>> > >> >. >>> > >> > >>> > >> > He's going to work on a revision to the proposal which I'll >>> iterate >>> > >> > with him. >>> > >> > >>> > >> > Simon >>> > >> > >>> > >> > On Tue, 21 Jan 2025 at 07:37, Arnaud Spiwack >>> > >> > > >>> wrote: >>> > >> > >>> > >> > Then, let's wait until your call with Matthew and decide >>> how to >>> > >> > act then. >>> > >> > >>> > >> > On Tue, 21 Jan 2025 at 02:43, Simon Peyton Jones >>> > >> > >> > >> > > wrote: >>> > >> > >>> > >> > Arnaud >>> > >> > >>> > >> > I have responded with a lot of feedback on the Github >>> thread >>> > >> > < >>> > >> >>> https://github.com/ghc-proposals/ghc-proposals/pull/682#pullrequestreview-2562175116 >>> > >> >. >>> > >> > >>> > >> > 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 >>> > >> > >> arnaud.spiwack at tweag.io>> >>> > >> > 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 >>> > >> > < >>> > >> 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 >>> > >> > . >>> > >> >>> > >> >>> > >> -- >>> > >> 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 >>> > > >>> > >>> > >>> > -- >>> > Arnaud Spiwack >>> > Director, Research at https://moduscreate.com and https://tweag.io. >>> >>> >>> -- >>> ---------------------------------------------------------------------- >>> Erik de Castro Lopo >>> http://www.mega-nerd.com/ >>> _______________________________________________ >>> 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. > _______________________________________________ > 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 malte.ott at maralorn.de Thu Feb 6 19:58:37 2025 From: malte.ott at maralorn.de (Malte Ott) Date: Thu, 6 Feb 2025 20:58:37 +0100 Subject: [ghc-steering-committee] #682: Explicit Level Imports, recommendation: accept In-Reply-To: References: <20250205191643.60ec5f23d8b4571b8cf14ece@mega-nerd.com> Message-ID: I agrre with this. On 2025-02-06 17:57, Matthías Páll Gissurarson wrote: > Sorry for the late reply! > > After reading the thread, I'm slightly in favor of having 2 extensions. > > While I agree that we already have too many extensions, the case for > having two extensions is convincing. As Arnaud mentioned, extensions > are often used in a long list in the .cabal file, and being able to > have ExplicitLevelImports enabled during refactoring seems to be a win. > We want to keep migration costs minimal. > > The subtle case of the list of extensions being order-dependent (as > Richard mentioned) is a bit troubling, but I agree that that should be > left to another proposal. > > On Thu, 6 Feb 2025 at 08:26, Arnaud Spiwack > <[1]arnaud.spiwack at tweag.io> wrote: > > Simon M: I'm pretty we would enable either both or neither in editions, > yes. > > --- > > Erik: See the argument summarized by Simon PJ here > [2]https://github.com/ghc-proposals/ghc-proposals/pull/682#issuecomment > -2609199731 , and the handful of comment below, these are the arguments > which have been laid down so far for either side of this conversation. > My summary of the summary is that there are two envisioned use-case for > turning on ExplicitLevelImports while leaving ImplicitStagePersistence > on: > > - Migration (this help compile a project, but progressively follow > warnings to prepare a project for NoImplicitStagePersistence) > - Exceptional ImplicitStagePersistence: in the current state of the > library, it seems that you will sometimes need to use > ImplicitStagePersistence (to define Lift function, perhaps, or in a > module where you define a bunch of Template Haskell: not every problem > has been solved). But because you are in a project which uses > ExplicitLevelImport everywhere, you may want to still mark your imports > consistently with the rest of the project, as being imports for slices, > quotes, or neither. > > On Thu, 6 Feb 2025 at 00:37, Simon Marlow <[3]marlowsd at gmail.com> > wrote: > > I don't feel strongly about 1 vs 2 extensions, because I think the > direction of travel is away from recommending individual extensions as > a way to interact with the compiler and towards GHC20xx instead. And in > GHC20xx I think we would enable either both or neither of these > extensions, correct? > > Cheers > Simon > > On Wed, 5 Feb 2025 at 08:16, Erik de Castro Lopo > <[4]erikd at mega-nerd.com> wrote: > > Hi, > > I have read through the proposal, but there is something I am still > unsure > of. For the LANGUAGE pragma's is there any utility in using one > separately > form the other? It seems there isn't. In any one file you would use > either > one or the other. > > Thanks, > Erik > > Arnaud Spiwack wrote: > > > Sorry I disappeared for a while. I second Simon's call, let's > vote. Let me > > repost a link to Simon's pro and cons post > > > [5]https://github.com/ghc-proposals/ghc-proposals/pull/682#issuecomm > ent-2609199731 > > > > So far, we have the following votes > > > > - Simon: 1 extension > > - Adam: 2 extension (feels quite strongly about it) > > - Sebastian: 1 extension (on the Github thread, but I'll count it > as a vote > > anyway) > > > > Eric, Moritz, Malta, Matthías, Erik, Jakob: what do you think? > > > > --- > > > > Beyond that we have a single piece of community feedback on the > Github > > thread. It's from Michael Peyton Jones who is in favour of 2 > extensions, > > find it here > > > [6]https://github.com/ghc-proposals/ghc-proposals/pull/682#issuecomm > ent-2609583126 > > > > --- > > > > For the record, I hadn't commented about it in my recommendation, > despite > > my well-known and desperately public distaste for micro > extensions. I have > > a couple of reasons: > > - I dislike micro-extensions less now that we are doing the > GHC20XX (the > > last one was very modest, I'm in favour, by the way, of doing a > much more > > ambitious language edition soon, otherwise my distaste will come > back with > > a vengeance) > > - While I consider every proposal with several extensions in it > with > > suspicion, the authors did argue for their second extension, I > found the > > argument mildly convincing, and thought it wasn't worth fighting > against. > > > > Now, even like this my preference is mildly for one extension. > Adam says > > that it's easier to implement warnings with both the new syntax on > and > > implicit stage persistence left turned on, than to implement > errors when > > implicit stage persistence is turned off. It may be so, but I > don't think > > we can avoid implementing the errors anyway, so I don't feel that > it's a > > particularly compelling argument. I don't feel strongly. But > that's > > presumably where my vote goes. > > > > On Tue, 4 Feb 2025 at 07:13, Simon Peyton Jones > <[7]simon.peytonjones at gmail.com> > > wrote: > > > > > Yes: all members of the steering committee, please vote. > Evaluating > > > proposals is what we all signed up to do! > > > > > > Thanks > > > > > > Simon > > > > > > On Mon, 3 Feb 2025 at 20:45, Adam Gundry > <[8]adam at well-typed.com> wrote: > > > > > >> I'm (unsurprisingly) in favour of acceptance, and I vote for > two > > >> extensions. As I commented on the GitHub thread: > > >> > > >> > We shouldn't unnecessarily conflate a syntactic extension > > >> (ExplicitLevelImports) with a semantic one > (NoImplicitStagePersistence) > > >> just because the common case is to want both and we want to > keep the > > >> number of extensions lower. > > >> > > >> If there are reasons why having two extensions is actually > problematic, > > >> I'd like to hear them. > > >> > > >> Also, at the risk of opening another avenue of discussion, we > also need > > >> to resolve the syntax question (see > > >> > > >> > [9]https://github.com/ghc-proposals/ghc-proposals/pull/682#discussio > n_r1849123243). > > >> > > >> I don't have a very strong opinion here, but given that some > people do, > > >> perhaps we should make ImportQualifiedPost affect splice > imports so we > > >> have > > >> > > >> import splice qualified A -- By default > > >> import A splice qualified -- Under ImportQualifiedPost > > >> > > >> In any case, please do vote! It would be good to get this > proposal done. > > >> > > >> Cheers, > > >> > > >> Adam > > >> > > >> > > >> > > >> On 27/01/2025 11:52, Simon Peyton Jones wrote: > > >> > Arnaud > > >> > > > >> > OK, following my call and some further iteration, the > proposal is much > > >> > improved. See here > > >> > > <[10]https://github.com/ghc-proposals/ghc-proposals/pull/682>. > Please > > >> read > > >> > the new "Proposed Change Specification" which has had a large > rewrite. > > >> > > > >> > I vote to accept. > > >> > > > >> > BUT there is one point that the committee must resolve: *one > extension > > >> > of two?* It's just a judgement call and I lay out the > choices in this > > >> > post > > >> > < > > >> > [11]https://github.com/ghc-proposals/ghc-proposals/pull/682#issuecom > ment-2609199731>. > > >> I doubt that we'll get much community feedback. I suggest that > we just > > >> vote. I vote for one, not two. As does Sebastian. > > >> > > > >> > Over to you Arnaud. Let's get this one done. Matthew is busy > > >> > implementing it for a customer and it has been on our to-do > list for > > >> > some time now. (Partly my fault.) > > >> > > > >> > Simon > > >> > > > >> > On Tue, 21 Jan 2025 at 10:48, Simon Peyton Jones > > >> > <[12]simon.peytonjones at gmail.com > > > > >> wrote: > > >> > > > >> > Matthew and I had a good conversation. Some notes here > > >> > < > > >> > [14]https://docs.google.com/document/d/1dEMPIHpbN19xYZymGCxO0BpQR58R > Phk5MslruY7yXD0/edit?usp=sharing > > >> >. > > >> > > > >> > He's going to work on a revision to the proposal which > I'll iterate > > >> > with him. > > >> > > > >> > Simon > > >> > > > >> > On Tue, 21 Jan 2025 at 07:37, Arnaud Spiwack > > >> > <[15]arnaud.spiwack at tweag.io > > wrote: > > >> > > > >> > Then, let's wait until your call with Matthew and > decide how to > > >> > act then. > > >> > > > >> > On Tue, 21 Jan 2025 at 02:43, Simon Peyton Jones > > >> > <[17]simon.peytonjones at gmail.com > > >> > > wrote: > > >> > > > >> > Arnaud > > >> > > > >> > I have responded with a lot of feedback on the > Github thread > > >> > < > > >> > [19]https://github.com/ghc-proposals/ghc-proposals/pull/682#pullrequ > estreview-2562175116 > > >> >. > > >> > > > >> > 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 > > >> > <[20]arnaud.spiwack at tweag.io > > > > >> > wrote: > > >> > > > >> > > > >> > Mathew Pickering, Rodrigo Mesquita, and our > own Adam > > >> > Gundry put forward a new proposal for the > perenial > > >> > problem of dependencies and Template Haskell > > >> > > [22]https://github.com/ghc-proposals/ghc-proposals/pull/682 > > >> > < > > >> [23]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 > [24]https://moduscreate.com > > >> > <[25]https://moduscreate.com> and > [26]https://tweag.io > > >> > <[27]https://tweag.io>. > > >> > > >> > > >> -- > > >> Adam Gundry, Haskell Consultant > > >> Well-Typed LLP, [28]https://www.well-typed.com/ > > >> > > >> Registered in England & Wales, OC335890 > > >> 27 Old Gloucester Street, London WC1N 3AX, England > > >> > > >> _______________________________________________ > > >> ghc-steering-committee mailing list > > >> [29]ghc-steering-committee at haskell.org > > >> > [30]https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-c > ommittee > > >> > > > _______________________________________________ > > > ghc-steering-committee mailing list > > > [31]ghc-steering-committee at haskell.org > > > > [32]https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-c > ommittee > > > > > > > > > -- > > Arnaud Spiwack > > Director, Research at [33]https://moduscreate.com and > [34]https://tweag.io. > > -- > -------------------------------------------------------------------- > -- > Erik de Castro Lopo > [35]http://www.mega-nerd.com/ > _______________________________________________ > ghc-steering-committee mailing list > [36]ghc-steering-committee at haskell.org > [37]https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-c > ommittee > > -- > > Arnaud Spiwack > Director, Research at [38]https://moduscreate.com and > [39]https://tweag.io. > > _______________________________________________ > ghc-steering-committee mailing list > [40]ghc-steering-committee at haskell.org > [41]https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-c > ommittee > > -- > > -- [42]Matthías Páll Gissurarson > > References > > 1. mailto:arnaud.spiwack at tweag.io > 2. https://github.com/ghc-proposals/ghc-proposals/pull/682#issuecomment-2609199731 > 3. mailto:marlowsd at gmail.com > 4. mailto:erikd at mega-nerd.com > 5. https://github.com/ghc-proposals/ghc-proposals/pull/682#issuecomment-2609199731 > 6. https://github.com/ghc-proposals/ghc-proposals/pull/682#issuecomment-2609583126 > 7. mailto:simon.peytonjones at gmail.com > 8. mailto:adam at well-typed.com > 9. https://github.com/ghc-proposals/ghc-proposals/pull/682#discussion_r1849123243 > 10. https://github.com/ghc-proposals/ghc-proposals/pull/682 > 11. https://github.com/ghc-proposals/ghc-proposals/pull/682#issuecomment-2609199731 > 12. mailto:simon.peytonjones at gmail.com > 13. mailto:simon.peytonjones at gmail.com > 14. https://docs.google.com/document/d/1dEMPIHpbN19xYZymGCxO0BpQR58RPhk5MslruY7yXD0/edit?usp=sharing > 15. mailto:arnaud.spiwack at tweag.io > 16. mailto:arnaud.spiwack at tweag.io > 17. mailto:simon.peytonjones at gmail.com > 18. mailto:simon.peytonjones at gmail.com > 19. https://github.com/ghc-proposals/ghc-proposals/pull/682#pullrequestreview-2562175116 > 20. mailto:arnaud.spiwack at tweag.io > 21. mailto:arnaud.spiwack at tweag.io > 22. https://github.com/ghc-proposals/ghc-proposals/pull/682 > 23. https://github.com/ghc-proposals/ghc-proposals/pull/682 > 24. https://moduscreate.com/ > 25. https://moduscreate.com/ > 26. https://tweag.io/ > 27. https://tweag.io/ > 28. https://www.well-typed.com/ > 29. mailto:ghc-steering-committee at haskell.org > 30. https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee > 31. mailto:ghc-steering-committee at haskell.org > 32. https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee > 33. https://moduscreate.com/ > 34. https://tweag.io/ > 35. http://www.mega-nerd.com/ > 36. mailto:ghc-steering-committee at haskell.org > 37. https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee > 38. https://moduscreate.com/ > 39. https://tweag.io/ > 40. mailto:ghc-steering-committee at haskell.org > 41. https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee > 42. http://mpg.is/ > _______________________________________________ > 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 Thu Feb 6 23:01:14 2025 From: erikd at mega-nerd.com (Erik de Castro Lopo) Date: Fri, 7 Feb 2025 10:01:14 +1100 Subject: [ghc-steering-committee] #682: Explicit Level Imports, recommendation: accept In-Reply-To: <20250205191643.60ec5f23d8b4571b8cf14ece@mega-nerd.com> References: <20250205191643.60ec5f23d8b4571b8cf14ece@mega-nerd.com> Message-ID: <20250207100114.c0dd8b72c6dc9167a58bff43@mega-nerd.com> OK, slightly in favor of two extensions. Erik Erik de Castro Lopo wrote: > Hi, > > I have read through the proposal, but there is something I am still unsure > of. For the LANGUAGE pragma's is there any utility in using one separately > form the other? It seems there isn't. In any one file you would use either > one or the other. > > Thanks, > Erik > > Arnaud Spiwack wrote: > > > Sorry I disappeared for a while. I second Simon's call, let's vote. Let me > > repost a link to Simon's pro and cons post > > https://github.com/ghc-proposals/ghc-proposals/pull/682#issuecomment-2609199731 > > > > So far, we have the following votes > > > > - Simon: 1 extension > > - Adam: 2 extension (feels quite strongly about it) > > - Sebastian: 1 extension (on the Github thread, but I'll count it as a vote > > anyway) > > > > Eric, Moritz, Malta, Matthías, Erik, Jakob: what do you think? > > > > --- > > > > Beyond that we have a single piece of community feedback on the Github > > thread. It's from Michael Peyton Jones who is in favour of 2 extensions, > > find it here > > https://github.com/ghc-proposals/ghc-proposals/pull/682#issuecomment-2609583126 > > > > --- > > > > For the record, I hadn't commented about it in my recommendation, despite > > my well-known and desperately public distaste for micro extensions. I have > > a couple of reasons: > > - I dislike micro-extensions less now that we are doing the GHC20XX (the > > last one was very modest, I'm in favour, by the way, of doing a much more > > ambitious language edition soon, otherwise my distaste will come back with > > a vengeance) > > - While I consider every proposal with several extensions in it with > > suspicion, the authors did argue for their second extension, I found the > > argument mildly convincing, and thought it wasn't worth fighting against. > > > > Now, even like this my preference is mildly for one extension. Adam says > > that it's easier to implement warnings with both the new syntax on and > > implicit stage persistence left turned on, than to implement errors when > > implicit stage persistence is turned off. It may be so, but I don't think > > we can avoid implementing the errors anyway, so I don't feel that it's a > > particularly compelling argument. I don't feel strongly. But that's > > presumably where my vote goes. > > > > On Tue, 4 Feb 2025 at 07:13, Simon Peyton Jones > > wrote: > > > > > Yes: all members of the steering committee, please vote. Evaluating > > > proposals is what we all signed up to do! > > > > > > Thanks > > > > > > Simon > > > > > > On Mon, 3 Feb 2025 at 20:45, Adam Gundry wrote: > > > > > >> I'm (unsurprisingly) in favour of acceptance, and I vote for two > > >> extensions. As I commented on the GitHub thread: > > >> > > >> > We shouldn't unnecessarily conflate a syntactic extension > > >> (ExplicitLevelImports) with a semantic one (NoImplicitStagePersistence) > > >> just because the common case is to want both and we want to keep the > > >> number of extensions lower. > > >> > > >> If there are reasons why having two extensions is actually problematic, > > >> I'd like to hear them. > > >> > > >> Also, at the risk of opening another avenue of discussion, we also need > > >> to resolve the syntax question (see > > >> > > >> https://github.com/ghc-proposals/ghc-proposals/pull/682#discussion_r1849123243). > > >> > > >> I don't have a very strong opinion here, but given that some people do, > > >> perhaps we should make ImportQualifiedPost affect splice imports so we > > >> have > > >> > > >> import splice qualified A -- By default > > >> import A splice qualified -- Under ImportQualifiedPost > > >> > > >> In any case, please do vote! It would be good to get this proposal done. > > >> > > >> Cheers, > > >> > > >> Adam > > >> > > >> > > >> > > >> On 27/01/2025 11:52, Simon Peyton Jones wrote: > > >> > Arnaud > > >> > > > >> > OK, following my call and some further iteration, the proposal is much > > >> > improved. See here > > >> > . Please > > >> read > > >> > the new "Proposed Change Specification" which has had a large rewrite. > > >> > > > >> > I vote to accept. > > >> > > > >> > BUT there is one point that the committee must resolve: *one extension > > >> > of two?* It's just a judgement call and I lay out the choices in this > > >> > post > > >> > < > > >> https://github.com/ghc-proposals/ghc-proposals/pull/682#issuecomment-2609199731>. > > >> I doubt that we'll get much community feedback. I suggest that we just > > >> vote. I vote for one, not two. As does Sebastian. > > >> > > > >> > Over to you Arnaud. Let's get this one done. Matthew is busy > > >> > implementing it for a customer and it has been on our to-do list for > > >> > some time now. (Partly my fault.) > > >> > > > >> > Simon > > >> > > > >> > On Tue, 21 Jan 2025 at 10:48, Simon Peyton Jones > > >> > > > > >> wrote: > > >> > > > >> > Matthew and I had a good conversation. Some notes here > > >> > < > > >> https://docs.google.com/document/d/1dEMPIHpbN19xYZymGCxO0BpQR58RPhk5MslruY7yXD0/edit?usp=sharing > > >> >. > > >> > > > >> > He's going to work on a revision to the proposal which I'll iterate > > >> > with him. > > >> > > > >> > Simon > > >> > > > >> > On Tue, 21 Jan 2025 at 07:37, Arnaud Spiwack > > >> > > wrote: > > >> > > > >> > Then, let's wait until your call with Matthew and decide how to > > >> > act then. > > >> > > > >> > On Tue, 21 Jan 2025 at 02:43, Simon Peyton Jones > > >> > > >> > > wrote: > > >> > > > >> > Arnaud > > >> > > > >> > I have responded with a lot of feedback on the Github thread > > >> > < > > >> https://github.com/ghc-proposals/ghc-proposals/pull/682#pullrequestreview-2562175116 > > >> >. > > >> > > > >> > 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 > > >> > < > > >> 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 > > >> > . > > >> > > >> > > >> -- > > >> 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 > > > > > > > > > -- > > Arnaud Spiwack > > Director, Research at https://moduscreate.com and https://tweag.io. > > > -- > ---------------------------------------------------------------------- > Erik de Castro Lopo > http://www.mega-nerd.com/ > -- ---------------------------------------------------------------------- Erik de Castro Lopo http://www.mega-nerd.com/ From arnaud.spiwack at tweag.io Fri Feb 7 06:48:53 2025 From: arnaud.spiwack at tweag.io (Arnaud Spiwack) Date: Fri, 7 Feb 2025 15:48:53 +0900 Subject: [ghc-steering-committee] #682: Explicit Level Imports, recommendation: accept In-Reply-To: <20250207100114.c0dd8b72c6dc9167a58bff43@mega-nerd.com> References: <20250205191643.60ec5f23d8b4571b8cf14ece@mega-nerd.com> <20250207100114.c0dd8b72c6dc9167a58bff43@mega-nerd.com> Message-ID: Ok, we have enough of a quorum at this point. If everybody else voted 1 extension this would come at a rough draw. It can't be a strong enough push to overrule the preference of the authors. I'll give it a handful more day, say until next Wednesday 12th February. If someone has a strong objection, please voice it very loudly. Otherwise I'll declare the proposal as accepted in its current state. Best, Arnaud On Fri, 7 Feb 2025 at 08:01, Erik de Castro Lopo wrote: > > OK, slightly in favor of two extensions. > > Erik > > > Erik de Castro Lopo wrote: > > > Hi, > > > > I have read through the proposal, but there is something I am still > unsure > > of. For the LANGUAGE pragma's is there any utility in using one > separately > > form the other? It seems there isn't. In any one file you would use > either > > one or the other. > > > > Thanks, > > Erik > > > > Arnaud Spiwack wrote: > > > > > Sorry I disappeared for a while. I second Simon's call, let's vote. > Let me > > > repost a link to Simon's pro and cons post > > > > https://github.com/ghc-proposals/ghc-proposals/pull/682#issuecomment-2609199731 > > > > > > So far, we have the following votes > > > > > > - Simon: 1 extension > > > - Adam: 2 extension (feels quite strongly about it) > > > - Sebastian: 1 extension (on the Github thread, but I'll count it as a > vote > > > anyway) > > > > > > Eric, Moritz, Malta, Matthías, Erik, Jakob: what do you think? > > > > > > --- > > > > > > Beyond that we have a single piece of community feedback on the Github > > > thread. It's from Michael Peyton Jones who is in favour of 2 > extensions, > > > find it here > > > > https://github.com/ghc-proposals/ghc-proposals/pull/682#issuecomment-2609583126 > > > > > > --- > > > > > > For the record, I hadn't commented about it in my recommendation, > despite > > > my well-known and desperately public distaste for micro extensions. I > have > > > a couple of reasons: > > > - I dislike micro-extensions less now that we are doing the GHC20XX > (the > > > last one was very modest, I'm in favour, by the way, of doing a much > more > > > ambitious language edition soon, otherwise my distaste will come back > with > > > a vengeance) > > > - While I consider every proposal with several extensions in it with > > > suspicion, the authors did argue for their second extension, I found > the > > > argument mildly convincing, and thought it wasn't worth fighting > against. > > > > > > Now, even like this my preference is mildly for one extension. Adam > says > > > that it's easier to implement warnings with both the new syntax on and > > > implicit stage persistence left turned on, than to implement errors > when > > > implicit stage persistence is turned off. It may be so, but I don't > think > > > we can avoid implementing the errors anyway, so I don't feel that it's > a > > > particularly compelling argument. I don't feel strongly. But that's > > > presumably where my vote goes. > > > > > > On Tue, 4 Feb 2025 at 07:13, Simon Peyton Jones < > simon.peytonjones at gmail.com> > > > wrote: > > > > > > > Yes: all members of the steering committee, please vote. Evaluating > > > > proposals is what we all signed up to do! > > > > > > > > Thanks > > > > > > > > Simon > > > > > > > > On Mon, 3 Feb 2025 at 20:45, Adam Gundry > wrote: > > > > > > > >> I'm (unsurprisingly) in favour of acceptance, and I vote for two > > > >> extensions. As I commented on the GitHub thread: > > > >> > > > >> > We shouldn't unnecessarily conflate a syntactic extension > > > >> (ExplicitLevelImports) with a semantic one > (NoImplicitStagePersistence) > > > >> just because the common case is to want both and we want to keep the > > > >> number of extensions lower. > > > >> > > > >> If there are reasons why having two extensions is actually > problematic, > > > >> I'd like to hear them. > > > >> > > > >> Also, at the risk of opening another avenue of discussion, we also > need > > > >> to resolve the syntax question (see > > > >> > > > >> > https://github.com/ghc-proposals/ghc-proposals/pull/682#discussion_r1849123243 > ). > > > >> > > > >> I don't have a very strong opinion here, but given that some people > do, > > > >> perhaps we should make ImportQualifiedPost affect splice imports so > we > > > >> have > > > >> > > > >> import splice qualified A -- By default > > > >> import A splice qualified -- Under ImportQualifiedPost > > > >> > > > >> In any case, please do vote! It would be good to get this proposal > done. > > > >> > > > >> Cheers, > > > >> > > > >> Adam > > > >> > > > >> > > > >> > > > >> On 27/01/2025 11:52, Simon Peyton Jones wrote: > > > >> > Arnaud > > > >> > > > > >> > OK, following my call and some further iteration, the proposal is > much > > > >> > improved. See here > > > >> > . > Please > > > >> read > > > >> > the new "Proposed Change Specification" which has had a large > rewrite. > > > >> > > > > >> > I vote to accept. > > > >> > > > > >> > BUT there is one point that the committee must resolve: *one > extension > > > >> > of two?* It's just a judgement call and I lay out the choices in > this > > > >> > post > > > >> > < > > > >> > https://github.com/ghc-proposals/ghc-proposals/pull/682#issuecomment-2609199731 > >. > > > >> I doubt that we'll get much community feedback. I suggest that we > just > > > >> vote. I vote for one, not two. As does Sebastian. > > > >> > > > > >> > Over to you Arnaud. Let's get this one done. Matthew is busy > > > >> > implementing it for a customer and it has been on our to-do list > for > > > >> > some time now. (Partly my fault.) > > > >> > > > > >> > Simon > > > >> > > > > >> > On Tue, 21 Jan 2025 at 10:48, Simon Peyton Jones > > > >> > >> > > > >> wrote: > > > >> > > > > >> > Matthew and I had a good conversation. Some notes here > > > >> > < > > > >> > https://docs.google.com/document/d/1dEMPIHpbN19xYZymGCxO0BpQR58RPhk5MslruY7yXD0/edit?usp=sharing > > > >> >. > > > >> > > > > >> > He's going to work on a revision to the proposal which I'll > iterate > > > >> > with him. > > > >> > > > > >> > Simon > > > >> > > > > >> > On Tue, 21 Jan 2025 at 07:37, Arnaud Spiwack > > > >> > > > wrote: > > > >> > > > > >> > Then, let's wait until your call with Matthew and decide > how to > > > >> > act then. > > > >> > > > > >> > On Tue, 21 Jan 2025 at 02:43, Simon Peyton Jones > > > >> > > > >> > > wrote: > > > >> > > > > >> > Arnaud > > > >> > > > > >> > I have responded with a lot of feedback on the Github > thread > > > >> > < > > > >> > https://github.com/ghc-proposals/ghc-proposals/pull/682#pullrequestreview-2562175116 > > > >> >. > > > >> > > > > >> > 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 > > > >> > arnaud.spiwack at tweag.io>> > > > >> > 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 > > > >> > < > > > >> 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 > > > >> > . > > > >> > > > >> > > > >> -- > > > >> 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 > > > > > > > > > > > > > -- > > > Arnaud Spiwack > > > Director, Research at https://moduscreate.com and https://tweag.io. > > > > > > -- > > ---------------------------------------------------------------------- > > Erik de Castro Lopo > > http://www.mega-nerd.com/ > > > > > -- > ---------------------------------------------------------------------- > Erik de Castro Lopo > http://www.mega-nerd.com/ > _______________________________________________ > 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 malte.ott at maralorn.de Fri Feb 7 12:16:26 2025 From: malte.ott at maralorn.de (Malte Ott) Date: Fri, 7 Feb 2025 13:16:26 +0100 Subject: [ghc-steering-committee] #682: Explicit Level Imports, recommendation: accept In-Reply-To: References: <20250205191643.60ec5f23d8b4571b8cf14ece@mega-nerd.com> <20250207100114.c0dd8b72c6dc9167a58bff43@mega-nerd.com> Message-ID: I do not object to accepting the proposal, but I don’t think we were finished with bikeshedding the syntax. At least I think the proposal should state what the syntax is when ImportQualifiedPost is enabled and voiced that on the GitHub thread. I know we all dread wasting our time with syntax discussions but lets at least think about it for 5 minutes. Best, Malte On 2025-02-07 15:48, Arnaud Spiwack wrote: > Ok, we have enough of a quorum at this point. If everybody else voted 1 > extension this would come at a rough draw. It can't be a strong enough > push to overrule the preference of the authors. > > I'll give it a handful more day, say until next Wednesday 12th > February. If someone has a strong objection, please voice it very > loudly. Otherwise I'll declare the proposal as accepted in its current > state. > > Best, > Arnaud > > On Fri, 7 Feb 2025 at 08:01, Erik de Castro Lopo > <[1]erikd at mega-nerd.com> wrote: > > OK, slightly in favor of two extensions. > > Erik > > Erik de Castro Lopo wrote: > > > Hi, > > > > I have read through the proposal, but there is something I am > still unsure > > of. For the LANGUAGE pragma's is there any utility in using one > separately > > form the other? It seems there isn't. In any one file you would > use either > > one or the other. > > > > Thanks, > > Erik > > > > Arnaud Spiwack wrote: > > > > > Sorry I disappeared for a while. I second Simon's call, let's > vote. Let me > > > repost a link to Simon's pro and cons post > > > > [2]https://github.com/ghc-proposals/ghc-proposals/pull/682#issuecomm > ent-2609199731 > > > > > > So far, we have the following votes > > > > > > - Simon: 1 extension > > > - Adam: 2 extension (feels quite strongly about it) > > > - Sebastian: 1 extension (on the Github thread, but I'll count > it as a vote > > > anyway) > > > > > > Eric, Moritz, Malta, Matthías, Erik, Jakob: what do you think? > > > > > > --- > > > > > > Beyond that we have a single piece of community feedback on the > Github > > > thread. It's from Michael Peyton Jones who is in favour of 2 > extensions, > > > find it here > > > > [3]https://github.com/ghc-proposals/ghc-proposals/pull/682#issuecomm > ent-2609583126 > > > > > > --- > > > > > > For the record, I hadn't commented about it in my > recommendation, despite > > > my well-known and desperately public distaste for micro > extensions. I have > > > a couple of reasons: > > > - I dislike micro-extensions less now that we are doing the > GHC20XX (the > > > last one was very modest, I'm in favour, by the way, of doing a > much more > > > ambitious language edition soon, otherwise my distaste will come > back with > > > a vengeance) > > > - While I consider every proposal with several extensions in it > with > > > suspicion, the authors did argue for their second extension, I > found the > > > argument mildly convincing, and thought it wasn't worth fighting > against. > > > > > > Now, even like this my preference is mildly for one extension. > Adam says > > > that it's easier to implement warnings with both the new syntax > on and > > > implicit stage persistence left turned on, than to implement > errors when > > > implicit stage persistence is turned off. It may be so, but I > don't think > > > we can avoid implementing the errors anyway, so I don't feel > that it's a > > > particularly compelling argument. I don't feel strongly. But > that's > > > presumably where my vote goes. > > > > > > On Tue, 4 Feb 2025 at 07:13, Simon Peyton Jones > <[4]simon.peytonjones at gmail.com> > > > wrote: > > > > > > > Yes: all members of the steering committee, please vote. > Evaluating > > > > proposals is what we all signed up to do! > > > > > > > > Thanks > > > > > > > > Simon > > > > > > > > On Mon, 3 Feb 2025 at 20:45, Adam Gundry > <[5]adam at well-typed.com> wrote: > > > > > > > >> I'm (unsurprisingly) in favour of acceptance, and I vote for > two > > > >> extensions. As I commented on the GitHub thread: > > > >> > > > >> > We shouldn't unnecessarily conflate a syntactic extension > > > >> (ExplicitLevelImports) with a semantic one > (NoImplicitStagePersistence) > > > >> just because the common case is to want both and we want to > keep the > > > >> number of extensions lower. > > > >> > > > >> If there are reasons why having two extensions is actually > problematic, > > > >> I'd like to hear them. > > > >> > > > >> Also, at the risk of opening another avenue of discussion, we > also need > > > >> to resolve the syntax question (see > > > >> > > > >> > [6]https://github.com/ghc-proposals/ghc-proposals/pull/682#discussio > n_r1849123243). > > > >> > > > >> I don't have a very strong opinion here, but given that some > people do, > > > >> perhaps we should make ImportQualifiedPost affect splice > imports so we > > > >> have > > > >> > > > >> import splice qualified A -- By default > > > >> import A splice qualified -- Under ImportQualifiedPost > > > >> > > > >> In any case, please do vote! It would be good to get this > proposal done. > > > >> > > > >> Cheers, > > > >> > > > >> Adam > > > >> > > > >> > > > >> > > > >> On 27/01/2025 11:52, Simon Peyton Jones wrote: > > > >> > Arnaud > > > >> > > > > >> > OK, following my call and some further iteration, the > proposal is much > > > >> > improved. See here > > > >> > > <[7]https://github.com/ghc-proposals/ghc-proposals/pull/682>. > Please > > > >> read > > > >> > the new "Proposed Change Specification" which has had a > large rewrite. > > > >> > > > > >> > I vote to accept. > > > >> > > > > >> > BUT there is one point that the committee must resolve: > *one extension > > > >> > of two?* It's just a judgement call and I lay out the > choices in this > > > >> > post > > > >> > < > > > >> > [8]https://github.com/ghc-proposals/ghc-proposals/pull/682#issuecomm > ent-2609199731>. > > > >> I doubt that we'll get much community feedback. I suggest > that we just > > > >> vote. I vote for one, not two. As does Sebastian. > > > >> > > > > >> > Over to you Arnaud. Let's get this one done. Matthew is > busy > > > >> > implementing it for a customer and it has been on our to-do > list for > > > >> > some time now. (Partly my fault.) > > > >> > > > > >> > Simon > > > >> > > > > >> > On Tue, 21 Jan 2025 at 10:48, Simon Peyton Jones > > > >> > <[9]simon.peytonjones at gmail.com > > > > > >> wrote: > > > >> > > > > >> > Matthew and I had a good conversation. Some notes here > > > >> > < > > > >> > [11]https://docs.google.com/document/d/1dEMPIHpbN19xYZymGCxO0BpQR58R > Phk5MslruY7yXD0/edit?usp=sharing > > > >> >. > > > >> > > > > >> > He's going to work on a revision to the proposal which > I'll iterate > > > >> > with him. > > > >> > > > > >> > Simon > > > >> > > > > >> > On Tue, 21 Jan 2025 at 07:37, Arnaud Spiwack > > > >> > <[12]arnaud.spiwack at tweag.io > > wrote: > > > >> > > > > >> > Then, let's wait until your call with Matthew and > decide how to > > > >> > act then. > > > >> > > > > >> > On Tue, 21 Jan 2025 at 02:43, Simon Peyton Jones > > > >> > <[14]simon.peytonjones at gmail.com > > > >> > > wrote: > > > >> > > > > >> > Arnaud > > > >> > > > > >> > I have responded with a lot of feedback on the > Github thread > > > >> > < > > > >> > [16]https://github.com/ghc-proposals/ghc-proposals/pull/682#pullrequ > estreview-2562175116 > > > >> >. > > > >> > > > > >> > 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 > > > >> > <[17]arnaud.spiwack at tweag.io > > > > > >> > wrote: > > > >> > > > > >> > > > > >> > Mathew Pickering, Rodrigo Mesquita, and our > own Adam > > > >> > Gundry put forward a new proposal for the > perenial > > > >> > problem of dependencies and Template > Haskell > > > >> > > [19]https://github.com/ghc-proposals/ghc-proposals/pull/682 > > > >> > < > > > >> [20]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 > [21]https://moduscreate.com > > > >> > <[22]https://moduscreate.com> and > [23]https://tweag.io > > > >> > <[24]https://tweag.io>. > > > >> > > > >> > > > >> -- > > > >> Adam Gundry, Haskell Consultant > > > >> Well-Typed LLP, [25]https://www.well-typed.com/ > > > >> > > > >> Registered in England & Wales, OC335890 > > > >> 27 Old Gloucester Street, London WC1N 3AX, England > > > >> > > > >> _______________________________________________ > > > >> ghc-steering-committee mailing list > > > >> [26]ghc-steering-committee at haskell.org > > > >> > [27]https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-c > ommittee > > > >> > > > > _______________________________________________ > > > > ghc-steering-committee mailing list > > > > [28]ghc-steering-committee at haskell.org > > > > > [29]https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-c > ommittee > > > > > > > > > > > > > -- > > > Arnaud Spiwack > > > Director, Research at [30]https://moduscreate.com and > [31]https://tweag.io. > > > > > > -- > > > -------------------------------------------------------------------- > -- > > Erik de Castro Lopo > > [32]http://www.mega-nerd.com/ > > > > -- > -------------------------------------------------------------------- > -- > Erik de Castro Lopo > [33]http://www.mega-nerd.com/ > _______________________________________________ > ghc-steering-committee mailing list > [34]ghc-steering-committee at haskell.org > [35]https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-c > ommittee > > -- > > Arnaud Spiwack > Director, Research at [36]https://moduscreate.com and > [37]https://tweag.io. > > References > > 1. mailto:erikd at mega-nerd.com > 2. https://github.com/ghc-proposals/ghc-proposals/pull/682#issuecomment-2609199731 > 3. https://github.com/ghc-proposals/ghc-proposals/pull/682#issuecomment-2609583126 > 4. mailto:simon.peytonjones at gmail.com > 5. mailto:adam at well-typed.com > 6. https://github.com/ghc-proposals/ghc-proposals/pull/682#discussion_r1849123243 > 7. https://github.com/ghc-proposals/ghc-proposals/pull/682 > 8. https://github.com/ghc-proposals/ghc-proposals/pull/682#issuecomment-2609199731 > 9. mailto:simon.peytonjones at gmail.com > 10. mailto:simon.peytonjones at gmail.com > 11. https://docs.google.com/document/d/1dEMPIHpbN19xYZymGCxO0BpQR58RPhk5MslruY7yXD0/edit?usp=sharing > 12. mailto:arnaud.spiwack at tweag.io > 13. mailto:arnaud.spiwack at tweag.io > 14. mailto:simon.peytonjones at gmail.com > 15. mailto:simon.peytonjones at gmail.com > 16. https://github.com/ghc-proposals/ghc-proposals/pull/682#pullrequestreview-2562175116 > 17. mailto:arnaud.spiwack at tweag.io > 18. mailto:arnaud.spiwack at tweag.io > 19. https://github.com/ghc-proposals/ghc-proposals/pull/682 > 20. https://github.com/ghc-proposals/ghc-proposals/pull/682 > 21. https://moduscreate.com/ > 22. https://moduscreate.com/ > 23. https://tweag.io/ > 24. https://tweag.io/ > 25. https://www.well-typed.com/ > 26. mailto:ghc-steering-committee at haskell.org > 27. https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee > 28. mailto:ghc-steering-committee at haskell.org > 29. https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee > 30. https://moduscreate.com/ > 31. https://tweag.io/ > 32. http://www.mega-nerd.com/ > 33. http://www.mega-nerd.com/ > 34. mailto:ghc-steering-committee at haskell.org > 35. https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee > 36. https://moduscreate.com/ > 37. 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 From simon.peytonjones at gmail.com Fri Feb 7 16:18:49 2025 From: simon.peytonjones at gmail.com (Simon Peyton Jones) Date: Fri, 7 Feb 2025 16:18:49 +0000 Subject: [ghc-steering-committee] #682: Explicit Level Imports, recommendation: accept In-Reply-To: References: <20250205191643.60ec5f23d8b4571b8cf14ece@mega-nerd.com> <20250207100114.c0dd8b72c6dc9167a58bff43@mega-nerd.com> Message-ID: I don’t think we were finished with bikeshedding the syntax. At least I think the proposal should state what the syntax is when ImportQualifiedPost is enabled and voiced that on the GitHub thread. OK -- but I suspect that most of us have lost context. Would you like to post (on the Github) a message explaining: - what the syntactic alternatives are - what you recommend That will help to focus the discussion Thanks! Simon On Fri, 7 Feb 2025 at 12:16, Malte Ott wrote: > I do not object to accepting the proposal, but I don’t think we were > finished > with bikeshedding the syntax. At least I think the proposal should state > what > the syntax is when ImportQualifiedPost is enabled and voiced that on the > GitHub > thread. > > I know we all dread wasting our time with syntax discussions but lets at > least > think about it for 5 minutes. > > Best, > Malte > > On 2025-02-07 15:48, Arnaud Spiwack wrote: > > Ok, we have enough of a quorum at this point. If everybody else voted > 1 > > extension this would come at a rough draw. It can't be a strong enough > > push to overrule the preference of the authors. > > > > I'll give it a handful more day, say until next Wednesday 12th > > February. If someone has a strong objection, please voice it very > > loudly. Otherwise I'll declare the proposal as accepted in its current > > state. > > > > Best, > > Arnaud > > > > On Fri, 7 Feb 2025 at 08:01, Erik de Castro Lopo > > <[1]erikd at mega-nerd.com> wrote: > > > > OK, slightly in favor of two extensions. > > > > Erik > > > > Erik de Castro Lopo wrote: > > > > > Hi, > > > > > > I have read through the proposal, but there is something I am > > still unsure > > > of. For the LANGUAGE pragma's is there any utility in using one > > separately > > > form the other? It seems there isn't. In any one file you would > > use either > > > one or the other. > > > > > > Thanks, > > > Erik > > > > > > Arnaud Spiwack wrote: > > > > > > > Sorry I disappeared for a while. I second Simon's call, let's > > vote. Let me > > > > repost a link to Simon's pro and cons post > > > > > > [2] > https://github.com/ghc-proposals/ghc-proposals/pull/682#issuecomm > > ent-2609199731 > > > > > > > > So far, we have the following votes > > > > > > > > - Simon: 1 extension > > > > - Adam: 2 extension (feels quite strongly about it) > > > > - Sebastian: 1 extension (on the Github thread, but I'll count > > it as a vote > > > > anyway) > > > > > > > > Eric, Moritz, Malta, Matthías, Erik, Jakob: what do you think? > > > > > > > > --- > > > > > > > > Beyond that we have a single piece of community feedback on the > > Github > > > > thread. It's from Michael Peyton Jones who is in favour of 2 > > extensions, > > > > find it here > > > > > > [3] > https://github.com/ghc-proposals/ghc-proposals/pull/682#issuecomm > > ent-2609583126 > > > > > > > > --- > > > > > > > > For the record, I hadn't commented about it in my > > recommendation, despite > > > > my well-known and desperately public distaste for micro > > extensions. I have > > > > a couple of reasons: > > > > - I dislike micro-extensions less now that we are doing the > > GHC20XX (the > > > > last one was very modest, I'm in favour, by the way, of doing a > > much more > > > > ambitious language edition soon, otherwise my distaste will come > > back with > > > > a vengeance) > > > > - While I consider every proposal with several extensions in it > > with > > > > suspicion, the authors did argue for their second extension, I > > found the > > > > argument mildly convincing, and thought it wasn't worth fighting > > against. > > > > > > > > Now, even like this my preference is mildly for one extension. > > Adam says > > > > that it's easier to implement warnings with both the new syntax > > on and > > > > implicit stage persistence left turned on, than to implement > > errors when > > > > implicit stage persistence is turned off. It may be so, but I > > don't think > > > > we can avoid implementing the errors anyway, so I don't feel > > that it's a > > > > particularly compelling argument. I don't feel strongly. But > > that's > > > > presumably where my vote goes. > > > > > > > > On Tue, 4 Feb 2025 at 07:13, Simon Peyton Jones > > <[4]simon.peytonjones at gmail.com> > > > > wrote: > > > > > > > > > Yes: all members of the steering committee, please vote. > > Evaluating > > > > > proposals is what we all signed up to do! > > > > > > > > > > Thanks > > > > > > > > > > Simon > > > > > > > > > > On Mon, 3 Feb 2025 at 20:45, Adam Gundry > > <[5]adam at well-typed.com> wrote: > > > > > > > > > >> I'm (unsurprisingly) in favour of acceptance, and I vote for > > two > > > > >> extensions. As I commented on the GitHub thread: > > > > >> > > > > >> > We shouldn't unnecessarily conflate a syntactic extension > > > > >> (ExplicitLevelImports) with a semantic one > > (NoImplicitStagePersistence) > > > > >> just because the common case is to want both and we want to > > keep the > > > > >> number of extensions lower. > > > > >> > > > > >> If there are reasons why having two extensions is actually > > problematic, > > > > >> I'd like to hear them. > > > > >> > > > > >> Also, at the risk of opening another avenue of discussion, we > > also need > > > > >> to resolve the syntax question (see > > > > >> > > > > >> > > [6] > https://github.com/ghc-proposals/ghc-proposals/pull/682#discussio > > n_r1849123243). > > > > >> > > > > >> I don't have a very strong opinion here, but given that some > > people do, > > > > >> perhaps we should make ImportQualifiedPost affect splice > > imports so we > > > > >> have > > > > >> > > > > >> import splice qualified A -- By default > > > > >> import A splice qualified -- Under ImportQualifiedPost > > > > >> > > > > >> In any case, please do vote! It would be good to get this > > proposal done. > > > > >> > > > > >> Cheers, > > > > >> > > > > >> Adam > > > > >> > > > > >> > > > > >> > > > > >> On 27/01/2025 11:52, Simon Peyton Jones wrote: > > > > >> > Arnaud > > > > >> > > > > > >> > OK, following my call and some further iteration, the > > proposal is much > > > > >> > improved. See here > > > > >> > > > <[7]https://github.com/ghc-proposals/ghc-proposals/pull/682>. > > Please > > > > >> read > > > > >> > the new "Proposed Change Specification" which has had a > > large rewrite. > > > > >> > > > > > >> > I vote to accept. > > > > >> > > > > > >> > BUT there is one point that the committee must resolve: > > *one extension > > > > >> > of two?* It's just a judgement call and I lay out the > > choices in this > > > > >> > post > > > > >> > < > > > > >> > > [8] > https://github.com/ghc-proposals/ghc-proposals/pull/682#issuecomm > > ent-2609199731>. > > > > >> I doubt that we'll get much community feedback. I suggest > > that we just > > > > >> vote. I vote for one, not two. As does Sebastian. > > > > >> > > > > > >> > Over to you Arnaud. Let's get this one done. Matthew is > > busy > > > > >> > implementing it for a customer and it has been on our to-do > > list for > > > > >> > some time now. (Partly my fault.) > > > > >> > > > > > >> > Simon > > > > >> > > > > > >> > On Tue, 21 Jan 2025 at 10:48, Simon Peyton Jones > > > > >> > <[9]simon.peytonjones at gmail.com > > > > > > > >> wrote: > > > > >> > > > > > >> > Matthew and I had a good conversation. Some notes here > > > > >> > < > > > > >> > > [11] > https://docs.google.com/document/d/1dEMPIHpbN19xYZymGCxO0BpQR58R > > Phk5MslruY7yXD0/edit?usp=sharing > > > > >> >. > > > > >> > > > > > >> > He's going to work on a revision to the proposal which > > I'll iterate > > > > >> > with him. > > > > >> > > > > > >> > Simon > > > > >> > > > > > >> > On Tue, 21 Jan 2025 at 07:37, Arnaud Spiwack > > > > >> > <[12]arnaud.spiwack at tweag.io > > > wrote: > > > > >> > > > > > >> > Then, let's wait until your call with Matthew and > > decide how to > > > > >> > act then. > > > > >> > > > > > >> > On Tue, 21 Jan 2025 at 02:43, Simon Peyton Jones > > > > >> > <[14]simon.peytonjones at gmail.com > > > > >> > > wrote: > > > > >> > > > > > >> > Arnaud > > > > >> > > > > > >> > I have responded with a lot of feedback on the > > Github thread > > > > >> > < > > > > >> > > [16] > https://github.com/ghc-proposals/ghc-proposals/pull/682#pullrequ > > estreview-2562175116 > > > > >> >. > > > > >> > > > > > >> > 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 > > > > >> > <[17]arnaud.spiwack at tweag.io > > > > > > > >> > wrote: > > > > >> > > > > > >> > > > > > >> > Mathew Pickering, Rodrigo Mesquita, and our > > own Adam > > > > >> > Gundry put forward a new proposal for the > > perenial > > > > >> > problem of dependencies and Template > > Haskell > > > > >> > > > [19]https://github.com/ghc-proposals/ghc-proposals/pull/682 > > > > >> > < > > > > >> [20]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 > > [21]https://moduscreate.com > > > > >> > <[22]https://moduscreate.com> and > > [23]https://tweag.io > > > > >> > <[24]https://tweag.io>. > > > > >> > > > > >> > > > > >> -- > > > > >> Adam Gundry, Haskell Consultant > > > > >> Well-Typed LLP, [25]https://www.well-typed.com/ > > > > >> > > > > >> Registered in England & Wales, OC335890 > > > > >> 27 Old Gloucester Street, London WC1N 3AX, England > > > > >> > > > > >> _______________________________________________ > > > > >> ghc-steering-committee mailing list > > > > >> [26]ghc-steering-committee at haskell.org > > > > >> > > [27] > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-c > > ommittee > > > > >> > > > > > _______________________________________________ > > > > > ghc-steering-committee mailing list > > > > > [28]ghc-steering-committee at haskell.org > > > > > > > [29] > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-c > > ommittee > > > > > > > > > > > > > > > > > -- > > > > Arnaud Spiwack > > > > Director, Research at [30]https://moduscreate.com and > > [31]https://tweag.io. > > > > > > > > > -- > > > > > -------------------------------------------------------------------- > > -- > > > Erik de Castro Lopo > > > [32]http://www.mega-nerd.com/ > > > > > > > -- > > -------------------------------------------------------------------- > > -- > > Erik de Castro Lopo > > [33]http://www.mega-nerd.com/ > > _______________________________________________ > > ghc-steering-committee mailing list > > [34]ghc-steering-committee at haskell.org > > [35] > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-c > > ommittee > > > > -- > > > > Arnaud Spiwack > > Director, Research at [36]https://moduscreate.com and > > [37]https://tweag.io. > > > > References > > > > 1. mailto:erikd at mega-nerd.com > > 2. > https://github.com/ghc-proposals/ghc-proposals/pull/682#issuecomment-2609199731 > > 3. > https://github.com/ghc-proposals/ghc-proposals/pull/682#issuecomment-2609583126 > > 4. mailto:simon.peytonjones at gmail.com > > 5. mailto:adam at well-typed.com > > 6. > https://github.com/ghc-proposals/ghc-proposals/pull/682#discussion_r1849123243 > > 7. https://github.com/ghc-proposals/ghc-proposals/pull/682 > > 8. > https://github.com/ghc-proposals/ghc-proposals/pull/682#issuecomment-2609199731 > > 9. mailto:simon.peytonjones at gmail.com > > 10. mailto:simon.peytonjones at gmail.com > > 11. > https://docs.google.com/document/d/1dEMPIHpbN19xYZymGCxO0BpQR58RPhk5MslruY7yXD0/edit?usp=sharing > > 12. mailto:arnaud.spiwack at tweag.io > > 13. mailto:arnaud.spiwack at tweag.io > > 14. mailto:simon.peytonjones at gmail.com > > 15. mailto:simon.peytonjones at gmail.com > > 16. > https://github.com/ghc-proposals/ghc-proposals/pull/682#pullrequestreview-2562175116 > > 17. mailto:arnaud.spiwack at tweag.io > > 18. mailto:arnaud.spiwack at tweag.io > > 19. https://github.com/ghc-proposals/ghc-proposals/pull/682 > > 20. https://github.com/ghc-proposals/ghc-proposals/pull/682 > > 21. https://moduscreate.com/ > > 22. https://moduscreate.com/ > > 23. https://tweag.io/ > > 24. https://tweag.io/ > > 25. https://www.well-typed.com/ > > 26. mailto:ghc-steering-committee at haskell.org > > 27. > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee > > 28. mailto:ghc-steering-committee at haskell.org > > 29. > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee > > 30. https://moduscreate.com/ > > 31. https://tweag.io/ > > 32. http://www.mega-nerd.com/ > > 33. http://www.mega-nerd.com/ > > 34. mailto:ghc-steering-committee at haskell.org > > 35. > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee > > 36. https://moduscreate.com/ > > 37. 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 > > _______________________________________________ > 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 arnaud.spiwack at tweag.io Mon Feb 10 06:25:44 2025 From: arnaud.spiwack at tweag.io (Arnaud Spiwack) Date: Mon, 10 Feb 2025 15:25:44 +0900 Subject: [ghc-steering-committee] #682: Explicit Level Imports, recommendation: accept In-Reply-To: References: <20250205191643.60ec5f23d8b4571b8cf14ece@mega-nerd.com> <20250207100114.c0dd8b72c6dc9167a58bff43@mega-nerd.com> Message-ID: For the record, the syntactic alternatives can be found in [§8.5 Syntactic alternatives]( https://github.com/well-typed/ghc-proposals/blob/wip/level-imports-2024/proposals/0000-splice-imports.rst#syntactic-alternatives ) Malte seems to be uncomfortable with the fact that the proposed syntax is import slice Foo import quote Bar Even when ImportQualifiedPost, which enables the syntax import Foo qualified [as …] is enabled. The proposal offers alternative syntaxes like import Foo slice Import Bar quote or (to sound more English) import Foo for slice import Bar for quote Richard Eisenberg, in the thread, suggests that the motivation for ImportQualifiedPost doesn't apply to slice/quote because he believes that there's going to be one block of import slice, one block of import (nothing), one block of import quote, and they aren't going to be mixed together. Them being more visually distinguished by starting with the keyword is an asset in this view. Many seem convinced My understanding of Malte's point is that this is not intuitive enough that it can be left implicit in the proposal, and he'd like the proposal to at least state explicitly that it ignores ImportQualifiedPost. Malte, let me know if I misrepresent your point of view (or anybody else's). On Sat, 8 Feb 2025 at 01:19, Simon Peyton Jones wrote: > I don’t think we were finished > with bikeshedding the syntax. At least I think the proposal should state > what > the syntax is when ImportQualifiedPost is enabled and voiced that on the > GitHub > thread. > > > OK -- but I suspect that most of us have lost context. > > Would you like to post (on the Github) a message explaining: > > - what the syntactic alternatives are > - what you recommend > > That will help to focus the discussion > > Thanks! > > Simon > > > On Fri, 7 Feb 2025 at 12:16, Malte Ott wrote: > >> I do not object to accepting the proposal, but I don’t think we were >> finished >> with bikeshedding the syntax. At least I think the proposal should state >> what >> the syntax is when ImportQualifiedPost is enabled and voiced that on the >> GitHub >> thread. >> >> I know we all dread wasting our time with syntax discussions but lets at >> least >> think about it for 5 minutes. >> >> Best, >> Malte >> >> On 2025-02-07 15:48, Arnaud Spiwack wrote: >> > Ok, we have enough of a quorum at this point. If everybody else >> voted 1 >> > extension this would come at a rough draw. It can't be a strong >> enough >> > push to overrule the preference of the authors. >> > >> > I'll give it a handful more day, say until next Wednesday 12th >> > February. If someone has a strong objection, please voice it very >> > loudly. Otherwise I'll declare the proposal as accepted in its >> current >> > state. >> > >> > Best, >> > Arnaud >> > >> > On Fri, 7 Feb 2025 at 08:01, Erik de Castro Lopo >> > <[1]erikd at mega-nerd.com> wrote: >> > >> > OK, slightly in favor of two extensions. >> > >> > Erik >> > >> > Erik de Castro Lopo wrote: >> > >> > > Hi, >> > > >> > > I have read through the proposal, but there is something I am >> > still unsure >> > > of. For the LANGUAGE pragma's is there any utility in using one >> > separately >> > > form the other? It seems there isn't. In any one file you would >> > use either >> > > one or the other. >> > > >> > > Thanks, >> > > Erik >> > > >> > > Arnaud Spiwack wrote: >> > > >> > > > Sorry I disappeared for a while. I second Simon's call, let's >> > vote. Let me >> > > > repost a link to Simon's pro and cons post >> > > > >> > [2] >> https://github.com/ghc-proposals/ghc-proposals/pull/682#issuecomm >> > ent-2609199731 >> > > > >> > > > So far, we have the following votes >> > > > >> > > > - Simon: 1 extension >> > > > - Adam: 2 extension (feels quite strongly about it) >> > > > - Sebastian: 1 extension (on the Github thread, but I'll count >> > it as a vote >> > > > anyway) >> > > > >> > > > Eric, Moritz, Malta, Matthías, Erik, Jakob: what do you think? >> > > > >> > > > --- >> > > > >> > > > Beyond that we have a single piece of community feedback on the >> > Github >> > > > thread. It's from Michael Peyton Jones who is in favour of 2 >> > extensions, >> > > > find it here >> > > > >> > [3] >> https://github.com/ghc-proposals/ghc-proposals/pull/682#issuecomm >> > ent-2609583126 >> > > > >> > > > --- >> > > > >> > > > For the record, I hadn't commented about it in my >> > recommendation, despite >> > > > my well-known and desperately public distaste for micro >> > extensions. I have >> > > > a couple of reasons: >> > > > - I dislike micro-extensions less now that we are doing the >> > GHC20XX (the >> > > > last one was very modest, I'm in favour, by the way, of doing a >> > much more >> > > > ambitious language edition soon, otherwise my distaste will >> come >> > back with >> > > > a vengeance) >> > > > - While I consider every proposal with several extensions in it >> > with >> > > > suspicion, the authors did argue for their second extension, I >> > found the >> > > > argument mildly convincing, and thought it wasn't worth >> fighting >> > against. >> > > > >> > > > Now, even like this my preference is mildly for one extension. >> > Adam says >> > > > that it's easier to implement warnings with both the new syntax >> > on and >> > > > implicit stage persistence left turned on, than to implement >> > errors when >> > > > implicit stage persistence is turned off. It may be so, but I >> > don't think >> > > > we can avoid implementing the errors anyway, so I don't feel >> > that it's a >> > > > particularly compelling argument. I don't feel strongly. But >> > that's >> > > > presumably where my vote goes. >> > > > >> > > > On Tue, 4 Feb 2025 at 07:13, Simon Peyton Jones >> > <[4]simon.peytonjones at gmail.com> >> > > > wrote: >> > > > >> > > > > Yes: all members of the steering committee, please vote. >> > Evaluating >> > > > > proposals is what we all signed up to do! >> > > > > >> > > > > Thanks >> > > > > >> > > > > Simon >> > > > > >> > > > > On Mon, 3 Feb 2025 at 20:45, Adam Gundry >> > <[5]adam at well-typed.com> wrote: >> > > > > >> > > > >> I'm (unsurprisingly) in favour of acceptance, and I vote for >> > two >> > > > >> extensions. As I commented on the GitHub thread: >> > > > >> >> > > > >> > We shouldn't unnecessarily conflate a syntactic extension >> > > > >> (ExplicitLevelImports) with a semantic one >> > (NoImplicitStagePersistence) >> > > > >> just because the common case is to want both and we want to >> > keep the >> > > > >> number of extensions lower. >> > > > >> >> > > > >> If there are reasons why having two extensions is actually >> > problematic, >> > > > >> I'd like to hear them. >> > > > >> >> > > > >> Also, at the risk of opening another avenue of discussion, >> we >> > also need >> > > > >> to resolve the syntax question (see >> > > > >> >> > > > >> >> > [6] >> https://github.com/ghc-proposals/ghc-proposals/pull/682#discussio >> > n_r1849123243). >> > > > >> >> > > > >> I don't have a very strong opinion here, but given that some >> > people do, >> > > > >> perhaps we should make ImportQualifiedPost affect splice >> > imports so we >> > > > >> have >> > > > >> >> > > > >> import splice qualified A -- By default >> > > > >> import A splice qualified -- Under ImportQualifiedPost >> > > > >> >> > > > >> In any case, please do vote! It would be good to get this >> > proposal done. >> > > > >> >> > > > >> Cheers, >> > > > >> >> > > > >> Adam >> > > > >> >> > > > >> >> > > > >> >> > > > >> On 27/01/2025 11:52, Simon Peyton Jones wrote: >> > > > >> > Arnaud >> > > > >> > >> > > > >> > OK, following my call and some further iteration, the >> > proposal is much >> > > > >> > improved. See here >> > > > >> > >> > <[7]https://github.com/ghc-proposals/ghc-proposals/pull/682>. >> > Please >> > > > >> read >> > > > >> > the new "Proposed Change Specification" which has had a >> > large rewrite. >> > > > >> > >> > > > >> > I vote to accept. >> > > > >> > >> > > > >> > BUT there is one point that the committee must resolve: >> > *one extension >> > > > >> > of two?* It's just a judgement call and I lay out the >> > choices in this >> > > > >> > post >> > > > >> > < >> > > > >> >> > [8] >> https://github.com/ghc-proposals/ghc-proposals/pull/682#issuecomm >> > ent-2609199731>. >> > > > >> I doubt that we'll get much community feedback. I suggest >> > that we just >> > > > >> vote. I vote for one, not two. As does Sebastian. >> > > > >> > >> > > > >> > Over to you Arnaud. Let's get this one done. Matthew is >> > busy >> > > > >> > implementing it for a customer and it has been on our >> to-do >> > list for >> > > > >> > some time now. (Partly my fault.) >> > > > >> > >> > > > >> > Simon >> > > > >> > >> > > > >> > On Tue, 21 Jan 2025 at 10:48, Simon Peyton Jones >> > > > >> > <[9]simon.peytonjones at gmail.com >> > > >> > > > >> wrote: >> > > > >> > >> > > > >> > Matthew and I had a good conversation. Some notes here >> > > > >> > < >> > > > >> >> > [11] >> https://docs.google.com/document/d/1dEMPIHpbN19xYZymGCxO0BpQR58R >> > Phk5MslruY7yXD0/edit?usp=sharing >> > > > >> >. >> > > > >> > >> > > > >> > He's going to work on a revision to the proposal which >> > I'll iterate >> > > > >> > with him. >> > > > >> > >> > > > >> > Simon >> > > > >> > >> > > > >> > On Tue, 21 Jan 2025 at 07:37, Arnaud Spiwack >> > > > >> > <[12]arnaud.spiwack at tweag.io >> > > wrote: >> > > > >> > >> > > > >> > Then, let's wait until your call with Matthew and >> > decide how to >> > > > >> > act then. >> > > > >> > >> > > > >> > On Tue, 21 Jan 2025 at 02:43, Simon Peyton Jones >> > > > >> > <[14]simon.peytonjones at gmail.com >> > > > >> > > wrote: >> > > > >> > >> > > > >> > Arnaud >> > > > >> > >> > > > >> > I have responded with a lot of feedback on the >> > Github thread >> > > > >> > < >> > > > >> >> > [16] >> https://github.com/ghc-proposals/ghc-proposals/pull/682#pullrequ >> > estreview-2562175116 >> > > > >> >. >> > > > >> > >> > > > >> > 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 >> > > > >> > <[17]arnaud.spiwack at tweag.io >> > > >> > > > >> > wrote: >> > > > >> > >> > > > >> > >> > > > >> > Mathew Pickering, Rodrigo Mesquita, and >> our >> > own Adam >> > > > >> > Gundry put forward a new proposal for the >> > perenial >> > > > >> > problem of dependencies and Template >> > Haskell >> > > > >> > >> > [19]https://github.com/ghc-proposals/ghc-proposals/pull/682 >> > > > >> > < >> > > > >> [20]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 >> > [21]https://moduscreate.com >> > > > >> > <[22]https://moduscreate.com> and >> > [23]https://tweag.io >> > > > >> > <[24]https://tweag.io>. >> > > > >> >> > > > >> >> > > > >> -- >> > > > >> Adam Gundry, Haskell Consultant >> > > > >> Well-Typed LLP, [25]https://www.well-typed.com/ >> > > > >> >> > > > >> Registered in England & Wales, OC335890 >> > > > >> 27 Old Gloucester Street, London WC1N 3AX, England >> > > > >> >> > > > >> _______________________________________________ >> > > > >> ghc-steering-committee mailing list >> > > > >> [26]ghc-steering-committee at haskell.org >> > > > >> >> > [27] >> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-c >> > ommittee >> > > > >> >> > > > > _______________________________________________ >> > > > > ghc-steering-committee mailing list >> > > > > [28]ghc-steering-committee at haskell.org >> > > > > >> > [29] >> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-c >> > ommittee >> > > > > >> > > > >> > > > >> > > > -- >> > > > Arnaud Spiwack >> > > > Director, Research at [30]https://moduscreate.com and >> > [31]https://tweag.io. >> > > >> > > >> > > -- >> > > >> > >> -------------------------------------------------------------------- >> > -- >> > > Erik de Castro Lopo >> > > [32]http://www.mega-nerd.com/ >> > > >> > >> > -- >> > >> -------------------------------------------------------------------- >> > -- >> > Erik de Castro Lopo >> > [33]http://www.mega-nerd.com/ >> > _______________________________________________ >> > ghc-steering-committee mailing list >> > [34]ghc-steering-committee at haskell.org >> > [35] >> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-c >> > ommittee >> > >> > -- >> > >> > Arnaud Spiwack >> > Director, Research at [36]https://moduscreate.com and >> > [37]https://tweag.io. >> > >> > References >> > >> > 1. mailto:erikd at mega-nerd.com >> > 2. >> https://github.com/ghc-proposals/ghc-proposals/pull/682#issuecomment-2609199731 >> > 3. >> https://github.com/ghc-proposals/ghc-proposals/pull/682#issuecomment-2609583126 >> > 4. mailto:simon.peytonjones at gmail.com >> > 5. mailto:adam at well-typed.com >> > 6. >> https://github.com/ghc-proposals/ghc-proposals/pull/682#discussion_r1849123243 >> > 7. https://github.com/ghc-proposals/ghc-proposals/pull/682 >> > 8. >> https://github.com/ghc-proposals/ghc-proposals/pull/682#issuecomment-2609199731 >> > 9. mailto:simon.peytonjones at gmail.com >> > 10. mailto:simon.peytonjones at gmail.com >> > 11. >> https://docs.google.com/document/d/1dEMPIHpbN19xYZymGCxO0BpQR58RPhk5MslruY7yXD0/edit?usp=sharing >> > 12. mailto:arnaud.spiwack at tweag.io >> > 13. mailto:arnaud.spiwack at tweag.io >> > 14. mailto:simon.peytonjones at gmail.com >> > 15. mailto:simon.peytonjones at gmail.com >> > 16. >> https://github.com/ghc-proposals/ghc-proposals/pull/682#pullrequestreview-2562175116 >> > 17. mailto:arnaud.spiwack at tweag.io >> > 18. mailto:arnaud.spiwack at tweag.io >> > 19. https://github.com/ghc-proposals/ghc-proposals/pull/682 >> > 20. https://github.com/ghc-proposals/ghc-proposals/pull/682 >> > 21. https://moduscreate.com/ >> > 22. https://moduscreate.com/ >> > 23. https://tweag.io/ >> > 24. https://tweag.io/ >> > 25. https://www.well-typed.com/ >> > 26. mailto:ghc-steering-committee at haskell.org >> > 27. >> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee >> > 28. mailto:ghc-steering-committee at haskell.org >> > 29. >> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee >> > 30. https://moduscreate.com/ >> > 31. https://tweag.io/ >> > 32. http://www.mega-nerd.com/ >> > 33. http://www.mega-nerd.com/ >> > 34. mailto:ghc-steering-committee at haskell.org >> > 35. >> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee >> > 36. https://moduscreate.com/ >> > 37. 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 >> >> _______________________________________________ >> 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 > -- Arnaud Spiwack Director, Research at https://moduscreate.com and https://tweag.io. -------------- next part -------------- An HTML attachment was scrubbed... URL: From malte.ott at maralorn.de Mon Feb 10 08:48:13 2025 From: malte.ott at maralorn.de (Malte Ott) Date: Mon, 10 Feb 2025 09:48:13 +0100 Subject: [ghc-steering-committee] #682: Explicit Level Imports, recommendation: accept In-Reply-To: References: <20250205191643.60ec5f23d8b4571b8cf14ece@mega-nerd.com> <20250207100114.c0dd8b72c6dc9167a58bff43@mega-nerd.com> Message-ID: Yes, Arnaud, that was my point, thank you. People voiced opinions about syntax and I didn’t want to silently ignore them. I, however, retract my point about the proposal being ambiguous regarding ImportQualifiedPost. I actually think the specification is clear. Now it is up to us to consider the alternatives. If the rest of the committee does not think that any of the listed syntactic alternatives have merit, I am fine with that. I am not super convinced by Richards argument because I am sceptical that (all) code formatters would implement that grouping soon. So I would consider the proposed alternative of allowing splices after the modid. Best, Malte On 2025-02-10 15:25, Arnaud Spiwack wrote: > For the record, the syntactic alternatives can be found in [§8.5 > Syntactic > alternatives]([1]https://github.com/well-typed/ghc-proposals/blob/wip/l > evel-imports-2024/proposals/0000-splice-imports.rst#syntactic-alternati > ves) > > Malte seems to be uncomfortable with the fact that the proposed syntax > is > > import slice Foo > import quote Bar > > Even when ImportQualifiedPost, which enables the syntax > > import Foo qualified [as …] > > is enabled. > > The proposal offers alternative syntaxes like > > import Foo slice > Import Bar quote > > or (to sound more English) > > import Foo for slice > import Bar for quote > > Richard Eisenberg, in the thread, suggests that the motivation for > ImportQualifiedPost doesn't apply to slice/quote because he believes > that there's going to be one block of import slice, one block of import > (nothing), one block of import quote, and they aren't going to be mixed > together. Them being more visually distinguished by starting with the > keyword is an asset in this view. Many seem convinced > > My understanding of Malte's point is that this is not intuitive enough > that it can be left implicit in the proposal, and he'd like the > proposal to at least state explicitly that it ignores > ImportQualifiedPost. > > Malte, let me know if I misrepresent your point of view (or anybody > else's). > > On Sat, 8 Feb 2025 at 01:19, Simon Peyton Jones > <[2]simon.peytonjones at gmail.com> wrote: > > I don’t think we were finished > with bikeshedding the syntax. At least I think the proposal should > state what > the syntax is when ImportQualifiedPost is enabled and voiced that on > the GitHub > thread. > > OK -- but I suspect that most of us have lost context. > > Would you like to post (on the Github) a message explaining: > * what the syntactic alternatives are > * what you recommend > > That will help to focus the discussion > > Thanks! > > Simon > > On Fri, 7 Feb 2025 at 12:16, Malte Ott <[3]malte.ott at maralorn.de> > wrote: > > I do not object to accepting the proposal, but I don’t think we were > finished > with bikeshedding the syntax. At least I think the proposal should > state what > the syntax is when ImportQualifiedPost is enabled and voiced that on > the GitHub > thread. > > I know we all dread wasting our time with syntax discussions but > lets at least > think about it for 5 minutes. > > Best, > Malte > > On 2025-02-07 15:48, Arnaud Spiwack wrote: > > Ok, we have enough of a quorum at this point. If everybody else > voted 1 > > extension this would come at a rough draw. It can't be a strong > enough > > push to overrule the preference of the authors. > > > > I'll give it a handful more day, say until next Wednesday 12th > > February. If someone has a strong objection, please voice it > very > > loudly. Otherwise I'll declare the proposal as accepted in its > current > > state. > > > > Best, > > Arnaud > > > > On Fri, 7 Feb 2025 at 08:01, Erik de Castro Lopo > > <[1][4]erikd at mega-nerd.com> wrote: > > > > OK, slightly in favor of two extensions. > > > > Erik > > > > Erik de Castro Lopo wrote: > > > > > Hi, > > > > > > I have read through the proposal, but there is something I > am > > still unsure > > > of. For the LANGUAGE pragma's is there any utility in using > one > > separately > > > form the other? It seems there isn't. In any one file you > would > > use either > > > one or the other. > > > > > > Thanks, > > > Erik > > > > > > Arnaud Spiwack wrote: > > > > > > > Sorry I disappeared for a while. I second Simon's call, > let's > > vote. Let me > > > > repost a link to Simon's pro and cons post > > > > > > > [2][5]https://github.com/ghc-proposals/ghc-proposals/pull/682#issuec > omm > > ent-2609199731 > > > > > > > > So far, we have the following votes > > > > > > > > - Simon: 1 extension > > > > - Adam: 2 extension (feels quite strongly about it) > > > > - Sebastian: 1 extension (on the Github thread, but I'll > count > > it as a vote > > > > anyway) > > > > > > > > Eric, Moritz, Malta, Matthías, Erik, Jakob: what do you > think? > > > > > > > > --- > > > > > > > > Beyond that we have a single piece of community feedback > on the > > Github > > > > thread. It's from Michael Peyton Jones who is in favour > of 2 > > extensions, > > > > find it here > > > > > > > [3][6]https://github.com/ghc-proposals/ghc-proposals/pull/682#issuec > omm > > ent-2609583126 > > > > > > > > --- > > > > > > > > For the record, I hadn't commented about it in my > > recommendation, despite > > > > my well-known and desperately public distaste for micro > > extensions. I have > > > > a couple of reasons: > > > > - I dislike micro-extensions less now that we are doing > the > > GHC20XX (the > > > > last one was very modest, I'm in favour, by the way, of > doing a > > much more > > > > ambitious language edition soon, otherwise my distaste > will come > > back with > > > > a vengeance) > > > > - While I consider every proposal with several extensions > in it > > with > > > > suspicion, the authors did argue for their second > extension, I > > found the > > > > argument mildly convincing, and thought it wasn't worth > fighting > > against. > > > > > > > > Now, even like this my preference is mildly for one > extension. > > Adam says > > > > that it's easier to implement warnings with both the new > syntax > > on and > > > > implicit stage persistence left turned on, than to > implement > > errors when > > > > implicit stage persistence is turned off. It may be so, > but I > > don't think > > > > we can avoid implementing the errors anyway, so I don't > feel > > that it's a > > > > particularly compelling argument. I don't feel strongly. > But > > that's > > > > presumably where my vote goes. > > > > > > > > On Tue, 4 Feb 2025 at 07:13, Simon Peyton Jones > > <[4][7]simon.peytonjones at gmail.com> > > > > wrote: > > > > > > > > > Yes: all members of the steering committee, please > vote. > > Evaluating > > > > > proposals is what we all signed up to do! > > > > > > > > > > Thanks > > > > > > > > > > Simon > > > > > > > > > > On Mon, 3 Feb 2025 at 20:45, Adam Gundry > > <[5][8]adam at well-typed.com> wrote: > > > > > > > > > >> I'm (unsurprisingly) in favour of acceptance, and I > vote for > > two > > > > >> extensions. As I commented on the GitHub thread: > > > > >> > > > > >> > We shouldn't unnecessarily conflate a syntactic > extension > > > > >> (ExplicitLevelImports) with a semantic one > > (NoImplicitStagePersistence) > > > > >> just because the common case is to want both and we > want to > > keep the > > > > >> number of extensions lower. > > > > >> > > > > >> If there are reasons why having two extensions is > actually > > problematic, > > > > >> I'd like to hear them. > > > > >> > > > > >> Also, at the risk of opening another avenue of > discussion, we > > also need > > > > >> to resolve the syntax question (see > > > > >> > > > > >> > > > [6][9]https://github.com/ghc-proposals/ghc-proposals/pull/682#discus > sio > > n_r1849123243). > > > > >> > > > > >> I don't have a very strong opinion here, but given > that some > > people do, > > > > >> perhaps we should make ImportQualifiedPost affect > splice > > imports so we > > > > >> have > > > > >> > > > > >> import splice qualified A -- By default > > > > >> import A splice qualified -- Under > ImportQualifiedPost > > > > >> > > > > >> In any case, please do vote! It would be good to get > this > > proposal done. > > > > >> > > > > >> Cheers, > > > > >> > > > > >> Adam > > > > >> > > > > >> > > > > >> > > > > >> On 27/01/2025 11:52, Simon Peyton Jones wrote: > > > > >> > Arnaud > > > > >> > > > > > >> > OK, following my call and some further iteration, > the > > proposal is much > > > > >> > improved. See here > > > > >> > > > > <[7][10]https://github.com/ghc-proposals/ghc-proposals/pull/682>. > > Please > > > > >> read > > > > >> > the new "Proposed Change Specification" which has > had a > > large rewrite. > > > > >> > > > > > >> > I vote to accept. > > > > >> > > > > > >> > BUT there is one point that the committee must > resolve: > > *one extension > > > > >> > of two?* It's just a judgement call and I lay out > the > > choices in this > > > > >> > post > > > > >> > < > > > > >> > > > [8][11]https://github.com/ghc-proposals/ghc-proposals/pull/682#issue > comm > > ent-2609199731>. > > > > >> I doubt that we'll get much community feedback. I > suggest > > that we just > > > > >> vote. I vote for one, not two. As does Sebastian. > > > > >> > > > > > >> > Over to you Arnaud. Let's get this one done. > Matthew is > > busy > > > > >> > implementing it for a customer and it has been on > our to-do > > list for > > > > >> > some time now. (Partly my fault.) > > > > >> > > > > > >> > Simon > > > > >> > > > > > >> > On Tue, 21 Jan 2025 at 10:48, Simon Peyton Jones > > > > >> > <[9][12]simon.peytonjones at gmail.com > > > > > > > >> wrote: > > > > >> > > > > > >> > Matthew and I had a good conversation. Some > notes here > > > > >> > < > > > > >> > > > [11][14]https://docs.google.com/document/d/1dEMPIHpbN19xYZymGCxO0BpQ > R58R > > Phk5MslruY7yXD0/edit?usp=sharing > > > > >> >. > > > > >> > > > > > >> > He's going to work on a revision to the proposal > which > > I'll iterate > > > > >> > with him. > > > > >> > > > > > >> > Simon > > > > >> > > > > > >> > On Tue, 21 Jan 2025 at 07:37, Arnaud Spiwack > > > > >> > <[12][15]arnaud.spiwack at tweag.io > > > wrote: > > > > >> > > > > > >> > Then, let's wait until your call with > Matthew and > > decide how to > > > > >> > act then. > > > > >> > > > > > >> > On Tue, 21 Jan 2025 at 02:43, Simon Peyton > Jones > > > > >> > <[14][17]simon.peytonjones at gmail.com > > > > >> > > > wrote: > > > > >> > > > > > >> > Arnaud > > > > >> > > > > > >> > I have responded with a lot of feedback > on the > > Github thread > > > > >> > < > > > > >> > > > [16][19]https://github.com/ghc-proposals/ghc-proposals/pull/682#pull > requ > > estreview-2562175116 > > > > >> >. > > > > >> > > > > > >> > 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 > > > > >> > <[17][20]arnaud.spiwack at tweag.io > > > > > > > >> > wrote: > > > > >> > > > > > >> > > > > > >> > Mathew Pickering, Rodrigo Mesquita, > and our > > own Adam > > > > >> > Gundry put forward a new proposal > for the > > perenial > > > > >> > problem of dependencies and Template > > Haskell > > > > >> > > > > [19][22]https://github.com/ghc-proposals/ghc-proposals/pull/682 > > > > >> > < > > > > >> > [20][23]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 > > [21][24]https://moduscreate.com > > > > >> > <[22][25]https://moduscreate.com> > and > > [23][26]https://tweag.io > > > > >> > <[24][27]https://tweag.io>. > > > > >> > > > > >> > > > > >> -- > > > > >> Adam Gundry, Haskell Consultant > > > > >> Well-Typed LLP, [25][28]https://www.well-typed.com/ > > > > >> > > > > >> Registered in England & Wales, OC335890 > > > > >> 27 Old Gloucester Street, London WC1N 3AX, England > > > > >> > > > > >> _______________________________________________ > > > > >> ghc-steering-committee mailing list > > > > >> [26][29]ghc-steering-committee at haskell.org > > > > >> > > > [27][30]https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steeri > ng-c > > ommittee > > > > >> > > > > > _______________________________________________ > > > > > ghc-steering-committee mailing list > > > > > [28][31]ghc-steering-committee at haskell.org > > > > > > > > [29][32]https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steeri > ng-c > > ommittee > > > > > > > > > > > > > > > > > -- > > > > Arnaud Spiwack > > > > Director, Research at [30][33]https://moduscreate.com and > > [31][34]https://tweag.io. > > > > > > > > > -- > > > > > > -------------------------------------------------------------------- > > -- > > > Erik de Castro Lopo > > > [32][35]http://www.mega-nerd.com/ > > > > > > > -- > > > -------------------------------------------------------------------- > > -- > > Erik de Castro Lopo > > [33][36]http://www.mega-nerd.com/ > > _______________________________________________ > > ghc-steering-committee mailing list > > [34][37]ghc-steering-committee at haskell.org > > > [35][38]https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steeri > ng-c > > ommittee > > > > -- > > > > Arnaud Spiwack > > Director, Research at [36][39]https://moduscreate.com and > > [37][40]https://tweag.io. > > > > References > > > > 1. mailto:[41]erikd at mega-nerd.com > > 2. > [42]https://github.com/ghc-proposals/ghc-proposals/pull/682#issuecom > ment-2609199731 > > 3. > [43]https://github.com/ghc-proposals/ghc-proposals/pull/682#issuecom > ment-2609583126 > > 4. mailto:[44]simon.peytonjones at gmail.com > > 5. mailto:[45]adam at well-typed.com > > 6. > [46]https://github.com/ghc-proposals/ghc-proposals/pull/682#discussi > on_r1849123243 > > 7. [47]https://github.com/ghc-proposals/ghc-proposals/pull/682 > > 8. > [48]https://github.com/ghc-proposals/ghc-proposals/pull/682#issuecom > ment-2609199731 > > 9. mailto:[49]simon.peytonjones at gmail.com > > 10. mailto:[50]simon.peytonjones at gmail.com > > 11. > [51]https://docs.google.com/document/d/1dEMPIHpbN19xYZymGCxO0BpQR58R > Phk5MslruY7yXD0/edit?usp=sharing > > 12. mailto:[52]arnaud.spiwack at tweag.io > > 13. mailto:[53]arnaud.spiwack at tweag.io > > 14. mailto:[54]simon.peytonjones at gmail.com > > 15. mailto:[55]simon.peytonjones at gmail.com > > 16. > [56]https://github.com/ghc-proposals/ghc-proposals/pull/682#pullrequ > estreview-2562175116 > > 17. mailto:[57]arnaud.spiwack at tweag.io > > 18. mailto:[58]arnaud.spiwack at tweag.io > > 19. [59]https://github.com/ghc-proposals/ghc-proposals/pull/682 > > 20. [60]https://github.com/ghc-proposals/ghc-proposals/pull/682 > > 21. [61]https://moduscreate.com/ > > 22. [62]https://moduscreate.com/ > > 23. [63]https://tweag.io/ > > 24. [64]https://tweag.io/ > > 25. [65]https://www.well-typed.com/ > > 26. mailto:[66]ghc-steering-committee at haskell.org > > 27. > [67]https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-c > ommittee > > 28. mailto:[68]ghc-steering-committee at haskell.org > > 29. > [69]https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-c > ommittee > > 30. [70]https://moduscreate.com/ > > 31. [71]https://tweag.io/ > > 32. [72]http://www.mega-nerd.com/ > > 33. [73]http://www.mega-nerd.com/ > > 34. mailto:[74]ghc-steering-committee at haskell.org > > 35. > [75]https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-c > ommittee > > 36. [76]https://moduscreate.com/ > > 37. [77]https://tweag.io/ > > > _______________________________________________ > > ghc-steering-committee mailing list > > [78]ghc-steering-committee at haskell.org > > > [79]https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-c > ommittee > > _______________________________________________ > ghc-steering-committee mailing list > [80]ghc-steering-committee at haskell.org > [81]https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-c > ommittee > > _______________________________________________ > ghc-steering-committee mailing list > [82]ghc-steering-committee at haskell.org > [83]https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-c > ommittee > > -- > Arnaud Spiwack > Director, Research at [84]https://moduscreate.com and > [85]https://tweag.io. > > References > > 1. https://github.com/well-typed/ghc-proposals/blob/wip/level-imports-2024/proposals/0000-splice-imports.rst#syntactic-alternatives > 2. mailto:simon.peytonjones at gmail.com > 3. mailto:malte.ott at maralorn.de > 4. mailto:erikd at mega-nerd.com > 5. https://github.com/ghc-proposals/ghc-proposals/pull/682#issuecomm > 6. https://github.com/ghc-proposals/ghc-proposals/pull/682#issuecomm > 7. mailto:simon.peytonjones at gmail.com > 8. mailto:adam at well-typed.com > 9. https://github.com/ghc-proposals/ghc-proposals/pull/682#discussio > 10. https://github.com/ghc-proposals/ghc-proposals/pull/682 > 11. https://github.com/ghc-proposals/ghc-proposals/pull/682#issuecomm > 12. mailto:simon.peytonjones at gmail.com > 13. mailto:simon.peytonjones at gmail.com > 14. https://docs.google.com/document/d/1dEMPIHpbN19xYZymGCxO0BpQR58R > 15. mailto:arnaud.spiwack at tweag.io > 16. mailto:arnaud.spiwack at tweag.io > 17. mailto:simon.peytonjones at gmail.com > 18. mailto:simon.peytonjones at gmail.com > 19. https://github.com/ghc-proposals/ghc-proposals/pull/682#pullrequ > 20. mailto:arnaud.spiwack at tweag.io > 21. mailto:arnaud.spiwack at tweag.io > 22. https://github.com/ghc-proposals/ghc-proposals/pull/682 > 23. https://github.com/ghc-proposals/ghc-proposals/pull/682 > 24. https://moduscreate.com/ > 25. https://moduscreate.com/ > 26. https://tweag.io/ > 27. https://tweag.io/ > 28. https://www.well-typed.com/ > 29. mailto:ghc-steering-committee at haskell.org > 30. https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-c > 31. mailto:ghc-steering-committee at haskell.org > 32. https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-c > 33. https://moduscreate.com/ > 34. https://tweag.io/ > 35. http://www.mega-nerd.com/ > 36. http://www.mega-nerd.com/ > 37. mailto:ghc-steering-committee at haskell.org > 38. https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-c > 39. https://moduscreate.com/ > 40. https://tweag.io/ > 41. mailto:erikd at mega-nerd.com > 42. https://github.com/ghc-proposals/ghc-proposals/pull/682#issuecomment-2609199731 > 43. https://github.com/ghc-proposals/ghc-proposals/pull/682#issuecomment-2609583126 > 44. mailto:simon.peytonjones at gmail.com > 45. mailto:adam at well-typed.com > 46. https://github.com/ghc-proposals/ghc-proposals/pull/682#discussion_r1849123243 > 47. https://github.com/ghc-proposals/ghc-proposals/pull/682 > 48. https://github.com/ghc-proposals/ghc-proposals/pull/682#issuecomment-2609199731 > 49. mailto:simon.peytonjones at gmail.com > 50. mailto:simon.peytonjones at gmail.com > 51. https://docs.google.com/document/d/1dEMPIHpbN19xYZymGCxO0BpQR58RPhk5MslruY7yXD0/edit?usp=sharing > 52. mailto:arnaud.spiwack at tweag.io > 53. mailto:arnaud.spiwack at tweag.io > 54. mailto:simon.peytonjones at gmail.com > 55. mailto:simon.peytonjones at gmail.com > 56. https://github.com/ghc-proposals/ghc-proposals/pull/682#pullrequestreview-2562175116 > 57. mailto:arnaud.spiwack at tweag.io > 58. mailto:arnaud.spiwack at tweag.io > 59. https://github.com/ghc-proposals/ghc-proposals/pull/682 > 60. https://github.com/ghc-proposals/ghc-proposals/pull/682 > 61. https://moduscreate.com/ > 62. https://moduscreate.com/ > 63. https://tweag.io/ > 64. https://tweag.io/ > 65. https://www.well-typed.com/ > 66. mailto:ghc-steering-committee at haskell.org > 67. https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee > 68. mailto:ghc-steering-committee at haskell.org > 69. https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee > 70. https://moduscreate.com/ > 71. https://tweag.io/ > 72. http://www.mega-nerd.com/ > 73. http://www.mega-nerd.com/ > 74. mailto:ghc-steering-committee at haskell.org > 75. https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee > 76. https://moduscreate.com/ > 77. https://tweag.io/ > 78. mailto:ghc-steering-committee at haskell.org > 79. https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee > 80. mailto:ghc-steering-committee at haskell.org > 81. https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee > 82. mailto:ghc-steering-committee at haskell.org > 83. https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee > 84. https://moduscreate.com/ > 85. https://tweag.io/ From arnaud.spiwack at tweag.io Fri Feb 14 05:19:55 2025 From: arnaud.spiwack at tweag.io (Arnaud Spiwack) Date: Fri, 14 Feb 2025 14:19:55 +0900 Subject: [ghc-steering-committee] #682: Explicit Level Imports, recommendation: accept In-Reply-To: References: <20250205191643.60ec5f23d8b4571b8cf14ece@mega-nerd.com> <20250207100114.c0dd8b72c6dc9167a58bff43@mega-nerd.com> Message-ID: There's a little bit of a debate going on in the Github thread on the topic of syntax. I'll give this one one last push. If the authors decide that they are ok with specifying the keywords before and after the module name, then we can accept immediately, as there's no voice against this. Otherwise I'll recapitulate everybody's argument here and call for a quick vote. On Mon, 10 Feb 2025 at 15:25, Arnaud Spiwack wrote: > For the record, the syntactic alternatives can be found in [§8.5 Syntactic > alternatives]( > https://github.com/well-typed/ghc-proposals/blob/wip/level-imports-2024/proposals/0000-splice-imports.rst#syntactic-alternatives > ) > > Malte seems to be uncomfortable with the fact that the proposed syntax is > > import slice Foo > import quote Bar > > Even when ImportQualifiedPost, which enables the syntax > > import Foo qualified [as …] > > is enabled. > > The proposal offers alternative syntaxes like > > import Foo slice > Import Bar quote > > or (to sound more English) > > import Foo for slice > import Bar for quote > > Richard Eisenberg, in the thread, suggests that the motivation for > ImportQualifiedPost doesn't apply to slice/quote because he believes that > there's going to be one block of import slice, one block of import > (nothing), one block of import quote, and they aren't going to be mixed > together. Them being more visually distinguished by starting with the > keyword is an asset in this view. Many seem convinced > > My understanding of Malte's point is that this is not intuitive enough > that it can be left implicit in the proposal, and he'd like the proposal to > at least state explicitly that it ignores ImportQualifiedPost. > > Malte, let me know if I misrepresent your point of view (or anybody > else's). > > On Sat, 8 Feb 2025 at 01:19, Simon Peyton Jones < > simon.peytonjones at gmail.com> wrote: > >> I don’t think we were finished >> with bikeshedding the syntax. At least I think the proposal should state >> what >> the syntax is when ImportQualifiedPost is enabled and voiced that on the >> GitHub >> thread. >> >> >> OK -- but I suspect that most of us have lost context. >> >> Would you like to post (on the Github) a message explaining: >> >> - what the syntactic alternatives are >> - what you recommend >> >> That will help to focus the discussion >> >> Thanks! >> >> Simon >> >> >> On Fri, 7 Feb 2025 at 12:16, Malte Ott wrote: >> >>> I do not object to accepting the proposal, but I don’t think we were >>> finished >>> with bikeshedding the syntax. At least I think the proposal should state >>> what >>> the syntax is when ImportQualifiedPost is enabled and voiced that on the >>> GitHub >>> thread. >>> >>> I know we all dread wasting our time with syntax discussions but lets at >>> least >>> think about it for 5 minutes. >>> >>> Best, >>> Malte >>> >>> On 2025-02-07 15:48, Arnaud Spiwack wrote: >>> > Ok, we have enough of a quorum at this point. If everybody else >>> voted 1 >>> > extension this would come at a rough draw. It can't be a strong >>> enough >>> > push to overrule the preference of the authors. >>> > >>> > I'll give it a handful more day, say until next Wednesday 12th >>> > February. If someone has a strong objection, please voice it very >>> > loudly. Otherwise I'll declare the proposal as accepted in its >>> current >>> > state. >>> > >>> > Best, >>> > Arnaud >>> > >>> > On Fri, 7 Feb 2025 at 08:01, Erik de Castro Lopo >>> > <[1]erikd at mega-nerd.com> wrote: >>> > >>> > OK, slightly in favor of two extensions. >>> > >>> > Erik >>> > >>> > Erik de Castro Lopo wrote: >>> > >>> > > Hi, >>> > > >>> > > I have read through the proposal, but there is something I am >>> > still unsure >>> > > of. For the LANGUAGE pragma's is there any utility in using one >>> > separately >>> > > form the other? It seems there isn't. In any one file you would >>> > use either >>> > > one or the other. >>> > > >>> > > Thanks, >>> > > Erik >>> > > >>> > > Arnaud Spiwack wrote: >>> > > >>> > > > Sorry I disappeared for a while. I second Simon's call, let's >>> > vote. Let me >>> > > > repost a link to Simon's pro and cons post >>> > > > >>> > [2] >>> https://github.com/ghc-proposals/ghc-proposals/pull/682#issuecomm >>> > ent-2609199731 >>> > > > >>> > > > So far, we have the following votes >>> > > > >>> > > > - Simon: 1 extension >>> > > > - Adam: 2 extension (feels quite strongly about it) >>> > > > - Sebastian: 1 extension (on the Github thread, but I'll count >>> > it as a vote >>> > > > anyway) >>> > > > >>> > > > Eric, Moritz, Malta, Matthías, Erik, Jakob: what do you think? >>> > > > >>> > > > --- >>> > > > >>> > > > Beyond that we have a single piece of community feedback on >>> the >>> > Github >>> > > > thread. It's from Michael Peyton Jones who is in favour of 2 >>> > extensions, >>> > > > find it here >>> > > > >>> > [3] >>> https://github.com/ghc-proposals/ghc-proposals/pull/682#issuecomm >>> > ent-2609583126 >>> > > > >>> > > > --- >>> > > > >>> > > > For the record, I hadn't commented about it in my >>> > recommendation, despite >>> > > > my well-known and desperately public distaste for micro >>> > extensions. I have >>> > > > a couple of reasons: >>> > > > - I dislike micro-extensions less now that we are doing the >>> > GHC20XX (the >>> > > > last one was very modest, I'm in favour, by the way, of doing >>> a >>> > much more >>> > > > ambitious language edition soon, otherwise my distaste will >>> come >>> > back with >>> > > > a vengeance) >>> > > > - While I consider every proposal with several extensions in >>> it >>> > with >>> > > > suspicion, the authors did argue for their second extension, I >>> > found the >>> > > > argument mildly convincing, and thought it wasn't worth >>> fighting >>> > against. >>> > > > >>> > > > Now, even like this my preference is mildly for one extension. >>> > Adam says >>> > > > that it's easier to implement warnings with both the new >>> syntax >>> > on and >>> > > > implicit stage persistence left turned on, than to implement >>> > errors when >>> > > > implicit stage persistence is turned off. It may be so, but I >>> > don't think >>> > > > we can avoid implementing the errors anyway, so I don't feel >>> > that it's a >>> > > > particularly compelling argument. I don't feel strongly. But >>> > that's >>> > > > presumably where my vote goes. >>> > > > >>> > > > On Tue, 4 Feb 2025 at 07:13, Simon Peyton Jones >>> > <[4]simon.peytonjones at gmail.com> >>> > > > wrote: >>> > > > >>> > > > > Yes: all members of the steering committee, please vote. >>> > Evaluating >>> > > > > proposals is what we all signed up to do! >>> > > > > >>> > > > > Thanks >>> > > > > >>> > > > > Simon >>> > > > > >>> > > > > On Mon, 3 Feb 2025 at 20:45, Adam Gundry >>> > <[5]adam at well-typed.com> wrote: >>> > > > > >>> > > > >> I'm (unsurprisingly) in favour of acceptance, and I vote >>> for >>> > two >>> > > > >> extensions. As I commented on the GitHub thread: >>> > > > >> >>> > > > >> > We shouldn't unnecessarily conflate a syntactic >>> extension >>> > > > >> (ExplicitLevelImports) with a semantic one >>> > (NoImplicitStagePersistence) >>> > > > >> just because the common case is to want both and we want to >>> > keep the >>> > > > >> number of extensions lower. >>> > > > >> >>> > > > >> If there are reasons why having two extensions is actually >>> > problematic, >>> > > > >> I'd like to hear them. >>> > > > >> >>> > > > >> Also, at the risk of opening another avenue of discussion, >>> we >>> > also need >>> > > > >> to resolve the syntax question (see >>> > > > >> >>> > > > >> >>> > [6] >>> https://github.com/ghc-proposals/ghc-proposals/pull/682#discussio >>> > n_r1849123243). >>> > > > >> >>> > > > >> I don't have a very strong opinion here, but given that >>> some >>> > people do, >>> > > > >> perhaps we should make ImportQualifiedPost affect splice >>> > imports so we >>> > > > >> have >>> > > > >> >>> > > > >> import splice qualified A -- By default >>> > > > >> import A splice qualified -- Under ImportQualifiedPost >>> > > > >> >>> > > > >> In any case, please do vote! It would be good to get this >>> > proposal done. >>> > > > >> >>> > > > >> Cheers, >>> > > > >> >>> > > > >> Adam >>> > > > >> >>> > > > >> >>> > > > >> >>> > > > >> On 27/01/2025 11:52, Simon Peyton Jones wrote: >>> > > > >> > Arnaud >>> > > > >> > >>> > > > >> > OK, following my call and some further iteration, the >>> > proposal is much >>> > > > >> > improved. See here >>> > > > >> > >>> > <[7]https://github.com/ghc-proposals/ghc-proposals/pull/682>. >>> > Please >>> > > > >> read >>> > > > >> > the new "Proposed Change Specification" which has had a >>> > large rewrite. >>> > > > >> > >>> > > > >> > I vote to accept. >>> > > > >> > >>> > > > >> > BUT there is one point that the committee must resolve: >>> > *one extension >>> > > > >> > of two?* It's just a judgement call and I lay out the >>> > choices in this >>> > > > >> > post >>> > > > >> > < >>> > > > >> >>> > [8] >>> https://github.com/ghc-proposals/ghc-proposals/pull/682#issuecomm >>> > ent-2609199731>. >>> > > > >> I doubt that we'll get much community feedback. I suggest >>> > that we just >>> > > > >> vote. I vote for one, not two. As does Sebastian. >>> > > > >> > >>> > > > >> > Over to you Arnaud. Let's get this one done. Matthew is >>> > busy >>> > > > >> > implementing it for a customer and it has been on our >>> to-do >>> > list for >>> > > > >> > some time now. (Partly my fault.) >>> > > > >> > >>> > > > >> > Simon >>> > > > >> > >>> > > > >> > On Tue, 21 Jan 2025 at 10:48, Simon Peyton Jones >>> > > > >> > <[9]simon.peytonjones at gmail.com >>> > > >>> > > > >> wrote: >>> > > > >> > >>> > > > >> > Matthew and I had a good conversation. Some notes >>> here >>> > > > >> > < >>> > > > >> >>> > [11] >>> https://docs.google.com/document/d/1dEMPIHpbN19xYZymGCxO0BpQR58R >>> > Phk5MslruY7yXD0/edit?usp=sharing >>> > > > >> >. >>> > > > >> > >>> > > > >> > He's going to work on a revision to the proposal >>> which >>> > I'll iterate >>> > > > >> > with him. >>> > > > >> > >>> > > > >> > Simon >>> > > > >> > >>> > > > >> > On Tue, 21 Jan 2025 at 07:37, Arnaud Spiwack >>> > > > >> > <[12]arnaud.spiwack at tweag.io >>> > > wrote: >>> > > > >> > >>> > > > >> > Then, let's wait until your call with Matthew and >>> > decide how to >>> > > > >> > act then. >>> > > > >> > >>> > > > >> > On Tue, 21 Jan 2025 at 02:43, Simon Peyton Jones >>> > > > >> > <[14]simon.peytonjones at gmail.com >>> > > > >> > > wrote: >>> > > > >> > >>> > > > >> > Arnaud >>> > > > >> > >>> > > > >> > I have responded with a lot of feedback on >>> the >>> > Github thread >>> > > > >> > < >>> > > > >> >>> > [16] >>> https://github.com/ghc-proposals/ghc-proposals/pull/682#pullrequ >>> > estreview-2562175116 >>> > > > >> >. >>> > > > >> > >>> > > > >> > 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 >>> > > > >> > <[17]arnaud.spiwack at tweag.io >>> > > >>> > > > >> > wrote: >>> > > > >> > >>> > > > >> > >>> > > > >> > Mathew Pickering, Rodrigo Mesquita, and >>> our >>> > own Adam >>> > > > >> > Gundry put forward a new proposal for the >>> > perenial >>> > > > >> > problem of dependencies and Template >>> > Haskell >>> > > > >> > >>> > [19]https://github.com/ghc-proposals/ghc-proposals/pull/682 >>> > > > >> > < >>> > > > >> [20] >>> 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 >>> > [21]https://moduscreate.com >>> > > > >> > <[22]https://moduscreate.com> and >>> > [23]https://tweag.io >>> > > > >> > <[24]https://tweag.io>. >>> > > > >> >>> > > > >> >>> > > > >> -- >>> > > > >> Adam Gundry, Haskell Consultant >>> > > > >> Well-Typed LLP, [25]https://www.well-typed.com/ >>> > > > >> >>> > > > >> Registered in England & Wales, OC335890 >>> > > > >> 27 Old Gloucester Street, London WC1N 3AX, England >>> > > > >> >>> > > > >> _______________________________________________ >>> > > > >> ghc-steering-committee mailing list >>> > > > >> [26]ghc-steering-committee at haskell.org >>> > > > >> >>> > [27] >>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-c >>> > ommittee >>> > > > >> >>> > > > > _______________________________________________ >>> > > > > ghc-steering-committee mailing list >>> > > > > [28]ghc-steering-committee at haskell.org >>> > > > > >>> > [29] >>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-c >>> > ommittee >>> > > > > >>> > > > >>> > > > >>> > > > -- >>> > > > Arnaud Spiwack >>> > > > Director, Research at [30]https://moduscreate.com and >>> > [31]https://tweag.io. >>> > > >>> > > >>> > > -- >>> > > >>> > >>> -------------------------------------------------------------------- >>> > -- >>> > > Erik de Castro Lopo >>> > > [32]http://www.mega-nerd.com/ >>> > > >>> > >>> > -- >>> > >>> -------------------------------------------------------------------- >>> > -- >>> > Erik de Castro Lopo >>> > [33]http://www.mega-nerd.com/ >>> > _______________________________________________ >>> > ghc-steering-committee mailing list >>> > [34]ghc-steering-committee at haskell.org >>> > [35] >>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-c >>> > ommittee >>> > >>> > -- >>> > >>> > Arnaud Spiwack >>> > Director, Research at [36]https://moduscreate.com and >>> > [37]https://tweag.io. >>> > >>> > References >>> > >>> > 1. mailto:erikd at mega-nerd.com >>> > 2. >>> https://github.com/ghc-proposals/ghc-proposals/pull/682#issuecomment-2609199731 >>> > 3. >>> https://github.com/ghc-proposals/ghc-proposals/pull/682#issuecomment-2609583126 >>> > 4. mailto:simon.peytonjones at gmail.com >>> > 5. mailto:adam at well-typed.com >>> > 6. >>> https://github.com/ghc-proposals/ghc-proposals/pull/682#discussion_r1849123243 >>> > 7. https://github.com/ghc-proposals/ghc-proposals/pull/682 >>> > 8. >>> https://github.com/ghc-proposals/ghc-proposals/pull/682#issuecomment-2609199731 >>> > 9. mailto:simon.peytonjones at gmail.com >>> > 10. mailto:simon.peytonjones at gmail.com >>> > 11. >>> https://docs.google.com/document/d/1dEMPIHpbN19xYZymGCxO0BpQR58RPhk5MslruY7yXD0/edit?usp=sharing >>> > 12. mailto:arnaud.spiwack at tweag.io >>> > 13. mailto:arnaud.spiwack at tweag.io >>> > 14. mailto:simon.peytonjones at gmail.com >>> > 15. mailto:simon.peytonjones at gmail.com >>> > 16. >>> https://github.com/ghc-proposals/ghc-proposals/pull/682#pullrequestreview-2562175116 >>> > 17. mailto:arnaud.spiwack at tweag.io >>> > 18. mailto:arnaud.spiwack at tweag.io >>> > 19. https://github.com/ghc-proposals/ghc-proposals/pull/682 >>> > 20. https://github.com/ghc-proposals/ghc-proposals/pull/682 >>> > 21. https://moduscreate.com/ >>> > 22. https://moduscreate.com/ >>> > 23. https://tweag.io/ >>> > 24. https://tweag.io/ >>> > 25. https://www.well-typed.com/ >>> > 26. mailto:ghc-steering-committee at haskell.org >>> > 27. >>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee >>> > 28. mailto:ghc-steering-committee at haskell.org >>> > 29. >>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee >>> > 30. https://moduscreate.com/ >>> > 31. https://tweag.io/ >>> > 32. http://www.mega-nerd.com/ >>> > 33. http://www.mega-nerd.com/ >>> > 34. mailto:ghc-steering-committee at haskell.org >>> > 35. >>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee >>> > 36. https://moduscreate.com/ >>> > 37. 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 >>> >>> _______________________________________________ >>> 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 >> > > > -- > 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 sgraf1337 at gmail.com Mon Feb 17 08:40:00 2025 From: sgraf1337 at gmail.com (Sebastian Graf) Date: Mon, 17 Feb 2025 09:40:00 +0100 Subject: [ghc-steering-committee] #621: Linear constraints, recommendation: accept In-Reply-To: References: Message-ID: After multiple lengthy discussions that brought forth examples that IMO better motivate the proposal, I retract my earlier vote. However, since there are multiple points of design disagreement between Arnaud and me, I cannot vote in favour of acceptance either and will abstain from voting. Cheers, Sebastian Am Mo., 20. Jan. 2025 um 10:22 Uhr schrieb Sebastian Graf < sgraf1337 at gmail.com>: > 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: