From mail at joachim-breitner.de Fri Dec 2 11:06:26 2022 From: mail at joachim-breitner.de (Joachim Breitner) Date: Fri, 02 Dec 2022 12:06:26 +0100 Subject: [ghc-steering-committee] Why not?, rather than, why? Message-ID: Hello Committee and Community, occasionally we have meta-discussions about GHC language extensions: Should they be allowed to be fork-like, where some extensions are unlikely to be used together and some stay opt-in forever? Or should (ideally) every extension be on track to become on-by-default. Of course there are a few “old” extensions that by their very nature are not suitable to be on by default (SAFE, TRUSTWORTHY and CPP are the obvious candidates). Let’s put them aside for this discussion. I’d wager that if we’d introduce them these days, they wouldn’t be language extensions in the first place, but maybe modifiers on the module. I am mostly in the camp “every extension should be on track to become default (or be discarded)”. Once a language feature has been proven useful and reasonable stable, I see little value in requiring programmers to jump through hoops to use them. Is that the prevalent view here as well, or do we have a strong camp saying that our current “pick-and-choose” approach to language features is actually a good thing in its own (and not just a necessary nuisance)? If we assume the former, then maybe it would be worth to frame the discussion around new language extensions, and the discussion about which language extensions become default, around that vision. Concretely: * A new language proposal should not just be good enough for “worth  building for those who explicitly turn it on”, but really ought convince as “this will make Haskell better for all” (and not just “a Haskell”). * Most new language features should probably not on by default  initially, as usual, and are initially experimental. But then the proposal, and if accepted the documentation of the extension, should as explicit as possible explain why it is not yet default: What needs to happen for _this_ extension to be considered ready – or judged negatively and put on a track towards removal. This could be something like “been available for n releases, been stable for m releases”. (I wonder what other kind of criteria to expect here?) * The process for defining GHC20xx would then become very different: We’d go through all experimental extensions, check if the criteria are satisfied, maybe apply some common sense if the criteria are  still good ones, and turn it on if so. This may turn the process to be more structured and maybe more predictable, and hopefully reduces the number of non-default extensions developers have to make a decision about (probably good). But it does raise the bar for new language features (is that good?). And, if applied consequently, it suggests to deprecate and eventually remove extensions that turn out to not be default-worthy after all (that’s kinda harsh)? As you can see I am a bit unsure about what the criteria are that we could put in the docs. Are they really different for different extensions? But the fact that its hard to come up right now with a concrete reason why extension X is not yet the default does point to a hole in our thinking and our process! And it is the same question that we face when discussing GHC20xx. So I guess what I am proposing here is: Have that discussion (when is it ready?) already when accepting a proposal, and document it in clear sight for our users, rather than have it over and over when debating GHC20xx. This is not a concrete (meta-)proposal, but hopefully tasty food for thought. Cheers, Joachim -- Joachim Breitner mail at joachim-breitner.de http://www.joachim-breitner.de/ From arnaud.spiwack at tweag.io Fri Dec 2 15:06:03 2022 From: arnaud.spiwack at tweag.io (Arnaud Spiwack) Date: Fri, 2 Dec 2022 16:06:03 +0100 Subject: [ghc-steering-committee] Why not?, rather than, why? In-Reply-To: References: Message-ID: I believe that I've been vocal in the past about my view that extensions should eventually become on by default. And even about the fact that I struggle to understand the point of view of extensions as configuration switches. I have no idea, however, how numerous each side of this debate is, nor how strongly the beliefs are held (very strongly in my case, obviously, but I don't know for others). I think that you're right, Joachim, and that it's time to make a definite decision about that and make the decision one of our Principles. If we come to the side that extensions are to eventually become defaults, I agree that the question of how to deprecate extensions that will never make it to the default is something that we have to tackle. A slightly more difficult discussion is how do we deprecate things that used to be the default. Imagine, say, that we want to make `-XMonoLocalBinds` the default, `-XMonoLocalBinds` is really removing a feature (as such it should probably be named something like `-XNoGeneralizeLocaBinds`), what does the deprecation period look like? Maybe it's actually the same question as deprecating a non-default extension, but maybe not. On Fri, 2 Dec 2022 at 12:07, Joachim Breitner wrote: > Hello Committee and Community, > > occasionally we have meta-discussions about GHC language extensions: > Should they be allowed to be fork-like, where some extensions are > unlikely to be used together and some stay opt-in forever? Or should > (ideally) every extension be on track to become on-by-default. > > Of course there are a few “old” extensions that by their very nature > are not suitable to be on by default (SAFE, TRUSTWORTHY and CPP are the > obvious candidates). Let’s put them aside for this discussion. I’d > wager that if we’d introduce them these days, they wouldn’t be language > extensions in the first place, but maybe modifiers on the module. > > I am mostly in the camp “every extension should be on track to become > default (or be discarded)”. Once a language feature has been proven > useful and reasonable stable, I see little value in requiring > programmers to jump through hoops to use them. > > Is that the prevalent view here as well, or do we have a strong camp > saying that our current “pick-and-choose” approach to language features > is actually a good thing in its own (and not just a necessary > nuisance)? > > If we assume the former, then maybe it would be worth to frame the > discussion around new language extensions, and the discussion about > which language extensions become default, around that vision. > Concretely: > > * A new language proposal should not just be good enough for “worth > building for those who explicitly turn it on”, but really ought > convince as “this will make Haskell better for all” (and not just > “a Haskell”). > > * Most new language features should probably not on by default > initially, as usual, and are initially experimental. But then the > proposal, and if accepted the documentation of the extension, should > as explicit as possible explain why it is not yet default: What > needs to happen for _this_ extension to be considered ready – or > judged negatively and put on a track towards removal. > > This could be something like “been available for n releases, been > stable for m releases”. (I wonder what other kind of criteria to > expect here?) > > * The process for defining GHC20xx would then become very different: > We’d go through all experimental extensions, check if the criteria > are satisfied, maybe apply some common sense if the criteria are > still good ones, and turn it on if so. > > This may turn the process to be more structured and maybe more > predictable, and hopefully reduces the number of non-default extensions > developers have to make a decision about (probably good). > But it does raise the bar for new language features (is that good?). > And, if applied consequently, it suggests to deprecate and eventually > remove extensions that turn out to not be default-worthy after all > (that’s kinda harsh)? > > As you can see I am a bit unsure about what the criteria are that we > could put in the docs. Are they really different for different > extensions? But the fact that its hard to come up right now with a > concrete reason why extension X is not yet the default does point to a > hole in our thinking and our process! > > And it is the same question that we face when discussing GHC20xx. So I > guess what I am proposing here is: Have that discussion (when is it > ready?) already when accepting a proposal, and document it in clear > sight for our users, rather than have it over and over when debating > GHC20xx. > > This is not a concrete (meta-)proposal, but hopefully tasty food for > thought. > > Cheers, > Joachim > > > > > -- > Joachim Breitner > mail at joachim-breitner.de > http://www.joachim-breitner.de/ > > _______________________________________________ > ghc-steering-committee mailing list > ghc-steering-committee at haskell.org > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee > -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.peytonjones at gmail.com Fri Dec 2 16:03:54 2022 From: simon.peytonjones at gmail.com (Simon Peyton Jones) Date: Fri, 2 Dec 2022 16:03:54 +0000 Subject: [ghc-steering-committee] Why not?, rather than, why? In-Reply-To: References: Message-ID: > > I think that you're right, Joachim, and that it's time to make a definite > decision about that and make the decision one of our Principles. > I'm not sure we can make it completely black and white. Punning is an example. Some people Really Want to use punning (have a data type and a data constructor with the same name). Others Really Do Not Want punning because they want to do lots of dependently typed programing. They don't-want it so much that they want warnings if they accidentally use it. (Simply refraining from punning is not enough for them.) Neither group is wrong... it's simply a stylistic choice. But if we solidly adopt one choice or the other, we are privileging one group over the other, which to me seems like risking unnecessary conflict, one that could absorb precious cycles we could more profitably spend elsewhere. Simon On Fri, 2 Dec 2022 at 15:06, Arnaud Spiwack wrote: > I believe that I've been vocal in the past about my view that extensions > should eventually become on by default. And even about the fact that I > struggle to understand the point of view of extensions as configuration > switches. I have no idea, however, how numerous each side of this debate > is, nor how strongly the beliefs are held (very strongly in my case, > obviously, but I don't know for others). > > I think that you're right, Joachim, and that it's time to make a definite > decision about that and make the decision one of our Principles. > > If we come to the side that extensions are to eventually become defaults, > I agree that the question of how to deprecate extensions that will never > make it to the default is something that we have to tackle. A slightly more > difficult discussion is how do we deprecate things that used to be the > default. Imagine, say, that we want to make `-XMonoLocalBinds` the default, > `-XMonoLocalBinds` is really removing a feature (as such it should probably > be named something like `-XNoGeneralizeLocaBinds`), what does the > deprecation period look like? Maybe it's actually the same question as > deprecating a non-default extension, but maybe not. > > On Fri, 2 Dec 2022 at 12:07, Joachim Breitner > wrote: > >> Hello Committee and Community, >> >> occasionally we have meta-discussions about GHC language extensions: >> Should they be allowed to be fork-like, where some extensions are >> unlikely to be used together and some stay opt-in forever? Or should >> (ideally) every extension be on track to become on-by-default. >> >> Of course there are a few “old” extensions that by their very nature >> are not suitable to be on by default (SAFE, TRUSTWORTHY and CPP are the >> obvious candidates). Let’s put them aside for this discussion. I’d >> wager that if we’d introduce them these days, they wouldn’t be language >> extensions in the first place, but maybe modifiers on the module. >> >> I am mostly in the camp “every extension should be on track to become >> default (or be discarded)”. Once a language feature has been proven >> useful and reasonable stable, I see little value in requiring >> programmers to jump through hoops to use them. >> >> Is that the prevalent view here as well, or do we have a strong camp >> saying that our current “pick-and-choose” approach to language features >> is actually a good thing in its own (and not just a necessary >> nuisance)? >> >> If we assume the former, then maybe it would be worth to frame the >> discussion around new language extensions, and the discussion about >> which language extensions become default, around that vision. >> Concretely: >> >> * A new language proposal should not just be good enough for “worth >> building for those who explicitly turn it on”, but really ought >> convince as “this will make Haskell better for all” (and not just >> “a Haskell”). >> >> * Most new language features should probably not on by default >> initially, as usual, and are initially experimental. But then the >> proposal, and if accepted the documentation of the extension, should >> as explicit as possible explain why it is not yet default: What >> needs to happen for _this_ extension to be considered ready – or >> judged negatively and put on a track towards removal. >> >> This could be something like “been available for n releases, been >> stable for m releases”. (I wonder what other kind of criteria to >> expect here?) >> >> * The process for defining GHC20xx would then become very different: >> We’d go through all experimental extensions, check if the criteria >> are satisfied, maybe apply some common sense if the criteria are >> still good ones, and turn it on if so. >> >> This may turn the process to be more structured and maybe more >> predictable, and hopefully reduces the number of non-default extensions >> developers have to make a decision about (probably good). >> But it does raise the bar for new language features (is that good?). >> And, if applied consequently, it suggests to deprecate and eventually >> remove extensions that turn out to not be default-worthy after all >> (that’s kinda harsh)? >> >> As you can see I am a bit unsure about what the criteria are that we >> could put in the docs. Are they really different for different >> extensions? But the fact that its hard to come up right now with a >> concrete reason why extension X is not yet the default does point to a >> hole in our thinking and our process! >> >> And it is the same question that we face when discussing GHC20xx. So I >> guess what I am proposing here is: Have that discussion (when is it >> ready?) already when accepting a proposal, and document it in clear >> sight for our users, rather than have it over and over when debating >> GHC20xx. >> >> This is not a concrete (meta-)proposal, but hopefully tasty food for >> thought. >> >> Cheers, >> Joachim >> >> >> >> >> -- >> Joachim Breitner >> mail at joachim-breitner.de >> http://www.joachim-breitner.de/ >> >> _______________________________________________ >> 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 mail at joachim-breitner.de Fri Dec 2 16:39:49 2022 From: mail at joachim-breitner.de (Joachim Breitner) Date: Fri, 02 Dec 2022 17:39:49 +0100 Subject: [ghc-steering-committee] Why not?, rather than, why? In-Reply-To: References: Message-ID: <1d33645d4c2776317990065531a38550703e2186.camel@joachim-breitner.de> Hi, Am Freitag, dem 02.12.2022 um 16:03 +0000 schrieb Simon Peyton Jones: > > Neither group is wrong... it's simply a stylistic choice.  But if we > solidly adopt one choice or the other, we are privileging one group > over the other, which to me seems like risking unnecessary conflict, > one that could absorb precious cycles we could more profitably spend > elsewhere. but that amounts to saying that our vision for GHC is to support multiple languages, and not just by saying “some still experimental features are opt-in”, but really “There are different Haskell-like source languages you can choose from”. That is a justifiable stance! But it is a stance that’s incompatible with “we want there to be one Haskell language” (surely with different programming styles, but still one default stable language). And I believe it would be good to gain more clarity here. For example, if we’d go that route (which I am not fully opposed to, either!), I could imagine embracing it even more, and paying more attention to which language extensions are * module-local (i.e. define locally a new language syntax, but don’t affect the interface between modules), and which * cross the module boundary. Most syntactic gadgets (UnicodeSyntax, Punning) are of the former, most type system change (ExistentialTypes…) are of the latter. The former we can be much more liberal if we embrace the idea of that every programmer can have their own preferred dialect to write their Haskell code in, as they still participate in the wider ecosystem of existing Haskell code. To the extent that I would humor a proposal of LispyHaskell that proposes a completely new syntax with lots of parentheses, as long as it still behaves the same on the module boundary! Maybe an extreme example, but why not? (Is it too dangerous to call the two stances towards dialects the French and the German approach? :-)) Cheers, Joachim -- Joachim Breitner mail at joachim-breitner.de http://www.joachim-breitner.de/ From marlowsd at gmail.com Fri Dec 2 16:43:27 2022 From: marlowsd at gmail.com (Simon Marlow) Date: Fri, 2 Dec 2022 16:43:27 +0000 Subject: [ghc-steering-committee] Why not?, rather than, why? In-Reply-To: References: Message-ID: I also think I've been pretty vocal in the past about favouring the view that extensions should be on a path to being on by default - indeed in the language standard, if we ever have another one of those. Taking this approach more literally than we do would lead to difficult choices. Choices that penalise sections of the community with particular preferences. However, *not* making those choices penalises the whole community, perhaps not as visibly: more choices leads to a greater cognitive load, a longer learning curve, a greater barrier to entry off of which many potential users will bounce. And for us compiler developers, more alternatives and combinations to consider and test for, with more surprising emergent behaviours, more bugs and more work to do. In my view, if we want greater adoption we have to be opinionated: make difficult decisions that remove choices and streamline the language. At the very least, don't add more choices. But to Joachim's specific question: yes I like the idea of considering the "when will it be ready?" question for each extension, to precompute the input to the GHC20xx process. Cheers Simon On Fri, 2 Dec 2022 at 15:06, Arnaud Spiwack wrote: > I believe that I've been vocal in the past about my view that extensions > should eventually become on by default. And even about the fact that I > struggle to understand the point of view of extensions as configuration > switches. I have no idea, however, how numerous each side of this debate > is, nor how strongly the beliefs are held (very strongly in my case, > obviously, but I don't know for others). > > I think that you're right, Joachim, and that it's time to make a definite > decision about that and make the decision one of our Principles. > > If we come to the side that extensions are to eventually become defaults, > I agree that the question of how to deprecate extensions that will never > make it to the default is something that we have to tackle. A slightly more > difficult discussion is how do we deprecate things that used to be the > default. Imagine, say, that we want to make `-XMonoLocalBinds` the default, > `-XMonoLocalBinds` is really removing a feature (as such it should probably > be named something like `-XNoGeneralizeLocaBinds`), what does the > deprecation period look like? Maybe it's actually the same question as > deprecating a non-default extension, but maybe not. > > On Fri, 2 Dec 2022 at 12:07, Joachim Breitner > wrote: > >> Hello Committee and Community, >> >> occasionally we have meta-discussions about GHC language extensions: >> Should they be allowed to be fork-like, where some extensions are >> unlikely to be used together and some stay opt-in forever? Or should >> (ideally) every extension be on track to become on-by-default. >> >> Of course there are a few “old” extensions that by their very nature >> are not suitable to be on by default (SAFE, TRUSTWORTHY and CPP are the >> obvious candidates). Let’s put them aside for this discussion. I’d >> wager that if we’d introduce them these days, they wouldn’t be language >> extensions in the first place, but maybe modifiers on the module. >> >> I am mostly in the camp “every extension should be on track to become >> default (or be discarded)”. Once a language feature has been proven >> useful and reasonable stable, I see little value in requiring >> programmers to jump through hoops to use them. >> >> Is that the prevalent view here as well, or do we have a strong camp >> saying that our current “pick-and-choose” approach to language features >> is actually a good thing in its own (and not just a necessary >> nuisance)? >> >> If we assume the former, then maybe it would be worth to frame the >> discussion around new language extensions, and the discussion about >> which language extensions become default, around that vision. >> Concretely: >> >> * A new language proposal should not just be good enough for “worth >> building for those who explicitly turn it on”, but really ought >> convince as “this will make Haskell better for all” (and not just >> “a Haskell”). >> >> * Most new language features should probably not on by default >> initially, as usual, and are initially experimental. But then the >> proposal, and if accepted the documentation of the extension, should >> as explicit as possible explain why it is not yet default: What >> needs to happen for _this_ extension to be considered ready – or >> judged negatively and put on a track towards removal. >> >> This could be something like “been available for n releases, been >> stable for m releases”. (I wonder what other kind of criteria to >> expect here?) >> >> * The process for defining GHC20xx would then become very different: >> We’d go through all experimental extensions, check if the criteria >> are satisfied, maybe apply some common sense if the criteria are >> still good ones, and turn it on if so. >> >> This may turn the process to be more structured and maybe more >> predictable, and hopefully reduces the number of non-default extensions >> developers have to make a decision about (probably good). >> But it does raise the bar for new language features (is that good?). >> And, if applied consequently, it suggests to deprecate and eventually >> remove extensions that turn out to not be default-worthy after all >> (that’s kinda harsh)? >> >> As you can see I am a bit unsure about what the criteria are that we >> could put in the docs. Are they really different for different >> extensions? But the fact that its hard to come up right now with a >> concrete reason why extension X is not yet the default does point to a >> hole in our thinking and our process! >> >> And it is the same question that we face when discussing GHC20xx. So I >> guess what I am proposing here is: Have that discussion (when is it >> ready?) already when accepting a proposal, and document it in clear >> sight for our users, rather than have it over and over when debating >> GHC20xx. >> >> This is not a concrete (meta-)proposal, but hopefully tasty food for >> thought. >> >> Cheers, >> Joachim >> >> >> >> >> -- >> Joachim Breitner >> mail at joachim-breitner.de >> http://www.joachim-breitner.de/ >> >> _______________________________________________ >> 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 chris at chrisdornan.com Fri Dec 2 17:27:05 2022 From: chris at chrisdornan.com (Chris Dornan) Date: Fri, 2 Dec 2022 17:27:05 +0000 Subject: [ghc-steering-committee] Why not?, rather than, why? In-Reply-To: References: Message-ID: While I can see the value of expecting proposed extensions to finally be always on I am skeptical that we will be able to just force the community to accept that each extensions is going to be either binned or always on. It doesn’t, for me, fit with the history of Haskell and GHC being an open platform that encourages experimentation. (I don’t want to sideline the discussion by offering examples but I am sure we can all think of extensions in the gray zone that we like to break out on occasion or use extensively that would be contentious candidates for permanent enablement.) I am sympathetic to the idea of a new language standard that we promote heavily and encourage developers, tools, tutorials and courseware to favour —if we get this right then we will reap the benefits of a strong standard. But if we take it upon ourselves to try and force an extension combination of our choosing on the community because we believe the community will benefit from a big reset then I think it could blow up on us really badly, with forks and factions which could be truly difficult to manage — and fatally discourage adoption. Chris > On 2 Dec 2022, at 16:43, Simon Marlow wrote: > > I also think I've been pretty vocal in the past about favouring the view that extensions should be on a path to being on by default - indeed in the language standard, if we ever have another one of those. > > Taking this approach more literally than we do would lead to difficult choices. Choices that penalise sections of the community with particular preferences. However, *not* making those choices penalises the whole community, perhaps not as visibly: more choices leads to a greater cognitive load, a longer learning curve, a greater barrier to entry off of which many potential users will bounce. And for us compiler developers, more alternatives and combinations to consider and test for, with more surprising emergent behaviours, more bugs and more work to do. > > In my view, if we want greater adoption we have to be opinionated: make difficult decisions that remove choices and streamline the language. At the very least, don't add more choices. > > But to Joachim's specific question: yes I like the idea of considering the "when will it be ready?" question for each extension, to precompute the input to the GHC20xx process. > > Cheers > Simon > > On Fri, 2 Dec 2022 at 15:06, Arnaud Spiwack > wrote: > I believe that I've been vocal in the past about my view that extensions should eventually become on by default. And even about the fact that I struggle to understand the point of view of extensions as configuration switches. I have no idea, however, how numerous each side of this debate is, nor how strongly the beliefs are held (very strongly in my case, obviously, but I don't know for others). > > I think that you're right, Joachim, and that it's time to make a definite decision about that and make the decision one of our Principles. > > If we come to the side that extensions are to eventually become defaults, I agree that the question of how to deprecate extensions that will never make it to the default is something that we have to tackle. A slightly more difficult discussion is how do we deprecate things that used to be the default. Imagine, say, that we want to make `-XMonoLocalBinds` the default, `-XMonoLocalBinds` is really removing a feature (as such it should probably be named something like `-XNoGeneralizeLocaBinds`), what does the deprecation period look like? Maybe it's actually the same question as deprecating a non-default extension, but maybe not. > > On Fri, 2 Dec 2022 at 12:07, Joachim Breitner > wrote: > Hello Committee and Community, > > occasionally we have meta-discussions about GHC language extensions: > Should they be allowed to be fork-like, where some extensions are > unlikely to be used together and some stay opt-in forever? Or should > (ideally) every extension be on track to become on-by-default. > > Of course there are a few “old” extensions that by their very nature > are not suitable to be on by default (SAFE, TRUSTWORTHY and CPP are the > obvious candidates). Let’s put them aside for this discussion. I’d > wager that if we’d introduce them these days, they wouldn’t be language > extensions in the first place, but maybe modifiers on the module. > > I am mostly in the camp “every extension should be on track to become > default (or be discarded)”. Once a language feature has been proven > useful and reasonable stable, I see little value in requiring > programmers to jump through hoops to use them. > > Is that the prevalent view here as well, or do we have a strong camp > saying that our current “pick-and-choose” approach to language features > is actually a good thing in its own (and not just a necessary > nuisance)? > > If we assume the former, then maybe it would be worth to frame the > discussion around new language extensions, and the discussion about > which language extensions become default, around that vision. > Concretely: > > * A new language proposal should not just be good enough for “worth > building for those who explicitly turn it on”, but really ought > convince as “this will make Haskell better for all” (and not just > “a Haskell”). > > * Most new language features should probably not on by default > initially, as usual, and are initially experimental. But then the > proposal, and if accepted the documentation of the extension, should > as explicit as possible explain why it is not yet default: What > needs to happen for _this_ extension to be considered ready – or > judged negatively and put on a track towards removal. > > This could be something like “been available for n releases, been > stable for m releases”. (I wonder what other kind of criteria to > expect here?) > > * The process for defining GHC20xx would then become very different: > We’d go through all experimental extensions, check if the criteria > are satisfied, maybe apply some common sense if the criteria are > still good ones, and turn it on if so. > > This may turn the process to be more structured and maybe more > predictable, and hopefully reduces the number of non-default extensions > developers have to make a decision about (probably good). > But it does raise the bar for new language features (is that good?). > And, if applied consequently, it suggests to deprecate and eventually > remove extensions that turn out to not be default-worthy after all > (that’s kinda harsh)? > > As you can see I am a bit unsure about what the criteria are that we > could put in the docs. Are they really different for different > extensions? But the fact that its hard to come up right now with a > concrete reason why extension X is not yet the default does point to a > hole in our thinking and our process! > > And it is the same question that we face when discussing GHC20xx. So I > guess what I am proposing here is: Have that discussion (when is it > ready?) already when accepting a proposal, and document it in clear > sight for our users, rather than have it over and over when debating > GHC20xx. > > This is not a concrete (meta-)proposal, but hopefully tasty food for > thought. > > Cheers, > Joachim > > > > > -- > Joachim Breitner > mail at joachim-breitner.de > http://www.joachim-breitner.de/ > > _______________________________________________ > 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From mail at joachim-breitner.de Fri Dec 2 17:39:42 2022 From: mail at joachim-breitner.de (Joachim Breitner) Date: Fri, 02 Dec 2022 18:39:42 +0100 Subject: [ghc-steering-committee] Why not?, rather than, why? In-Reply-To: References: Message-ID: Hi, Am Freitag, dem 02.12.2022 um 17:27 +0000 schrieb Chris Dornan: > I am sympathetic to the idea of a new language standard that we > promote heavily and encourage developers, tools, tutorials and > courseware to favour —if we get this right then we will reap the > benefits of a strong standard. But if we take it upon ourselves to > try and force an extension combination of our choosing on the > community because we believe the community will benefit from a big > reset then I think it could blow up on us really badly, with forks > and factions which could be truly difficult to manage — and fatally > discourage adoption. ah, sorry if I was unclear. I am certainly not proposing a form of “big reset”! It’s more about “should every language extension be in principle on track towards in inclusion to a future GHC20xx” – still all incremental and cautious. Cheers, Joachim -- Joachim Breitner mail at joachim-breitner.de http://www.joachim-breitner.de/ From chris at chrisdornan.com Fri Dec 2 19:04:06 2022 From: chris at chrisdornan.com (Chris Dornan) Date: Fri, 2 Dec 2022 19:04:06 +0000 Subject: [ghc-steering-committee] Why not?, rather than, why? In-Reply-To: References: Message-ID: <10594AD6-665D-4674-8E96-78AB6C61973A@chrisdornan.com> I think we are on the same page, but the thread seemed to be taking an authoritarian turn so I thought it best to ensure the voices of caution were represented! Chris > On 2 Dec 2022, at 17:39, Joachim Breitner wrote: > > Hi, > > Am Freitag, dem 02.12.2022 um 17:27 +0000 schrieb Chris Dornan: >> I am sympathetic to the idea of a new language standard that we >> promote heavily and encourage developers, tools, tutorials and >> courseware to favour —if we get this right then we will reap the >> benefits of a strong standard. But if we take it upon ourselves to >> try and force an extension combination of our choosing on the >> community because we believe the community will benefit from a big >> reset then I think it could blow up on us really badly, with forks >> and factions which could be truly difficult to manage — and fatally >> discourage adoption. > > ah, sorry if I was unclear. I am certainly not proposing a form of “big > reset”! It’s more about “should every language extension be in > principle on track towards in inclusion to a future GHC20xx” – still > all incremental and cautious. > > Cheers, > Joachim > > -- > Joachim Breitner > mail at joachim-breitner.de > http://www.joachim-breitner.de/ > > _______________________________________________ > ghc-steering-committee mailing list > ghc-steering-committee at haskell.org > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee From chris at chrisdornan.com Mon Dec 5 18:32:49 2022 From: chris at chrisdornan.com (Chris Dornan) Date: Mon, 5 Dec 2022 18:32:49 +0000 Subject: [ghc-steering-committee] Proposal #270: Support pun-free code. Recommendation: accept Message-ID: <5D0E3610-C73F-4850-9435-8D22069382BD@chrisdornan.com> Hi all, I have been assigned to shepherd 'Proposal #270: Support pun-free code’ and this is my second attempt to reach a conclusion (see below for for my original encapsulation of the proposal). As I said, my outstanding concern was that some could see this proposal as a green-lighting a general move against the use of these puns in general Haskell code as ‘bad style. The author has now clarified in the proposal that it should not be seen in this light. Unless anyone has any outstanding objections I suggest the we accept the proposal — or at least hold an up-and-down vote to resolve whether we are going to accept the proposal or not. I vote yes to accepting this proposal. Chris — My original summary: Proposal text: https://github.com/hithroc/ghc-proposals/blob/master/proposals/0000-support-pun-free-code.md Proposal discussion: https://github.com/ghc-proposals/ghc-proposals/pull/270 The proposal helps manage @data T = T@ style definitions that use the same name for type and data constructors. It introduces -Wpuns and -Wpun-bind to warn about puns at usage and binding sites, respectively, and adds qualified import syntax for importing selectively into the data and type name spaces: import Data.Proxy type qualified as T -- import only the type namespace import Data.Proxy data qualified as D -- import only the data namespace As the low number indicates the proposal has been around for a while and the author has an implementation PR: https://gitlab.haskell.org/ghc/ghc/-/merge_requests/2044 . The most active discussion point was Simon’s observation that this extension introduces a ‘fork’ in the language: https://github.com/ghc-proposals/ghc-proposals/pull/270#issuecomment-536115565 . (See Simon’s comment at the link for an explanation of the Haskell language fork idea.) There is a long tradition of using data/type constructor puns (older than Haskell itself) and many people will consider it good style (I certainly do), while others do not, and they will benefit from tools to help manage and limit their use. So, notwithstanding the fork-like nature of the proposal, because it is not very intrusive (some warnings with finer control of qualified imports), and it is helping folks to establish a subset that they are maintaining anyway, I am minded to accept this proposal — though it was close. My sole concern is that it could give rise to contentious pressure on the wider Haskell community to embrace the subset. To (avoiding) this end, I suggest that we include wording in the user guide section documenting this extension to the effect that there is no consensus on the desirability or otherwise of the punful code the extension seeks to address. -------------- next part -------------- An HTML attachment was scrubbed... URL: From marlowsd at gmail.com Mon Dec 5 19:03:49 2022 From: marlowsd at gmail.com (Simon Marlow) Date: Mon, 5 Dec 2022 19:03:49 +0000 Subject: [ghc-steering-committee] Why not?, rather than, why? In-Reply-To: <10594AD6-665D-4674-8E96-78AB6C61973A@chrisdornan.com> References: <10594AD6-665D-4674-8E96-78AB6C61973A@chrisdornan.com> Message-ID: Apologies, I didn't mean to sound like I wanted us to be "authoritarian", perhaps more along the lines of "opinionated". By analogy with the CLC: they are forced to make decisions, because there is only one set of core libraries. I don't necessarily agree with all the decisions that the CLC makes, but I'm very glad we only have one set of core libraries. In GHC we have the dubious luxury of being able to give people optional language features, I'm suggesting we should use this very carefully and avoid forks - which is our current policy anyway - but to be more intentional about it in the way that Joachim suggested. I'm also a fan of an open platform that encourages experimentation, but at some point we have to accept (I believe) that too much of this leads to a poor experience for new users. (that's putting it gently! I'm itching to rant about this some more, but I fear it may come across poorly. One for the pub.) Cheers Simon On Fri, 2 Dec 2022 at 19:04, Chris Dornan wrote: > I think we are on the same page, but the thread seemed to be taking an > authoritarian turn so I thought it best to ensure the voices of caution > were represented! > > Chris > > > On 2 Dec 2022, at 17:39, Joachim Breitner > wrote: > > > > Hi, > > > > Am Freitag, dem 02.12.2022 um 17:27 +0000 schrieb Chris Dornan: > >> I am sympathetic to the idea of a new language standard that we > >> promote heavily and encourage developers, tools, tutorials and > >> courseware to favour —if we get this right then we will reap the > >> benefits of a strong standard. But if we take it upon ourselves to > >> try and force an extension combination of our choosing on the > >> community because we believe the community will benefit from a big > >> reset then I think it could blow up on us really badly, with forks > >> and factions which could be truly difficult to manage — and fatally > >> discourage adoption. > > > > ah, sorry if I was unclear. I am certainly not proposing a form of “big > > reset”! It’s more about “should every language extension be in > > principle on track towards in inclusion to a future GHC20xx” – still > > all incremental and cautious. > > > > Cheers, > > Joachim > > > > -- > > Joachim Breitner > > mail at joachim-breitner.de > > http://www.joachim-breitner.de/ > > > > _______________________________________________ > > 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 simon.peytonjones at gmail.com Mon Dec 5 20:13:56 2022 From: simon.peytonjones at gmail.com (Simon Peyton Jones) Date: Mon, 5 Dec 2022 20:13:56 +0000 Subject: [ghc-steering-committee] Proposal #270: Support pun-free code. Recommendation: accept In-Reply-To: <5D0E3610-C73F-4850-9435-8D22069382BD@chrisdornan.com> References: <5D0E3610-C73F-4850-9435-8D22069382BD@chrisdornan.com> Message-ID: I'm in support. I'm supporting this proposal so that Haskell can be a friendly home both for those who like punning and those who don't. I'm not taking a position on which is "better", but I don't want to stand in the way of those who do have a view and want to write in that style. Simon On Mon, 5 Dec 2022 at 18:33, Chris Dornan wrote: > Hi all, > > I have been assigned to shepherd 'Proposal #270: Support pun-free code’ > and this is my second attempt to reach a conclusion (see below for for my > original encapsulation of the proposal). > > As I said, my outstanding concern was that some could see this proposal as > a green-lighting a general move against the use of these puns in general > Haskell code as ‘bad style. The author has now clarified in the proposal > that it should not be seen in this light. > > Unless anyone has any outstanding objections I suggest the we accept the > proposal — or at least hold an up-and-down vote to resolve whether we are > going to accept the proposal or not. > > I vote yes to accepting this proposal. > > Chris > > — > > My original summary: > > Proposal text: > https://github.com/hithroc/ghc-proposals/blob/master/proposals/0000-support-pun-free-code.md > > Proposal discussion: > https://github.com/ghc-proposals/ghc-proposals/pull/270 > > The proposal helps manage @data T = T@ style definitions that use the > same name for type and data constructors. > > It introduces -Wpuns and -Wpun-bind to warn about puns at usage and > binding sites, respectively, and adds qualified import syntax for importing > selectively into the data and type name spaces: > > import Data.Proxy type qualified as T -- import only the type namespace > import Data.Proxy data qualified as D -- import only the data namespace > > As the low number indicates the proposal has been around for a while and > the author has an implementation PR: > https://gitlab.haskell.org/ghc/ghc/-/merge_requests/2044. > > The most active discussion point was Simon’s observation that this > extension introduces a ‘fork’ in the language: > https://github.com/ghc-proposals/ghc-proposals/pull/270#issuecomment-536115565. > (See Simon’s comment at the link for an explanation of the Haskell language > fork idea.) > > There is a long tradition of using data/type constructor puns (older than > Haskell itself) and many people will consider it good style (I certainly > do), while others do not, and they will benefit from tools to help manage > and limit their use. So, notwithstanding the fork-like nature of the > proposal, because it is not very intrusive (some warnings with finer > control of qualified imports), and it is helping folks to establish a > subset that they are maintaining anyway, I am minded to accept this > proposal — though it was close. > > My sole concern is that it could give rise to contentious pressure on the > wider Haskell community to embrace the subset. To (avoiding) this end, I > suggest that we include wording in the user guide section documenting this > extension to the effect that there is no consensus on the desirability or > otherwise of the punful code the extension seeks to address. > > > _______________________________________________ > 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 chris at chrisdornan.com Mon Dec 5 21:03:03 2022 From: chris at chrisdornan.com (Chris Dornan) Date: Mon, 5 Dec 2022 21:03:03 +0000 Subject: [ghc-steering-committee] Why not?, rather than, why? In-Reply-To: References: <10594AD6-665D-4674-8E96-78AB6C61973A@chrisdornan.com> Message-ID: <6D754A68-7BC5-48AF-A6A8-B307D9FD02EB@chrisdornan.com> Now I am sorry — my tongue was in my cheek in talking about the thread taking an authoritarian turn! I think we can al agree that there is a cost to adding more and more extensions, and bear the mounting complexity in mind when scrutinising these proposals, and try to steer this review process towards a coherent future language. At least that is my understanding of the spirit of what Joachim is getting at when he initiated this thread, in which case count me in. My point is just that we don’t also forget certain necessary messy realities in attempting to unwind ourselves from the ‘excessive’ complexity that our open, experimental philosophy/DNA will tend to generate. I would love to here more from Simon venting on what needs to happen, ideally down the pub, but, more practically, we might have to make do with a virtual one… Chris > On 5 Dec 2022, at 19:03, Simon Marlow wrote: > > Apologies, I didn't mean to sound like I wanted us to be "authoritarian", perhaps more along the lines of "opinionated". By analogy with the CLC: they are forced to make decisions, because there is only one set of core libraries. I don't necessarily agree with all the decisions that the CLC makes, but I'm very glad we only have one set of core libraries. > > In GHC we have the dubious luxury of being able to give people optional language features, I'm suggesting we should use this very carefully and avoid forks - which is our current policy anyway - but to be more intentional about it in the way that Joachim suggested. I'm also a fan of an open platform that encourages experimentation, but at some point we have to accept (I believe) that too much of this leads to a poor experience for new users. (that's putting it gently! I'm itching to rant about this some more, but I fear it may come across poorly. One for the pub.) > > Cheers > Simon > > On Fri, 2 Dec 2022 at 19:04, Chris Dornan > wrote: > I think we are on the same page, but the thread seemed to be taking an authoritarian turn so I thought it best to ensure the voices of caution were represented! > > Chris > > > On 2 Dec 2022, at 17:39, Joachim Breitner > wrote: > > > > Hi, > > > > Am Freitag, dem 02.12.2022 um 17:27 +0000 schrieb Chris Dornan: > >> I am sympathetic to the idea of a new language standard that we > >> promote heavily and encourage developers, tools, tutorials and > >> courseware to favour —if we get this right then we will reap the > >> benefits of a strong standard. But if we take it upon ourselves to > >> try and force an extension combination of our choosing on the > >> community because we believe the community will benefit from a big > >> reset then I think it could blow up on us really badly, with forks > >> and factions which could be truly difficult to manage — and fatally > >> discourage adoption. > > > > ah, sorry if I was unclear. I am certainly not proposing a form of “big > > reset”! It’s more about “should every language extension be in > > principle on track towards in inclusion to a future GHC20xx” – still > > all incremental and cautious. > > > > Cheers, > > Joachim > > > > -- > > Joachim Breitner > > mail at joachim-breitner.de > > http://www.joachim-breitner.de/ > > > > _______________________________________________ > > 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 vlad.z.4096 at gmail.com Tue Dec 6 06:53:21 2022 From: vlad.z.4096 at gmail.com (Vladislav Zavialov) Date: Tue, 6 Dec 2022 09:53:21 +0300 Subject: [ghc-steering-committee] Proposal #270: Support pun-free code. Recommendation: accept In-Reply-To: <5D0E3610-C73F-4850-9435-8D22069382BD@chrisdornan.com> References: <5D0E3610-C73F-4850-9435-8D22069382BD@chrisdornan.com> Message-ID: If you read the "Resolved Syntax Tree" section of #281, you can see the contortions it has to go through to support puns. It's very nuanced! I can easily imagine future users of RequiredTypeArguments struggle with type errors because they wanted to use a name from one namespace but this elaborate system selected a name from another namespace. -Wpuns would prevent this from happening: it can help identify namespace ambiguities and avoid them. It is mainly for this reason that I vote +1. And I'm happy to see the disclaimer that it is not "bad style" to use puns. What is considered good or bad often depends on context. In a module with RequiredTypeArguments, I would prefer to see -Wpuns enabled. In a module without it, I don't particularly care. Vlad On Mon, Dec 5, 2022 at 9:33 PM Chris Dornan wrote: > Hi all, > > I have been assigned to shepherd 'Proposal #270: Support pun-free code’ > and this is my second attempt to reach a conclusion (see below for for my > original encapsulation of the proposal). > > As I said, my outstanding concern was that some could see this proposal as > a green-lighting a general move against the use of these puns in general > Haskell code as ‘bad style. The author has now clarified in the proposal > that it should not be seen in this light. > > Unless anyone has any outstanding objections I suggest the we accept the > proposal — or at least hold an up-and-down vote to resolve whether we are > going to accept the proposal or not. > > I vote yes to accepting this proposal. > > Chris > > — > > My original summary: > > Proposal text: > https://github.com/hithroc/ghc-proposals/blob/master/proposals/0000-support-pun-free-code.md > > Proposal discussion: > https://github.com/ghc-proposals/ghc-proposals/pull/270 > > The proposal helps manage @data T = T@ style definitions that use the > same name for type and data constructors. > > It introduces -Wpuns and -Wpun-bind to warn about puns at usage and > binding sites, respectively, and adds qualified import syntax for importing > selectively into the data and type name spaces: > > import Data.Proxy type qualified as T -- import only the type namespace > import Data.Proxy data qualified as D -- import only the data namespace > > As the low number indicates the proposal has been around for a while and > the author has an implementation PR: > https://gitlab.haskell.org/ghc/ghc/-/merge_requests/2044. > > The most active discussion point was Simon’s observation that this > extension introduces a ‘fork’ in the language: > https://github.com/ghc-proposals/ghc-proposals/pull/270#issuecomment-536115565. > (See Simon’s comment at the link for an explanation of the Haskell language > fork idea.) > > There is a long tradition of using data/type constructor puns (older than > Haskell itself) and many people will consider it good style (I certainly > do), while others do not, and they will benefit from tools to help manage > and limit their use. So, notwithstanding the fork-like nature of the > proposal, because it is not very intrusive (some warnings with finer > control of qualified imports), and it is helping folks to establish a > subset that they are maintaining anyway, I am minded to accept this > proposal — though it was close. > > My sole concern is that it could give rise to contentious pressure on the > wider Haskell community to embrace the subset. To (avoiding) this end, I > suggest that we include wording in the user guide section documenting this > extension to the effect that there is no consensus on the desirability or > otherwise of the punful code the extension seeks to address. > > > _______________________________________________ > 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 mail at joachim-breitner.de Wed Dec 7 18:12:23 2022 From: mail at joachim-breitner.de (Joachim Breitner) Date: Wed, 07 Dec 2022 19:12:23 +0100 Subject: [ghc-steering-committee] Proposal #270: Support pun-free code. Recommendation: accept In-Reply-To: <5D0E3610-C73F-4850-9435-8D22069382BD@chrisdornan.com> References: <5D0E3610-C73F-4850-9435-8D22069382BD@chrisdornan.com> Message-ID: <2da00f7f92f292bb16a4dfc53ec62d68ecf6edc9.camel@joachim-breitner.de> Hi, generally in favor; these new warnings shoudn’t do harm and are hopefully useful to some. But I have a technical issue (sorry for being so late with that): I note that this proposal extends -XExplicitNamespaces, which so far can be used to distinguish type from term operators in export and import lists, by allowing them to be prefixed with `type` (but not `data`!), as in: import N( f, type (++) ) https://downloads.haskell.org/ghc/latest/docs/users_guide/exts/explicit_namespaces.html The new extension now extends this extension the import qualified Foo data as FD import qualified Foo type as FT forms to “filter” imports by namespace. A few points: * It seems to be inconsistent to allow both `type` and `data` in the  filtered-import, but as a qualifier on individual only `type`. Should we allow the use of `data` in import/export lists as well? import N(f, type (++), data (+)) * As discussed in https://github.com/ghc-proposals/ghc-proposals/issues/551, -XExplicitNamespaces, which is quite old and is implied by  -XTypeOperators which is implied by -XGHC2021 probably ought to have been in GHC2021 as well, and I’d like to include it in GHC2023 (if  that exists) to fix that (see #559). But that feels inappropriate if we extend that extension in this way. We could side-step that issue if we put he new forms in their own language extension (maybe -XNamespacedImport)? WDYT? Cheers, Joachim -- Joachim Breitner mail at joachim-breitner.de http://www.joachim-breitner.de/ From chris at chrisdornan.com Wed Dec 7 21:15:26 2022 From: chris at chrisdornan.com (Chris Dornan) Date: Wed, 7 Dec 2022 21:15:26 +0000 Subject: [ghc-steering-committee] Proposal #270: Support pun-free code. Recommendation: accept In-Reply-To: <2da00f7f92f292bb16a4dfc53ec62d68ecf6edc9.camel@joachim-breitner.de> References: <5D0E3610-C73F-4850-9435-8D22069382BD@chrisdornan.com> <2da00f7f92f292bb16a4dfc53ec62d68ecf6edc9.camel@joachim-breitner.de> Message-ID: <9F14A7C6-BB8E-433C-BD04-BD66B8A3937A@chrisdornan.com> On the first point , I suggest we propose it in the thread and see what the author has to say. On the second point I am all in favour of splitting out -XNamespacedImport. Chris > On 7 Dec 2022, at 18:12, Joachim Breitner wrote: > > Hi, > > generally in favor; these new warnings shoudn’t do harm and are > hopefully useful to some. > > But I have a technical issue (sorry for being so late with that): > > I note that this proposal extends -XExplicitNamespaces, which so far > can be used to distinguish type from term operators in export and > import lists, by allowing them to be prefixed with `type` (but not > `data`!), as in: import N( f, type (++) ) > https://downloads.haskell.org/ghc/latest/docs/users_guide/exts/explicit_namespaces.html > > The new extension now extends this extension the > > import qualified Foo data as FD > import qualified Foo type as FT > > forms to “filter” imports by namespace. A few points: > > * It seems to be inconsistent to allow both `type` and `data` in the > filtered-import, but as a qualifier on individual only `type`. Should > we allow the use of `data` in import/export lists as well? > > import N(f, type (++), data (+)) > > * As discussed in > https://github.com/ghc-proposals/ghc-proposals/issues/551, > -XExplicitNamespaces, which is quite old and is implied by > -XTypeOperators which is implied by -XGHC2021 probably ought to have > been in GHC2021 as well, and I’d like to include it in GHC2023 (if > that exists) to fix that (see #559). But that feels inappropriate > if we extend that extension in this way. > > We could side-step that issue if we put he new forms in their own > language extension (maybe -XNamespacedImport)? WDYT? > > Cheers, > Joachim > -- > Joachim Breitner > mail at joachim-breitner.de > http://www.joachim-breitner.de/ > > _______________________________________________ > 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 mail at joachim-breitner.de Thu Dec 8 07:28:43 2022 From: mail at joachim-breitner.de (Joachim Breitner) Date: Thu, 08 Dec 2022 08:28:43 +0100 Subject: [ghc-steering-committee] Proposal #270: Support pun-free code. Recommendation: accept In-Reply-To: <9F14A7C6-BB8E-433C-BD04-BD66B8A3937A@chrisdornan.com> References: <5D0E3610-C73F-4850-9435-8D22069382BD@chrisdornan.com> <2da00f7f92f292bb16a4dfc53ec62d68ecf6edc9.camel@joachim-breitner.de> <9F14A7C6-BB8E-433C-BD04-BD66B8A3937A@chrisdornan.com> Message-ID: <8310d99d67728299b3a3b0efa206841933404be5.camel@joachim-breitner.de> Hi, Am Mittwoch, dem 07.12.2022 um 21:15 +0000 schrieb Chris Dornan: > On the first point , I suggest we propose it in the thread and see > what the author has to say. > > On the second point I am all in favour of splitting out - > XNamespacedImport. If you are in favor of putting it under -XNamespacedImport, I suggest we don’t bother the authors with “cleaning up” ExplicitNamespaces, and leave that to a separate proposal (if at all). Cheers, Joachim -- Joachim Breitner mail at joachim-breitner.de http://www.joachim-breitner.de/ From vlad.z.4096 at gmail.com Thu Dec 8 07:43:06 2022 From: vlad.z.4096 at gmail.com (Vladislav Zavialov) Date: Thu, 8 Dec 2022 10:43:06 +0300 Subject: [ghc-steering-committee] Proposal #270: Support pun-free code. Recommendation: accept In-Reply-To: <2da00f7f92f292bb16a4dfc53ec62d68ecf6edc9.camel@joachim-breitner.de> References: <5D0E3610-C73F-4850-9435-8D22069382BD@chrisdornan.com> <2da00f7f92f292bb16a4dfc53ec62d68ecf6edc9.camel@joachim-breitner.de> Message-ID: Hi Joachim, * It seems to be inconsistent to allow both `type` and `data` in the > filtered-import, but as a qualifier on individual only `type`. Should > we allow the use of `data` in import/export lists as well? > > import N(f, type (++), data (+)) > The "data" qualifier is also in the proposal, but it's behind PatternSynonyms rather than ExplicitNamespaces. That's because it is meant to replace the "pattern" qualifier, which is currently enabled by PatternSynonyms. However, I think you make a very good point: both of those qualifiers should be enabled by the same extension, ExplicitNamespaces. > * As discussed in > https://github.com/ghc-proposals/ghc-proposals/issues/551, > -XExplicitNamespaces, which is quite old and is implied by > -XTypeOperators which is implied by -XGHC2021 probably ought to have > been in GHC2021 as well, and I’d like to include it in GHC2023 (if > that exists) to fix that (see #559). But that feels inappropriate > if we extend that extension in this way. > > We could side-step that issue if we put he new forms in their own > language extension (maybe -XNamespacedImport)? WDYT? > #281 also modifies ExplicitNamespaces to enable inline "type" qualifiers in expressions. Do you want a separate extension for that also? -------------- next part -------------- An HTML attachment was scrubbed... URL: From mail at joachim-breitner.de Thu Dec 8 08:00:57 2022 From: mail at joachim-breitner.de (Joachim Breitner) Date: Thu, 08 Dec 2022 09:00:57 +0100 Subject: [ghc-steering-committee] Proposal #270: Support pun-free code. Recommendation: accept In-Reply-To: References: <5D0E3610-C73F-4850-9435-8D22069382BD@chrisdornan.com> <2da00f7f92f292bb16a4dfc53ec62d68ecf6edc9.camel@joachim-breitner.de> Message-ID: <3267a53a47cec3597c54bab8f8518b2c1613e1a8.camel@joachim-breitner.de> Hi, Am Donnerstag, dem 08.12.2022 um 10:43 +0300 schrieb Vladislav Zavialov: > #281 also modifies ExplicitNamespaces to enable inline "type" > qualifiers in expressions. Do you want a separate extension for that > also? ah, I knew we had that somewhere! Thanks for reminding me! So with #281, I can use inline `type` everywhere where I refer to a name? Or only in expressions? Reading the spec I can only use them in expressions – why not in types? And is there no dual use-case to refer to data in types, e.g. with promoted types? My current gut feeling is that there could be a simple unified “explicit namespace qualifier” that I can use essentially everywhere when I want to be explicit which Foo I mean – expressions, types, import lists, export lists, INLINE pragmas. ExplicitNamespaces sounds like the natural name for that extensions, and nicely extends it. I am unsure if it is wise to extend ExplicitNamespaces that way and at the same time advocate for its inclusion in GHC20xx. This depends a bit on how bold we want to be with GHC20xx. A conservative approach is to find a new name for the “comprehensive” extension. I expect that extension would then subsume the changes in #281. The extension to imports in #270 has a slightly different feel to it – you are not qualifying a name here, but you are really filtering all imported names. I think putting that into its own extension makes sense for two reasons: * It decouples these discussions for now. * It may be that -XNamespacedImport turns out to be not that useful when instead you can disambiguate at the occurrence or in an explicit import list using (comprehensive) ExplicitNamespaces, and one possible future may be that that style will be more common. Then we may want to make one, but not the other, the default. Cheers, Joachim -- Joachim Breitner mail at joachim-breitner.de http://www.joachim-breitner.de/ From mail at joachim-breitner.de Thu Dec 8 08:33:13 2022 From: mail at joachim-breitner.de (Joachim Breitner) Date: Thu, 08 Dec 2022 09:33:13 +0100 Subject: [ghc-steering-committee] Proposal #270: Support pun-free code. Recommendation: accept In-Reply-To: References: <5D0E3610-C73F-4850-9435-8D22069382BD@chrisdornan.com> <2da00f7f92f292bb16a4dfc53ec62d68ecf6edc9.camel@joachim-breitner.de> <3267a53a47cec3597c54bab8f8518b2c1613e1a8.camel@joachim-breitner.de> Message-ID: (replying to the whole list, full quote) Am Donnerstag, dem 08.12.2022 um 11:23 +0300 schrieb Vladislav Zavialov: > I agree with your observation that namespaced imports are somewhat > different from simply specifying the namespace of a single name, so > they could be separated into their own extension. But if that is the > reasoning that we choose to follow, then the changes in #281 should > *definitely* go into their own extension: they affect not just names > but entire expressions and patterns, including their grammar (not > just namespacing). > > The only reason the changes in #270 and #281 are included in > ExplicitNamespaces is to reduce the amount of language flags. If you > prefer fine-grained control and immutable extensions, then both of > those changes need separate flags for them. > > So, if we are consistent, we have two options: > 1. Include changes in #270 and #281 in ExplicitNamespaces on the > grounds that they include explicitly specify a namespace (even though > that is not the only thing they do) > 2. Create separate language extension flags: NamespacedImports and > TypesInExpressions (names to be discussed) > > I happen to prefer (1), and that is the approach that the proposals > currently follow, but I am not opposed to (2) either. I don’t prefer fine-grained flags per se. In fact, my ideal world is one perfect language with no flags :-). So I think I’d prefer all under ExplicitNamespaces as well, and I think the only reason I am hesitant is that I believe the old ExplicitNamespaces should have been in GHC2021, so it should be in GHC2023, and am unsure if the (comprehensive) ExplicitNamespaces should be there. This gives us (at least) these options: 1. Leave ExplicitNamespaces alone, add ExplicitNamespaces to GHC2023,  introduce one or two new extensions for the newer changes. 2. Extend ExplicitNamespaces, and don’t add it already to GHC2023, disregarding issue #551. 3. Add ExplicitNamespaces to GHC2023, and still add it to GHC2023, arguing that GHC20xx allows more liberal (backward-compatibile) changes than, say, Haskell2010 would allow. Certainly 1 is the least bold move. I am not sure what the best way forwards is, and welcome other opinions. Cheers, Joachim -- Joachim Breitner mail at joachim-breitner.de http://www.joachim-breitner.de/ From arnaud.spiwack at tweag.io Thu Dec 8 17:01:05 2022 From: arnaud.spiwack at tweag.io (Arnaud Spiwack) Date: Thu, 8 Dec 2022 18:01:05 +0100 Subject: [ghc-steering-committee] #512: NoFieldSelectors as datatype annotation, Recommendation: reject In-Reply-To: <451cf30d-8fc6-a052-0c3d-707b5f7fbc92@well-typed.com> References: <494656e83f8d1486621fab153ed8f85f13b82e1b.camel@joachim-breitner.de> <414422bd-7085-f244-626a-19711dfd0692@well-typed.com> <02620ae95fb4d0a07172c06ffa83281d293e4149.camel@joachim-breitner.de> <451cf30d-8fc6-a052-0c3d-707b5f7fbc92@well-typed.com> Message-ID: It seems to me that the only motivation for this proposal is for Template Haskell generated code. So maybe we can imagine an alternative that is purely in Template Haskell, without any syntax. Which would avoid the concerns about parsing pragmas*. Maybe there is room, in this space, for a generic mechanism, but I don't think that we'd need this: it makes sense to let the Template Haskell slice decide if a record it defines generates selectors or not. That being said, I'm personally ok with the proposal as it stands, I think it makes sense. But it's likely that a pure Template Haskell solution may be both more forward compatible and easier to implement (at least, based on Vlad estimate, who knows this part of the code, I'm inclined to believe so). As there doesn't seem to be any particular motivation beyond Template Haskell, I'd be ok if we made this counter-proposal. I don't think counterargument 4 is something we can oppose: it is theoretically possible to define the doppelgänger record in a separate module, but we know it won't happen. Matt Parsons mentions the Esqueleto library, it is obvious that the library will prefer using a silly name for record fields rather than ask its users to move definitions to another module and the library will be right: it is less obnoxious. All in all, I think that the proposal is quite reasonable, and would open space in the design of Template-Haskell based libraries. * For the record, I don't think that we can claim that pragmas can be ignored semantically. The OVERLAPPING pragma is a counter-example. Maybe more acutely: the LANGUAGE pragma. So I don't agree with counterargument 3. On Wed, 30 Nov 2022 at 22:18, Adam Gundry wrote: > On 30/11/2022 20:37, Joachim Breitner wrote: > > Hi, > > > > Am Mittwoch, dem 30.11.2022 um 19:28 +0000 schrieb Adam Gundry: > >> What do you think? > > > > my initial feeling about `language … where …` is that it is a modifer > > of sorts, however > > * with a syntax that may not scale well (hard to target anything > > but a whole set of declarations) > > * looks like it could support any kind of language extension, when > > it probably doesn’t make sense for all of them. > > so may not gain much over implementing (parts) of the modifier syntax. > > Well, I find it hard to imagine really needing to enable an extension > for anything smaller than a declaration group. On the other hand, I not > infrequently want to enable particular extensions only for a few > specific definitions (AllowAmbiguousTypes comes to mind). > > As I understand it, modifiers need to be type-checked before they have > meaning assigned. This presumably means they cannot change the behaviour > of the parser, whereas an explicit "language ... where ..." construct > could do so. And I don't think modifiers can scope over a declaration > group, only a single declaration? > > I agree that we wouldn't necessarily support *all* language extensions > locally, but I think the list for which this fundamentally does not make > sense is relatively short (the main ones that come to mind are > import-related extensions such as ExplicitNamespaces). Others might be > hard to specify/implement (e.g. Safe Haskell seems tricky) but we could > simply not support them locally. > > > > ... > > > > Or we revive local modules, and use that as a then natural way of > > scoping language pragmas… > > There's clearly a relationship to local modules, but that seems like > more complexity than we need for the problem at hand. I don't see why we > shouldn't add "language ... where ..." now, then potentially later > support local (or top-level!) modules with > > language Blah where > module M where > ... > > After all, {-# LANGUAGE #-} pragmas violate the principle that pragmas > shouldn't change semantics. ;-) > > Cheers, > > Adam > > > -- > Adam Gundry, Haskell Consultant > Well-Typed LLP, https://www.well-typed.com/ > > Registered in England & Wales, OC335890 > 27 Old Gloucester Street, London WC1N 3AX, England > > _______________________________________________ > ghc-steering-committee mailing list > ghc-steering-committee at haskell.org > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee > -------------- next part -------------- An HTML attachment was scrubbed... URL: From arnaud.spiwack at tweag.io Thu Dec 8 17:29:16 2022 From: arnaud.spiwack at tweag.io (Arnaud Spiwack) Date: Thu, 8 Dec 2022 18:29:16 +0100 Subject: [ghc-steering-committee] Why not?, rather than, why? In-Reply-To: <6D754A68-7BC5-48AF-A6A8-B307D9FD02EB@chrisdornan.com> References: <10594AD6-665D-4674-8E96-78AB6C61973A@chrisdornan.com> <6D754A68-7BC5-48AF-A6A8-B307D9FD02EB@chrisdornan.com> Message-ID: Personally, my concern is primarily procedural. There is no official stance on what an extension can be, so different people map different concepts on them. As a result, we have a lot of conversations (in here, in proposal threads) where everybody speaks past one another. What I would like is that we come together and design a principle saying: we strive for future extensions to be X. This would clarify discussions around - Is a new extension X appropriate? - Should extension X imply extension Y? - Should extension X be included in GHC20XX? My personal (strong) preference is for striving for extensions to either become a default, eventually, or to be deprecated. It also seems to be the preference of most of those who spoke up here. But what really matters is that we make a choice. The choice can be: “An extension is a switch that triggers optional behaviour in the language, it can be used to gate advanced features, some (but probably not all) of these extensions will become defaults if their use is generalised enough”, I'd disagree with the choice, but I'd champion it anyway. Note that this option is compatible with the no-language-fork principle. My point is: we need to take an explicit stance and record it. /Arnaud On Mon, 5 Dec 2022 at 22:03, Chris Dornan wrote: > Now I am sorry — my tongue was in my cheek in talking about the thread > taking an authoritarian turn! > > I think we can al agree that there is a cost to adding more and more > extensions, and bear the mounting complexity in mind when scrutinising > these proposals, and try to steer this review process towards a coherent > future language. At least that is my understanding of the spirit of what > Joachim is getting at when he initiated this thread, in which case count me > in. My point is just that we don’t also forget certain necessary messy > realities in attempting to unwind ourselves from the ‘excessive’ complexity > that our open, experimental philosophy/DNA will tend to generate. > > I would love to here more from Simon venting on what needs to happen, > ideally down the pub, but, more practically, we might have to make do with > a virtual one… > > Chris > > > On 5 Dec 2022, at 19:03, Simon Marlow wrote: > > Apologies, I didn't mean to sound like I wanted us to be "authoritarian", > perhaps more along the lines of "opinionated". By analogy with the CLC: > they are forced to make decisions, because there is only one set of core > libraries. I don't necessarily agree with all the decisions that the CLC > makes, but I'm very glad we only have one set of core libraries. > > In GHC we have the dubious luxury of being able to give people optional > language features, I'm suggesting we should use this very carefully and > avoid forks - which is our current policy anyway - but to be more > intentional about it in the way that Joachim suggested. I'm also a fan of > an open platform that encourages experimentation, but at some point we have > to accept (I believe) that too much of this leads to a poor experience for > new users. (that's putting it gently! I'm itching to rant about this some > more, but I fear it may come across poorly. One for the pub.) > > Cheers > Simon > > On Fri, 2 Dec 2022 at 19:04, Chris Dornan wrote: > >> I think we are on the same page, but the thread seemed to be taking an >> authoritarian turn so I thought it best to ensure the voices of caution >> were represented! >> >> Chris >> >> > On 2 Dec 2022, at 17:39, Joachim Breitner >> wrote: >> > >> > Hi, >> > >> > Am Freitag, dem 02.12.2022 um 17:27 +0000 schrieb Chris Dornan: >> >> I am sympathetic to the idea of a new language standard that we >> >> promote heavily and encourage developers, tools, tutorials and >> >> courseware to favour —if we get this right then we will reap the >> >> benefits of a strong standard. But if we take it upon ourselves to >> >> try and force an extension combination of our choosing on the >> >> community because we believe the community will benefit from a big >> >> reset then I think it could blow up on us really badly, with forks >> >> and factions which could be truly difficult to manage — and fatally >> >> discourage adoption. >> > >> > ah, sorry if I was unclear. I am certainly not proposing a form of “big >> > reset”! It’s more about “should every language extension be in >> > principle on track towards in inclusion to a future GHC20xx” – still >> > all incremental and cautious. >> > >> > Cheers, >> > Joachim >> > >> > -- >> > Joachim Breitner >> > mail at joachim-breitner.de >> > http://www.joachim-breitner.de/ >> > >> > _______________________________________________ >> > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From arnaud.spiwack at tweag.io Thu Dec 8 17:44:36 2022 From: arnaud.spiwack at tweag.io (Arnaud Spiwack) Date: Thu, 8 Dec 2022 18:44:36 +0100 Subject: [ghc-steering-committee] Proposal #270: Support pun-free code. Recommendation: accept In-Reply-To: References: <5D0E3610-C73F-4850-9435-8D22069382BD@chrisdornan.com> <2da00f7f92f292bb16a4dfc53ec62d68ecf6edc9.camel@joachim-breitner.de> <3267a53a47cec3597c54bab8f8518b2c1613e1a8.camel@joachim-breitner.de> Message-ID: As it currently stands, it seems to me that the proposal is pretty modest. I'm in favour of the proposal, provided that the technical details are resolved to Joachim satisfaction. On Thu, 8 Dec 2022 at 09:33, Joachim Breitner wrote: > (replying to the whole list, full quote) > > Am Donnerstag, dem 08.12.2022 um 11:23 +0300 schrieb Vladislav > Zavialov: > > I agree with your observation that namespaced imports are somewhat > > different from simply specifying the namespace of a single name, so > > they could be separated into their own extension. But if that is the > > reasoning that we choose to follow, then the changes in #281 should > > *definitely* go into their own extension: they affect not just names > > but entire expressions and patterns, including their grammar (not > > just namespacing). > > > > The only reason the changes in #270 and #281 are included in > > ExplicitNamespaces is to reduce the amount of language flags. If you > > prefer fine-grained control and immutable extensions, then both of > > those changes need separate flags for them. > > > > So, if we are consistent, we have two options: > > 1. Include changes in #270 and #281 in ExplicitNamespaces on the > > grounds that they include explicitly specify a namespace (even though > > that is not the only thing they do) > > 2. Create separate language extension flags: NamespacedImports and > > TypesInExpressions (names to be discussed) > > > > I happen to prefer (1), and that is the approach that the proposals > > currently follow, but I am not opposed to (2) either. > > I don’t prefer fine-grained flags per se. In fact, my ideal world is > one perfect language with no flags :-). So I think I’d prefer all under > ExplicitNamespaces as well, and I think the only reason I am hesitant > is that I believe the old ExplicitNamespaces should have been in > GHC2021, so it should be in GHC2023, and am unsure if the > (comprehensive) ExplicitNamespaces should be there. > > This gives us (at least) these options: > > 1. Leave ExplicitNamespaces alone, add ExplicitNamespaces to GHC2023, > introduce one or two new extensions for the newer changes. > 2. Extend ExplicitNamespaces, and don’t add it already to GHC2023, > disregarding issue #551. > 3. Add ExplicitNamespaces to GHC2023, and still add it to GHC2023, > arguing that GHC20xx allows more liberal (backward-compatibile) > changes than, say, Haskell2010 would allow. > > Certainly 1 is the least bold move. I am not sure what the best way > forwards is, and welcome other opinions. > > Cheers, > Joachim > > > > -- > Joachim Breitner > mail at joachim-breitner.de > http://www.joachim-breitner.de/ > > _______________________________________________ > ghc-steering-committee mailing list > ghc-steering-committee at haskell.org > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee > -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.peytonjones at gmail.com Thu Dec 8 17:53:24 2022 From: simon.peytonjones at gmail.com (Simon Peyton Jones) Date: Thu, 8 Dec 2022 17:53:24 +0000 Subject: [ghc-steering-committee] Why not?, rather than, why? In-Reply-To: References: <10594AD6-665D-4674-8E96-78AB6C61973A@chrisdornan.com> <6D754A68-7BC5-48AF-A6A8-B307D9FD02EB@chrisdornan.com> Message-ID: > > The choice can be:... > My point is: we need to take an explicit stance and record it. > Do you want to lay out * the problem you want to solve * a set of possible choices that might solve it Personally I don't perceive an immediate problem that we need to solve. But I'm an outlier and willing to be educated. On Thu, 8 Dec 2022 at 17:30, Arnaud Spiwack wrote: > Personally, my concern is primarily procedural. There is no official > stance on what an extension can be, so different people map different > concepts on them. As a result, we have a lot of conversations (in here, in > proposal threads) where everybody speaks past one another. What I would > like is that we come together and design a principle saying: we strive for > future extensions to be X. This would clarify discussions around > - Is a new extension X appropriate? > - Should extension X imply extension Y? > - Should extension X be included in GHC20XX? > > My personal (strong) preference is for striving for extensions to either > become a default, eventually, or to be deprecated. It also seems to be the > preference of most of those who spoke up here. But what really matters is > that we make a choice. The choice can be: “An extension is a switch that > triggers optional behaviour in the language, it can be used to gate > advanced features, some (but probably not all) of these extensions will > become defaults if their use is generalised enough”, I'd disagree with the > choice, but I'd champion it anyway. Note that this option is compatible > with the no-language-fork principle. > > My point is: we need to take an explicit stance and record it. > > /Arnaud > > On Mon, 5 Dec 2022 at 22:03, Chris Dornan wrote: > >> Now I am sorry — my tongue was in my cheek in talking about the thread >> taking an authoritarian turn! >> >> I think we can al agree that there is a cost to adding more and more >> extensions, and bear the mounting complexity in mind when scrutinising >> these proposals, and try to steer this review process towards a coherent >> future language. At least that is my understanding of the spirit of what >> Joachim is getting at when he initiated this thread, in which case count me >> in. My point is just that we don’t also forget certain necessary messy >> realities in attempting to unwind ourselves from the ‘excessive’ complexity >> that our open, experimental philosophy/DNA will tend to generate. >> >> I would love to here more from Simon venting on what needs to happen, >> ideally down the pub, but, more practically, we might have to make do with >> a virtual one… >> >> Chris >> >> >> On 5 Dec 2022, at 19:03, Simon Marlow wrote: >> >> Apologies, I didn't mean to sound like I wanted us to be "authoritarian", >> perhaps more along the lines of "opinionated". By analogy with the CLC: >> they are forced to make decisions, because there is only one set of core >> libraries. I don't necessarily agree with all the decisions that the CLC >> makes, but I'm very glad we only have one set of core libraries. >> >> In GHC we have the dubious luxury of being able to give people optional >> language features, I'm suggesting we should use this very carefully and >> avoid forks - which is our current policy anyway - but to be more >> intentional about it in the way that Joachim suggested. I'm also a fan of >> an open platform that encourages experimentation, but at some point we have >> to accept (I believe) that too much of this leads to a poor experience for >> new users. (that's putting it gently! I'm itching to rant about this some >> more, but I fear it may come across poorly. One for the pub.) >> >> Cheers >> Simon >> >> On Fri, 2 Dec 2022 at 19:04, Chris Dornan wrote: >> >>> I think we are on the same page, but the thread seemed to be taking an >>> authoritarian turn so I thought it best to ensure the voices of caution >>> were represented! >>> >>> Chris >>> >>> > On 2 Dec 2022, at 17:39, Joachim Breitner >>> wrote: >>> > >>> > Hi, >>> > >>> > Am Freitag, dem 02.12.2022 um 17:27 +0000 schrieb Chris Dornan: >>> >> I am sympathetic to the idea of a new language standard that we >>> >> promote heavily and encourage developers, tools, tutorials and >>> >> courseware to favour —if we get this right then we will reap the >>> >> benefits of a strong standard. But if we take it upon ourselves to >>> >> try and force an extension combination of our choosing on the >>> >> community because we believe the community will benefit from a big >>> >> reset then I think it could blow up on us really badly, with forks >>> >> and factions which could be truly difficult to manage — and fatally >>> >> discourage adoption. >>> > >>> > ah, sorry if I was unclear. I am certainly not proposing a form of “big >>> > reset”! It’s more about “should every language extension be in >>> > principle on track towards in inclusion to a future GHC20xx” – still >>> > all incremental and cautious. >>> > >>> > Cheers, >>> > Joachim >>> > >>> > -- >>> > Joachim Breitner >>> > mail at joachim-breitner.de >>> > http://www.joachim-breitner.de/ >>> > >>> > _______________________________________________ >>> > 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 >> > _______________________________________________ > ghc-steering-committee mailing list > ghc-steering-committee at haskell.org > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee > -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.peytonjones at gmail.com Fri Dec 9 07:38:36 2022 From: simon.peytonjones at gmail.com (Simon Peyton Jones) Date: Fri, 9 Dec 2022 07:38:36 +0000 Subject: [ghc-steering-committee] #512: NoFieldSelectors as datatype annotation, Recommendation: reject In-Reply-To: References: <494656e83f8d1486621fab153ed8f85f13b82e1b.camel@joachim-breitner.de> <414422bd-7085-f244-626a-19711dfd0692@well-typed.com> <02620ae95fb4d0a07172c06ffa83281d293e4149.camel@joachim-breitner.de> <451cf30d-8fc6-a052-0c3d-707b5f7fbc92@well-typed.com> Message-ID: > > It seems to me that the only motivation for this proposal is for Template > Haskell generated code > I don't think so. Michael suggested another Another motivation: today it's generally considered Bad Practice to use record syntax for the constructors of datatypes with alternatives, because this generates partial field accessors. With NoFieldSelectors, we can avoid this, but at the cost of turning off field selector generation for the entire module, which we might not want. Being able to control field selector generation on a per-datatype level lets you use this trick while keeping other "normal" records the same. I think this proposal is generally a good idea. If we have NoRecrodSelectors at all we should have it on a per-data-type basis. I am exercised about the modifiers problem If we had modifiers we'd definitely use them. Using pragmas temporarily adds friction because we'll have to go through deprecation cycles to get rid of them. I think we should accept the proposal, but also proactively seek implementation support for modifiers. If we push hard maybe we can get modifiers in time not to have to go round the houses with pragmas. The only thing I'd like to add to the proposal is the specific modifier design. What is the modifier name? From which module is the modifier exported. That way when we get modifiers we don't have to start a new debate. On Thu, 8 Dec 2022 at 17:01, Arnaud Spiwack wrote: > It seems to me that the only motivation for this proposal is for Template > Haskell generated code. So maybe we can imagine an alternative that is > purely in Template Haskell, without any syntax. Which would avoid the > concerns about parsing pragmas*. Maybe there is room, in this space, for a > generic mechanism, but I don't think that we'd need this: it makes sense to > let the Template Haskell slice decide if a record it defines generates > selectors or not. > > That being said, I'm personally ok with the proposal as it stands, I think > it makes sense. But it's likely that a pure Template Haskell solution may > be both more forward compatible and easier to implement (at least, based on > Vlad estimate, who knows this part of the code, I'm inclined to believe > so). As there doesn't seem to be any particular motivation beyond Template > Haskell, I'd be ok if we made this counter-proposal. > > I don't think counterargument 4 is something we can oppose: it is > theoretically possible to define the doppelgänger record in a separate > module, but we know it won't happen. Matt Parsons mentions the Esqueleto > library, it is obvious that the library will prefer using a silly name for > record fields rather than ask its users to move definitions to another > module and the library will be right: it is less obnoxious. > > All in all, I think that the proposal is quite reasonable, and would open > space in the design of Template-Haskell based libraries. > > * For the record, I don't think that we can claim that pragmas can be > ignored semantically. The OVERLAPPING pragma is a counter-example. Maybe > more acutely: the LANGUAGE pragma. So I don't agree with counterargument 3. > > On Wed, 30 Nov 2022 at 22:18, Adam Gundry wrote: > >> On 30/11/2022 20:37, Joachim Breitner wrote: >> > Hi, >> > >> > Am Mittwoch, dem 30.11.2022 um 19:28 +0000 schrieb Adam Gundry: >> >> What do you think? >> > >> > my initial feeling about `language … where …` is that it is a modifer >> > of sorts, however >> > * with a syntax that may not scale well (hard to target anything >> > but a whole set of declarations) >> > * looks like it could support any kind of language extension, when >> > it probably doesn’t make sense for all of them. >> > so may not gain much over implementing (parts) of the modifier syntax. >> >> Well, I find it hard to imagine really needing to enable an extension >> for anything smaller than a declaration group. On the other hand, I not >> infrequently want to enable particular extensions only for a few >> specific definitions (AllowAmbiguousTypes comes to mind). >> >> As I understand it, modifiers need to be type-checked before they have >> meaning assigned. This presumably means they cannot change the behaviour >> of the parser, whereas an explicit "language ... where ..." construct >> could do so. And I don't think modifiers can scope over a declaration >> group, only a single declaration? >> >> I agree that we wouldn't necessarily support *all* language extensions >> locally, but I think the list for which this fundamentally does not make >> sense is relatively short (the main ones that come to mind are >> import-related extensions such as ExplicitNamespaces). Others might be >> hard to specify/implement (e.g. Safe Haskell seems tricky) but we could >> simply not support them locally. >> >> >> > ... >> > >> > Or we revive local modules, and use that as a then natural way of >> > scoping language pragmas… >> >> There's clearly a relationship to local modules, but that seems like >> more complexity than we need for the problem at hand. I don't see why we >> shouldn't add "language ... where ..." now, then potentially later >> support local (or top-level!) modules with >> >> language Blah where >> module M where >> ... >> >> After all, {-# LANGUAGE #-} pragmas violate the principle that pragmas >> shouldn't change semantics. ;-) >> >> Cheers, >> >> Adam >> >> >> -- >> Adam Gundry, Haskell Consultant >> Well-Typed LLP, https://www.well-typed.com/ >> >> Registered in England & Wales, OC335890 >> 27 Old Gloucester Street, London WC1N 3AX, England >> >> _______________________________________________ >> ghc-steering-committee mailing list >> ghc-steering-committee at haskell.org >> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee >> > _______________________________________________ > ghc-steering-committee mailing list > ghc-steering-committee at haskell.org > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee > -------------- next part -------------- An HTML attachment was scrubbed... URL: From adam at well-typed.com Fri Dec 9 08:18:21 2022 From: adam at well-typed.com (Adam Gundry) Date: Fri, 9 Dec 2022 08:18:21 +0000 Subject: [ghc-steering-committee] #512: NoFieldSelectors as datatype annotation, Recommendation: reject In-Reply-To: References: <494656e83f8d1486621fab153ed8f85f13b82e1b.camel@joachim-breitner.de> <414422bd-7085-f244-626a-19711dfd0692@well-typed.com> <02620ae95fb4d0a07172c06ffa83281d293e4149.camel@joachim-breitner.de> <451cf30d-8fc6-a052-0c3d-707b5f7fbc92@well-typed.com> Message-ID: <9484dee9-2d77-98ae-5b4d-ebc51f19cb24@well-typed.com> On 09/12/2022 07:38, Simon Peyton Jones wrote: > It seems to me that the only motivation for this proposal is for > Template Haskell generated code > > > I don't think so.  Michael suggested another > > Another motivation: today it's generally considered Bad Practice to > use record syntax for the constructors of datatypes with > alternatives, because this generates partial field accessors. With > NoFieldSelectors, we can avoid this, but at the cost of turning off > field selector generation for the entire module, which we might not > want. Being able to control field selector generation on a > per-datatype level lets you use this trick while keeping other > "normal" records the same. > > I think this proposal is generally a good idea. I agree with Simon here: the motivation for this proposal is wider than just with TH. It will be useful to be able to explore designs where a single module includes one record datatype with selectors, and other datatypes that use the same field names but not selectors. Those might be TH-generated, but need not be in general. Moreover, I think it would be problematic to have features that are available only via TH splices and that cannot be translated to the underlying declarations. As a user I expect to be able to expand spliced declarations, and some users rely on this (e.g. to support cross-compilation scenarios where TH support is tricky). > If we have NoRecrodSelectors at all we should have it on a > per-data-type basis. Agreed. But what about per-field or per-constructor? The proposal allows these but I'm not convinced we need more than per-datatype, and that would reduce complexity. > I am exercised about the modifiers problem  If we had modifiers we'd > definitely use them.  Using pragmas temporarily adds friction because > we'll have to go through deprecation cycles to get rid of them. > > I think we should accept the proposal, but also proactively seek > implementation support for modifiers.   If we push hard maybe we can get > modifiers in time not to have to go round the houses with pragmas. > > The only thing I'd like to add to the proposal is the specific modifier > design.  What is the modifier name?  From which module is the modifier > exported.  That way when we get modifiers we don't have to start a new > debate. I think there is a debate to be had about whether modifiers are really the best approach in general. Is the lack of motivation to implement then a sign that we don't really need them? > On Thu, 8 Dec 2022 at 17:01, Arnaud Spiwack > wrote: > > It seems to me that the only motivation for this proposal is for > Template Haskell generated code. So maybe we can imagine an > alternative that is purely in Template Haskell, without any syntax. > Which would avoid the concerns about parsing pragmas*. Maybe there > is room, in this space, for a generic mechanism, but I don't think > that we'd need this: it makes sense to let the Template Haskell > slice decide if a record it defines generates selectors or not. > > That being said, I'm personally ok with the proposal as it stands, I > think it makes sense. But it's likely that a pure Template Haskell > solution may be both more forward compatible and easier to implement > (at least, based on Vlad estimate, who knows this part of the code, > I'm inclined to believe so). As there doesn't seem to be any > particular motivation beyond Template Haskell, I'd be ok if we made > this counter-proposal. > > I don't think counterargument 4 is something we can oppose: it is > theoretically possible to define the doppelgänger record in a > separate module, but we know it won't happen. Matt Parsons mentions > the Esqueleto library, it is obvious that the library will prefer > using a silly name for record fields  rather than ask its users to > move definitions to another module and the library will be right: it > is less obnoxious. > > All in all, I think that the proposal is quite reasonable, and would > open space in the design of Template-Haskell based libraries. > > * For the record, I don't think that we can claim that pragmas can > be ignored semantically. The OVERLAPPING pragma is a > counter-example. Maybe more acutely: the LANGUAGE pragma. So I don't > agree with counterargument 3. > > On Wed, 30 Nov 2022 at 22:18, Adam Gundry > wrote: > > On 30/11/2022 20:37, Joachim Breitner wrote: > > Hi, > > > > Am Mittwoch, dem 30.11.2022 um 19:28 +0000 schrieb Adam Gundry: > >> What do you think? > > > > my initial feeling about `language … where …` is that it is a > modifer > > of sorts, however > >   * with a syntax that may not scale well (hard to target > anything > >     but a whole set of declarations) > >   * looks like it could support any kind of language > extension, when > >     it probably doesn’t make sense for all of them. > > so may not gain much over implementing (parts) of the > modifier syntax. > > Well, I find it hard to imagine really needing to enable an > extension > for anything smaller than a declaration group. On the other > hand, I not > infrequently want to enable particular extensions only for a few > specific definitions (AllowAmbiguousTypes comes to mind). > > As I understand it, modifiers need to be type-checked before > they have > meaning assigned. This presumably means they cannot change the > behaviour > of the parser, whereas an explicit "language ... where ..." > construct > could do so. And I don't think modifiers can scope over a > declaration > group, only a single declaration? > > I agree that we wouldn't necessarily support *all* language > extensions > locally, but I think the list for which this fundamentally does > not make > sense is relatively short (the main ones that come to mind are > import-related extensions such as ExplicitNamespaces). Others > might be > hard to specify/implement (e.g. Safe Haskell seems tricky) but > we could > simply not support them locally. > > > > ... > > > > Or we revive local modules, and use that as a then natural way of > > scoping language pragmas… > > There's clearly a relationship to local modules, but that seems > like > more complexity than we need for the problem at hand. I don't > see why we > shouldn't add "language ... where ..." now, then potentially later > support local (or top-level!) modules with > >    language Blah where >      module M where >        ... > > After all, {-# LANGUAGE #-} pragmas violate the principle that > pragmas > shouldn't change semantics. ;-) > > Cheers, > > Adam > -- Adam Gundry, Haskell Consultant Well-Typed LLP, https://www.well-typed.com/ Registered in England & Wales, OC335890 27 Old Gloucester Street, London WC1N 3AX, England From adam at well-typed.com Fri Dec 9 10:44:53 2022 From: adam at well-typed.com (Adam Gundry) Date: Fri, 9 Dec 2022 10:44:53 +0000 Subject: [ghc-steering-committee] Why not?, rather than, why? In-Reply-To: References: <10594AD6-665D-4674-8E96-78AB6C61973A@chrisdornan.com> <6D754A68-7BC5-48AF-A6A8-B307D9FD02EB@chrisdornan.com> Message-ID: I'm not convinced we should strive to eliminate all extensions as either "successful" (part of the default language), or "failed" experiments (deprecated and perhaps eventually removed). While it is surely good to reduce the proliferation of extensions that can itself be a source of confusion, there are still benefits to distinguishing "language levels". The right choice of language features can be context dependent, and invoking more powerful features is always a trade-off, so I think it is a positive virtue that LANGUAGE pragmas let us pass that choice to users/codebases. AntC made a good comment to this effect at https://github.com/ghc-proposals/ghc-proposals/pull/559#issuecomment-1336059655. By all means let's reduce the number of trivial syntactic extensions that exist primarily for backwards compatibility purposes. But for semantically meaningful extensions, I would rather make the ability to choose language features even more local, so that a user can tightly constrain their use to where they are needed, for example: module M where -- I would like GHC to complain if I accidentally risk compile time -- non-termination with this instance... instance ... => Foo T -- but for this one I need to lift the check, and have accepted the -- corresponding responsibility to ensure the instance is sensible. language UndecidableInstances where instance ... => Bar T Cheers, Adam On 08/12/2022 17:53, Simon Peyton Jones wrote: > The choice can be:... > My point is: we need to take an explicit stance and record it. > > > Do you want to lay out > * the problem you want to solve > * a set of possible choices that might solve it > > Personally I don't perceive an immediate problem that we need to solve. > But I'm an outlier and willing to be educated. > > > > On Thu, 8 Dec 2022 at 17:30, Arnaud Spiwack > wrote: > > Personally, my concern is primarily procedural. There is no official > stance on what an extension can be, so different people map > different concepts on them. As a result, we have a lot of > conversations (in here, in proposal threads) where everybody speaks > past one another. What I would like is that we come together and > design a principle saying: we strive for future extensions to be X. > This would clarify discussions around > - Is a new extension X appropriate? > - Should extension X imply extension Y? > - Should extension X be included in GHC20XX? > > My personal (strong) preference is for striving for extensions to > either become a default, eventually, or to be deprecated. It also > seems to be the preference of most of those who spoke up here. But > what really matters is that we make a choice. The choice can be: “An > extension is a switch that triggers optional behaviour in the > language, it can be used to gate advanced features, some (but > probably not all) of these extensions will become defaults if their > use is generalised enough”, I'd disagree with the choice, but I'd > champion it anyway. Note that this option is compatible with the > no-language-fork principle. > > My point is: we need to take an explicit stance and record it. > > /Arnaud > > On Mon, 5 Dec 2022 at 22:03, Chris Dornan > wrote: > > Now I am sorry — my tongue was in my cheek in talking about the > thread taking an authoritarian turn! > > I think we can al agree that there is a cost to adding more and > more extensions, and bear the mounting complexity in mind when > scrutinising these proposals, and try to steer this review > process towards a coherent future language. At least that is my > understanding of the spirit of what Joachim is getting at when > he initiated this thread, in which case count me in. My point is > just that we don’t also forget certain necessary messy realities > in attempting to unwind ourselves from the ‘excessive’ > complexity that our open, experimental philosophy/DNA will tend > to generate. > > I would love to here more from Simon venting on what needs to > happen, ideally down the pub, but, more practically, we might > have to make do with a virtual one… > > Chris > > >> On 5 Dec 2022, at 19:03, Simon Marlow > > wrote: >> >> Apologies, I didn't mean to sound like I wanted us to be >> "authoritarian", perhaps more along the lines of >> "opinionated". By analogy with the CLC: they are forced to >> make decisions, because there is only one set of core >> libraries. I don't necessarily agree with all the decisions >> that the CLC makes, but I'm very glad we only have one set of >> core libraries. >> >> In GHC we have the dubious luxury of being able to give people >> optional language features, I'm suggesting we should use this >> very carefully and avoid forks - which is our current policy >> anyway - but to be more intentional about it in the way that >> Joachim suggested. I'm also a fan of an open platform that >> encourages experimentation, but at some point we have to >> accept (I believe) that too much of this leads to a poor >> experience for new users. (that's putting it gently! I'm >> itching to rant about this some more, but I fear it may come >> across poorly. One for the pub.) >> >> Cheers >> Simon >> >> On Fri, 2 Dec 2022 at 19:04, Chris Dornan >> > wrote: >> >> I think we are on the same page, but the thread seemed to >> be taking an authoritarian turn so I thought it best to >> ensure the voices of caution were represented! >> >> Chris >> >> > On 2 Dec 2022, at 17:39, Joachim Breitner >> > > wrote: >> > >> > Hi, >> > >> > Am Freitag, dem 02.12.2022 um 17:27 +0000 schrieb Chris >> Dornan: >> >> I am sympathetic to the idea of a new language standard >> that we >> >> promote heavily and encourage developers, tools, >> tutorials and >> >> courseware to favour —if we get this right then we will >> reap the >> >> benefits of a strong standard. But if we take it upon >> ourselves to >> >> try and force an extension combination of our choosing >> on the >> >> community because we believe the community will benefit >> from a big >> >> reset then I think it could blow up on us really badly, >> with forks >> >> and factions which could be truly difficult to manage — >> and fatally >> >> discourage adoption. >> > >> > ah, sorry if I was unclear. I am certainly not proposing >> a form of “big >> > reset”!  It’s more about “should every language >> extension be in >> > principle on track towards in inclusion to a future >> GHC20xx” – still >> > all incremental and cautious. >> > >> > Cheers, >> > Joachim -- 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 adam at well-typed.com Fri Dec 9 11:11:04 2022 From: adam at well-typed.com (Adam Gundry) Date: Fri, 9 Dec 2022 11:11:04 +0000 Subject: [ghc-steering-committee] Proposal #270: Support pun-free code. Recommendation: accept In-Reply-To: References: <5D0E3610-C73F-4850-9435-8D22069382BD@chrisdornan.com> <2da00f7f92f292bb16a4dfc53ec62d68ecf6edc9.camel@joachim-breitner.de> <3267a53a47cec3597c54bab8f8518b2c1613e1a8.camel@joachim-breitner.de> Message-ID: <0e9b3372-5034-f596-acd2-aecc3c7be701@well-typed.com> I'm broadly in favour of accepting the proposal. I realise the history is complex here, so I don't think we should ask anyone to rewrite things further, though in general it would be nicer to have separate proposals for -Wpuns/-Wpun-bindings (which is unambiguously fine) and for the changes to imports (which as Joachim points out raise issues). I'm a bit concerned that the proposal does not motivate or specify -Wpattern-namespace-qualified very well. On 08/12/2022 08:33, Joachim Breitner wrote: > ... > > This gives us (at least) these options: > > 1. Leave ExplicitNamespaces alone, add ExplicitNamespaces to GHC2023, > introduce one or two new extensions for the newer changes. > 2. Extend ExplicitNamespaces, and don’t add it already to GHC2023, > disregarding issue #551. > 3. Add ExplicitNamespaces to GHC2023, and still add it to GHC2023, > arguing that GHC20xx allows more liberal (backward-compatibile) > changes than, say, Haskell2010 would allow. > > Certainly 1 is the least bold move. I am not sure what the best way > forwards is, and welcome other opinions. I would prefer a variant of 1: allow "data" as a keyword in import lists under ExplicitNamespaces, but make the other changes under other extensions. As I've said previously, I have a general preference for multiple small, orthogonal extensions rather than changing existing extensions to add unrelated features that happen to be in similar territory. I realise this is controversial, of course. Cheers, Adam -- Adam Gundry, Haskell Consultant Well-Typed LLP, https://www.well-typed.com/ Registered in England & Wales, OC335890 27 Old Gloucester Street, London WC1N 3AX, England From simon.peytonjones at gmail.com Fri Dec 9 12:38:26 2022 From: simon.peytonjones at gmail.com (Simon Peyton Jones) Date: Fri, 9 Dec 2022 12:38:26 +0000 Subject: [ghc-steering-committee] #512: NoFieldSelectors as datatype annotation, Recommendation: reject In-Reply-To: <9484dee9-2d77-98ae-5b4d-ebc51f19cb24@well-typed.com> References: <494656e83f8d1486621fab153ed8f85f13b82e1b.camel@joachim-breitner.de> <414422bd-7085-f244-626a-19711dfd0692@well-typed.com> <02620ae95fb4d0a07172c06ffa83281d293e4149.camel@joachim-breitner.de> <451cf30d-8fc6-a052-0c3d-707b5f7fbc92@well-typed.com> <9484dee9-2d77-98ae-5b4d-ebc51f19cb24@well-typed.com> Message-ID: > > I think there is a debate to be had about whether modifiers are really > the best approach in general. Is the lack of motivation to implement > then a sign that we don't really need them > We can always re-open an accepted proposal , especially if it is not yet implemented! The motivations for modifiers I see are: - We have modifiers for linear types - It seem wrong to use pragmas (in {-# #-} comments) for things that are semantically meaningful like overlapping instances. We definitely want modifiers *in some form*. We currently use them a lot for {-# OVERLAPPABLE #-} etc. We *could *stick with the {-# prag #-} syntax. But it's a bit noisy, and it really isn't a comment. And (unlike the modifier) the pragma stuff doesn't have internal structure -- we could not use it for linear annotations. But I think we should decide what syntax we want for modifier-like things, and get it implemented, else it'll keep blocking other proposals, like this one from Matthew. Simon On Fri, 9 Dec 2022 at 08:18, Adam Gundry wrote: > On 09/12/2022 07:38, Simon Peyton Jones wrote: > > It seems to me that the only motivation for this proposal is for > > Template Haskell generated code > > > > > > I don't think so. Michael suggested another > > > > Another motivation: today it's generally considered Bad Practice to > > use record syntax for the constructors of datatypes with > > alternatives, because this generates partial field accessors. With > > NoFieldSelectors, we can avoid this, but at the cost of turning off > > field selector generation for the entire module, which we might not > > want. Being able to control field selector generation on a > > per-datatype level lets you use this trick while keeping other > > "normal" records the same. > > > > I think this proposal is generally a good idea. > > I agree with Simon here: the motivation for this proposal is wider than > just with TH. It will be useful to be able to explore designs where a > single module includes one record datatype with selectors, and other > datatypes that use the same field names but not selectors. Those might > be TH-generated, but need not be in general. > > Moreover, I think it would be problematic to have features that are > available only via TH splices and that cannot be translated to the > underlying declarations. As a user I expect to be able to expand spliced > declarations, and some users rely on this (e.g. to support > cross-compilation scenarios where TH support is tricky). > > > > If we have NoRecrodSelectors at all we should have it on a > > per-data-type basis. > > Agreed. But what about per-field or per-constructor? The proposal allows > these but I'm not convinced we need more than per-datatype, and that > would reduce complexity. > > > > I am exercised about the modifiers problem If we had modifiers we'd > > definitely use them. Using pragmas temporarily adds friction because > > we'll have to go through deprecation cycles to get rid of them. > > > > I think we should accept the proposal, but also proactively seek > > implementation support for modifiers. If we push hard maybe we can get > > modifiers in time not to have to go round the houses with pragmas. > > > > The only thing I'd like to add to the proposal is the specific modifier > > design. What is the modifier name? From which module is the modifier > > exported. That way when we get modifiers we don't have to start a new > > debate. > > I think there is a debate to be had about whether modifiers are really > the best approach in general. Is the lack of motivation to implement > then a sign that we don't really need them? > > > > On Thu, 8 Dec 2022 at 17:01, Arnaud Spiwack > > wrote: > > > > It seems to me that the only motivation for this proposal is for > > Template Haskell generated code. So maybe we can imagine an > > alternative that is purely in Template Haskell, without any syntax. > > Which would avoid the concerns about parsing pragmas*. Maybe there > > is room, in this space, for a generic mechanism, but I don't think > > that we'd need this: it makes sense to let the Template Haskell > > slice decide if a record it defines generates selectors or not. > > > > That being said, I'm personally ok with the proposal as it stands, I > > think it makes sense. But it's likely that a pure Template Haskell > > solution may be both more forward compatible and easier to implement > > (at least, based on Vlad estimate, who knows this part of the code, > > I'm inclined to believe so). As there doesn't seem to be any > > particular motivation beyond Template Haskell, I'd be ok if we made > > this counter-proposal. > > > > I don't think counterargument 4 is something we can oppose: it is > > theoretically possible to define the doppelgänger record in a > > separate module, but we know it won't happen. Matt Parsons mentions > > the Esqueleto library, it is obvious that the library will prefer > > using a silly name for record fields rather than ask its users to > > move definitions to another module and the library will be right: it > > is less obnoxious. > > > > All in all, I think that the proposal is quite reasonable, and would > > open space in the design of Template-Haskell based libraries. > > > > * For the record, I don't think that we can claim that pragmas can > > be ignored semantically. The OVERLAPPING pragma is a > > counter-example. Maybe more acutely: the LANGUAGE pragma. So I don't > > agree with counterargument 3. > > > > On Wed, 30 Nov 2022 at 22:18, Adam Gundry > > wrote: > > > > On 30/11/2022 20:37, Joachim Breitner wrote: > > > Hi, > > > > > > Am Mittwoch, dem 30.11.2022 um 19:28 +0000 schrieb Adam > Gundry: > > >> What do you think? > > > > > > my initial feeling about `language … where …` is that it is a > > modifer > > > of sorts, however > > > * with a syntax that may not scale well (hard to target > > anything > > > but a whole set of declarations) > > > * looks like it could support any kind of language > > extension, when > > > it probably doesn’t make sense for all of them. > > > so may not gain much over implementing (parts) of the > > modifier syntax. > > > > Well, I find it hard to imagine really needing to enable an > > extension > > for anything smaller than a declaration group. On the other > > hand, I not > > infrequently want to enable particular extensions only for a few > > specific definitions (AllowAmbiguousTypes comes to mind). > > > > As I understand it, modifiers need to be type-checked before > > they have > > meaning assigned. This presumably means they cannot change the > > behaviour > > of the parser, whereas an explicit "language ... where ..." > > construct > > could do so. And I don't think modifiers can scope over a > > declaration > > group, only a single declaration? > > > > I agree that we wouldn't necessarily support *all* language > > extensions > > locally, but I think the list for which this fundamentally does > > not make > > sense is relatively short (the main ones that come to mind are > > import-related extensions such as ExplicitNamespaces). Others > > might be > > hard to specify/implement (e.g. Safe Haskell seems tricky) but > > we could > > simply not support them locally. > > > > > > > ... > > > > > > Or we revive local modules, and use that as a then natural > way of > > > scoping language pragmas… > > > > There's clearly a relationship to local modules, but that seems > > like > > more complexity than we need for the problem at hand. I don't > > see why we > > shouldn't add "language ... where ..." now, then potentially > later > > support local (or top-level!) modules with > > > > language Blah where > > module M where > > ... > > > > After all, {-# LANGUAGE #-} pragmas violate the principle that > > pragmas > > shouldn't change semantics. ;-) > > > > Cheers, > > > > Adam > > > > > -- > Adam Gundry, Haskell Consultant > Well-Typed LLP, https://www.well-typed.com/ > > Registered in England & Wales, OC335890 > 27 Old Gloucester Street, London WC1N 3AX, England > > _______________________________________________ > ghc-steering-committee mailing list > ghc-steering-committee at haskell.org > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lists at richarde.dev Fri Dec 9 14:21:47 2022 From: lists at richarde.dev (Richard Eisenberg) Date: Fri, 9 Dec 2022 14:21:47 +0000 Subject: [ghc-steering-committee] Why not?, rather than, why? In-Reply-To: References: <10594AD6-665D-4674-8E96-78AB6C61973A@chrisdornan.com> <6D754A68-7BC5-48AF-A6A8-B307D9FD02EB@chrisdornan.com> Message-ID: <010f0184f74380f9-b587b4d5-59af-4f09-8efe-4ad1745243ce-000000@us-east-2.amazonses.com> I have divided this email into two parts. The first part presents what are my observations of this (and related) conversation. Then I share my opinion in the second part. > On Dec 8, 2022, at 12:53 PM, Simon Peyton Jones wrote: > > * the problem you want to solve We, as a committee, struggle to figure out a policy around extensions. This policy would help inform decisions such as: * whether proposal X needs to come with an extension, can modify a previous one, or needs no extension at all * how to evolve the set of extensions that are part of GHC20XX / the default set of extensions Beyond these real-world challenges that the committee has faced, we might also want to consider * how better to communicate the role extensions play in the Haskell language (anecdotes suggest the current story is off-putting to newcomers) * whether some extensions ought to be retired While all decisions would continue to be made on a case-by-case basis, discussions in the past have suggested that individual members have very different criteria for making these calls, stymieing effective debate. Thus the problem is that we, the committee, don't have common goals for the extensions feature of the language. Accordingly, our decisions in this space easily risk being incoherent, which is a problem. > * a set of possible choices that might solve it I spot several solutions drawn from our conversations: 1. Declare that extensions are experimental language features, being evaluated for inclusion in the language proper. Gating some new syntax behind an extension theoretically allows us to experiment, improve, etc., until we are happy, and then we merge the feature into the language, with no extension needed. 2. Declare that extensions are configuration flags, meant to exist in perpetuity. In this way, extensions are a more powerful form of warning flag: not only can they dictate which programs are accepted, but sometimes they can be used to change the semantics of an accepted program. 3. Organize the set of extensions around an idea of language levels, where we classify different extensions according to the expected level of expertise of users working in the extended language. The levels themselves would exist in perpetuity, but the extensions themselves may eventually just be folded into the choice of language level. This is something of a hybrid between (1) and (2). Perhaps others have other ideas, but I hope I've captured the different approaches floated so far. Given the fact that we're working in an existing language, we have to incorporate the reality of today's Haskell: some existing language extensions are unmistakably configuration flags (e.g. RebindableSyntax, Safe) which could never reasonably be on by default. I urge us not to get caught on these snags. Once we have a general approach, we can come back to these if necessary and see how to incorporate them. ------------------------- I used to be in Camp 2, thinking that extensions make for good configuration flags, and would exist in perpetuity -- or at least until a standards committee forms and writes the next version of the standard. I've now switched over to Camp 1. The extensions system continues to grow without seeming bound. This fragments our community somewhat (think of the various exhortations to only use these extensions), provides a source of unnecessary and bureaucratic complexity to users, and means that language maintainers must consider 2^n languages. (When I last counted, n was around 150. It may have grown since.) What does it even mean that a language has a core and has extensions? We could argue that the unextended language is Haskell2010, but I don't think that's a useful designation in 2022. So why have the distinction between a core and an extension? I'm honestly not sure what the value is there. And I think the current state of this actively harms the language. Glancing through the list of extensions, I see a few broad categories: A. Extensions that simply enable new syntax. If users still want fine control over whether this syntax is allowed, each such extension could be converted to a warning -- but then all these extensions (except ones that are still experimental!) would be on by default. Maybe the warnings would be -Werror by default -- not sure. Examples: GADTSyntax, Arrows, InstanceSigs, StandaloneDeriving, and many more. B. Extensions that allow violation of some general principle that holds elsewhere. These should be replaced by modifiers or pragmas and be enabled locally. Examples: OverlappingInstances (this is already done!), NoMonomorphismRestriction, DeepSubsumption(*), UndecidableSuperClasses, NoMonoLocalBinds, etc. (*): Given the hue and cry about this one, perhaps there should be a flag to control the behavior. C. Extensions that change the compilation pipeline. These need to remain as configuration flags. Examples: CPP, TemplateHaskell. D. Extensions that create variants of the language by changing semantics of existing constructs. I'm not quite sure what to do with these, but they probably need to remain configuration flags. Even better if they could be enabled locally within a file, though. We should probably try to avoid doing this in the future, though the pain may be worth it. Examples: RebindableSyntax, Strict, OverloadedXXX, etc. Maybe some extensions fail to be categorized here, but this covers the vast, vast majority. About language levels: I like the idea of language levels. But I would want them to be mostly about error messages, not about gating language features. That is, at level 1, `x :: Just Int` wouldn't get "Did you want to turn on DataKinds?" but instead a message about confusing types and terms. So it's possible to do the language-level idea without hooking it to extensions. I think. Richard -------------- next part -------------- An HTML attachment was scrubbed... URL: From mail at joachim-breitner.de Fri Dec 9 18:31:30 2022 From: mail at joachim-breitner.de (Joachim Breitner) Date: Fri, 09 Dec 2022 19:31:30 +0100 Subject: [ghc-steering-committee] #541: WARNING pragma with category, Recommendation: accept In-Reply-To: References: <96101967a640825f61e52c2aae6c29dd5186f3ff.camel@joachim-breitner.de> <010f01849a416c75-213361ee-7955-487e-a782-cda06d19b1dd-000000@us-east-2.amazonses.com> <68516f416714774cf430daf762a2f0b616b6230b.camel@joachim-breitner.de> Message-ID: <8e8c16f13f955cda49a895fbc8378541db3fdc82.camel@joachim-breitner.de> Hi, Am Dienstag, dem 29.11.2022 um 17:14 +0100 schrieb Joachim Breitner: > Happy to hear more voices and accept with whatever the majority of > voices said they’d prefer (without formal votes, doesn’t seem to be > worth it), assuming nobody thinks either way is a showstopper. didn’t hear more on this issue. If silence continues for a few more days, I’ll accept it (in the current variant ({-# WARNING [x-partial] #-}), by popular vote). Cheers, Joachim -- Joachim Breitner mail at joachim-breitner.de http://www.joachim-breitner.de/ From mail at joachim-breitner.de Fri Dec 9 18:47:13 2022 From: mail at joachim-breitner.de (Joachim Breitner) Date: Fri, 09 Dec 2022 19:47:13 +0100 Subject: [ghc-steering-committee] Modifiers (Was: #512: NoFieldSelectors as datatype annotation) In-Reply-To: References: <494656e83f8d1486621fab153ed8f85f13b82e1b.camel@joachim-breitner.de> <414422bd-7085-f244-626a-19711dfd0692@well-typed.com> <02620ae95fb4d0a07172c06ffa83281d293e4149.camel@joachim-breitner.de> <451cf30d-8fc6-a052-0c3d-707b5f7fbc92@well-typed.com> <9484dee9-2d77-98ae-5b4d-ebc51f19cb24@well-typed.com> Message-ID: Hi, Am Freitag, dem 09.12.2022 um 12:38 +0000 schrieb Simon Peyton Jones: > > We can always re-open an accepted proposal, especially if it is not > yet implemented! > > The motivations for modifiers I see are: >  * We have modifiers for linear types >  * It seem wrong to use pragmas (in {-# #-} comments) for things that > are semantically meaningful like overlapping instances. > We definitely want modifiers in some form.  We currently use them a > lot for {-# OVERLAPPABLE #-} etc.  We could stick with the {-# prag > #-} syntax.  But it's a bit noisy, and it really isn't a comment.  > And (unlike the modifier) the pragma stuff doesn't have internal > structure -- we could not use it for linear annotations. > > But I think we should decide what syntax we want for modifier-like > things, and get it implemented, else it'll keep blocking other > proposals, like this one from Matthew. I was more quiet during the modifier discussion than I should have, but if we are opening this box again, I can share why I don’t feel to confident about it: * Tying modifiers to types rules out their use for every feature that is relevant before type-checking (parsing, renaming…) For example, imagine we only had unqualified imports, and now want to add qualified imports. This feels like a “modification” to me, and a good “modifier syntax” scheme should be able to accommodate  it. But it affects renaming, and thus wouldn’t work with a type- based thing. * The syntax might be too clumsy. Consider, again, adding qualified imports to the syntax: We’d have to specify an optional parameter (for the `qualified as Foo` part). How would that look like in Type syntax? Would the qualifier be data Quantified = Quantified (Maybe String) and you need to write Nothing or Just? And quote the name? Even linear types, listed as one of the motivations, really wants to have a nice syntax for the linear arrow, doesn’t it? I expect that many future modifiers on syntax benefit from custom syntax to be ergonomic and preserve the aesthetics of Haskell code. TL;DR: I doubt that a one-scheme-fits all, type-based modifier syntax covers enough use-cases to pay its weight, and am leaning towards “just” coming up with custom syntax for new features (likely with new context-dependent keywords where possible – as in deriving via).  Cheers, Joachim -- Joachim Breitner mail at joachim-breitner.de http://www.joachim-breitner.de/ From mail at joachim-breitner.de Fri Dec 9 18:57:27 2022 From: mail at joachim-breitner.de (Joachim Breitner) Date: Fri, 09 Dec 2022 19:57:27 +0100 Subject: [ghc-steering-committee] Why not?, rather than, why? In-Reply-To: <010f0184f74380f9-b587b4d5-59af-4f09-8efe-4ad1745243ce-000000@us-east-2.amazonses.com> References: <10594AD6-665D-4674-8E96-78AB6C61973A@chrisdornan.com> <6D754A68-7BC5-48AF-A6A8-B307D9FD02EB@chrisdornan.com> <010f0184f74380f9-b587b4d5-59af-4f09-8efe-4ad1745243ce-000000@us-east-2.amazonses.com> Message-ID: Hi, this categorization is very helpful, I’ve been thinking about that as well recently. Especially it’s worth keeping in mind that some language extensions probably wouldn’t be language extensions these days, but some other kind of flag (CPP, Safe, Trustworthy), and as you say shouldn’t get in the way of finding a more coherent story for the others. I think we should keep separate the category F: Enables new language features with not just a local (usually) syntactic effect. (Litmus test: will a user of a module with that extension tell). Mostly all the type-level feature extension (GADTs, LinearTypes, TypeFamilies etc.) Some of these are also guarded by “new syntax” of sorts, but I think they are fundamentally different from your category A. These are, in a way, the most interesting ones! Cheers, Joachim Am Freitag, dem 09.12.2022 um 14:21 +0000 schrieb Richard Eisenberg: > Glancing through the list of extensions, I see a few broad > categories: > > A. Extensions that simply enable new syntax. If users still want fine > control over whether this syntax is allowed, each such extension > could be converted to a warning -- but then all these extensions > (except ones that are still experimental!) would be on by default. > Maybe the warnings would be -Werror by default -- not sure. Examples: > GADTSyntax, Arrows, InstanceSigs, StandaloneDeriving, and many more. > > B. Extensions that allow violation of some general principle that > holds elsewhere. These should be replaced by modifiers or pragmas and > be enabled locally. Examples: OverlappingInstances (this is already > done!), NoMonomorphismRestriction, DeepSubsumption(*), > UndecidableSuperClasses, NoMonoLocalBinds, etc. > > (*): Given the hue and cry about this one, perhaps there should be a > flag to control the behavior. > > C. Extensions that change the compilation pipeline. These need to > remain as configuration flags. Examples: CPP, TemplateHaskell. > > D. Extensions that create variants of the language by changing > semantics of existing constructs. I'm not quite sure what to do with > these, but they probably need to remain configuration flags. Even > better if they could be enabled locally within a file, though. We > should probably try to avoid doing this in the future, though the > pain may be worth it. Examples: RebindableSyntax, Strict, > OverloadedXXX, etc. > > Maybe some extensions fail to be categorized here, but this covers > the vast, vast majority. -- Joachim Breitner mail at joachim-breitner.de http://www.joachim-breitner.de/ From mail at joachim-breitner.de Fri Dec 9 19:01:14 2022 From: mail at joachim-breitner.de (Joachim Breitner) Date: Fri, 09 Dec 2022 20:01:14 +0100 Subject: [ghc-steering-committee] Please review #546: Make Symbol a newtype over String, Shepherd: Chris In-Reply-To: <7590f16bfc68285b7803ac82ea7e77285a336460.camel@joachim-breitner.de> References: <555dcb045377d7eb674c5656ecdb47904f5bdbaf.camel@joachim-breitner.de> <7590f16bfc68285b7803ac82ea7e77285a336460.camel@joachim-breitner.de> Message-ID: <144726f8466b6b248f4851d69c2d8b73e1e8500a.camel@joachim-breitner.de> Hi, Am Freitag, dem 18.11.2022 um 09:20 +0100 schrieb Joachim Breitner: > Make Symbol a newtype over String > has been proposed by Oleg Grenus > > https://github.com/ghc-proposals/ghc-proposals/pull/546 > https://github.com/phadej/ghc-proposals/blob/symbol-type/proposals/0000-symbol-newtype-string.rst > > I suggest Chris Dornan shepherds this proposal. the authors has ran out of patience with our silence, and bureaucratic comments that parts of it should maybe a CLC proposal, nd has given up on this proposal: https://github.com/ghc-proposals/ghc-proposals/pull/546#issuecomment-1344604917 Cheers, Joachim -- Joachim Breitner mail at joachim-breitner.de http://www.joachim-breitner.de/ From mail at joachim-breitner.de Fri Dec 9 19:07:07 2022 From: mail at joachim-breitner.de (Joachim Breitner) Date: Fri, 09 Dec 2022 20:07:07 +0100 Subject: [ghc-steering-committee] #556: multiple type variables in signatures in type applications in patterns, Recommendation: accept Message-ID: <79ba755953e991f061d3a6f4d82884a5c3b0c472.camel@joachim-breitner.de> Dear all, Vlad has submitted a bug fix amendment to #448, to fix the wording around type variables in signatures within explicit type annotations: https://github.com/ghc-proposals/ghc-proposals/pull/556/files I’m shepherding that one myself. The gist is that in data Proxy a = P g :: Proxy (Nothing @(a, a)) -> () g (P @(Nothing :: Maybe (x, x))) = () the multiple occurrences of `a` are non-linear patterns and disallowed, but the multiple patterns of `x` are fine, because that’s how type variables in signatures in patterns happen to work. Vlad fixed the wording with regard to that in #448. Simon and Richard already signaled support on the Github thread, which I recommend to follow. I don’t expect much further discussion around this and will happily merge after a week of silence (or after one or two additional confirmations). Cheers, Joachim -- Joachim Breitner mail at joachim-breitner.de http://www.joachim-breitner.de/ From mail at joachim-breitner.de Fri Dec 9 19:08:30 2022 From: mail at joachim-breitner.de (Joachim Breitner) Date: Fri, 09 Dec 2022 20:08:30 +0100 Subject: [ghc-steering-committee] #556: multiple type variables in signatures in type applications in patterns, Recommendation: accept In-Reply-To: <79ba755953e991f061d3a6f4d82884a5c3b0c472.camel@joachim-breitner.de> References: <79ba755953e991f061d3a6f4d82884a5c3b0c472.camel@joachim-breitner.de> Message-ID: <1390d977ff38c68b80eba189ec088ecd58ba8e83.camel@joachim-breitner.de> Hi, ignore this mail. This is already shepherded by Richard. (I was thrown off by his “I'm happy with the new wording and would support this in a committee vote.” which sounded like something someone would say who is not in the position to propose acceptance :-))) Cheers, Joachim Am Freitag, dem 09.12.2022 um 20:07 +0100 schrieb Joachim Breitner: > Dear all, > > Vlad has submitted a bug fix amendment to #448, to fix the wording around > type variables in signatures within explicit type annotations: > > https://github.com/ghc-proposals/ghc-proposals/pull/556/files > > I’m shepherding that one myself. > > The gist is that in > > data Proxy a = P > g :: Proxy (Nothing @(a, a)) -> () > g (P @(Nothing :: Maybe (x, x))) = () > > > the multiple occurrences of `a` are non-linear patterns and disallowed, > but the multiple patterns of `x` are fine, because that’s how type > variables in signatures in patterns happen to work. Vlad fixed the > wording with regard to that in #448. > > > Simon and Richard already signaled support on the Github thread, which > I recommend to follow. I don’t expect much further discussion around > this and will happily merge after a week of silence (or after one or > two additional confirmations). > > Cheers, > Joachim > > > -- Joachim Breitner mail at joachim-breitner.de http://www.joachim-breitner.de/ From mail at joachim-breitner.de Fri Dec 9 19:11:21 2022 From: mail at joachim-breitner.de (Joachim Breitner) Date: Fri, 09 Dec 2022 20:11:21 +0100 Subject: [ghc-steering-committee] Please review #523: let in types and patterns, Shepherd: Adam In-Reply-To: <555dcb045377d7eb674c5656ecdb47904f5bdbaf.camel@joachim-breitner.de> References: <555dcb045377d7eb674c5656ecdb47904f5bdbaf.camel@joachim-breitner.de> Message-ID: <5ace6f1be49b8d5cc143f929fc45f6e2797359a2.camel@joachim-breitner.de> Dear Committee, Richard submitted “let in types and patterns”, a left-over from #448: https://github.com/ghc-proposals/ghc-proposals/pull/523 https://github.com/goldfirere/ghc-proposals/blob/extended-let/proposals/0000-extended-let.rst I suggest Adam to shepherd this proposal: Please guide us to a conclusion as outlined in https://github.com/ghc-proposals/ghc-proposals#committee-process Cheers, Joachim -- Joachim Breitner mail at joachim-breitner.de http://www.joachim-breitner.de/ From chris at chrisdornan.com Fri Dec 9 19:46:58 2022 From: chris at chrisdornan.com (Chris Dornan) Date: Fri, 9 Dec 2022 19:46:58 +0000 Subject: [ghc-steering-committee] Please review #546: Make Symbol a newtype over String, Shepherd: Chris In-Reply-To: <144726f8466b6b248f4851d69c2d8b73e1e8500a.camel@joachim-breitner.de> References: <555dcb045377d7eb674c5656ecdb47904f5bdbaf.camel@joachim-breitner.de> <7590f16bfc68285b7803ac82ea7e77285a336460.camel@joachim-breitner.de> <144726f8466b6b248f4851d69c2d8b73e1e8500a.camel@joachim-breitner.de> Message-ID: <32E74F1C-736A-4BF0-B906-57A60912BC02@chrisdornan.com> I am sorry, this is on me. I have also apologised to Oleg in the thread. I was trying to close out #270 so I could give it my full attention but just as it seems headed for resolution more complications emerge. I have offered to try and make the process work for Oleg but failing that I will try and find a new sponsor as the proposal seemed to be worthy. Chris > On 9 Dec 2022, at 19:01, Joachim Breitner wrote: > > Hi, > > Am Freitag, dem 18.11.2022 um 09:20 +0100 schrieb Joachim Breitner: >> Make Symbol a newtype over String >> has been proposed by Oleg Grenus >> >> https://github.com/ghc-proposals/ghc-proposals/pull/546 >> https://github.com/phadej/ghc-proposals/blob/symbol-type/proposals/0000-symbol-newtype-string.rst >> >> I suggest Chris Dornan shepherds this proposal. > > > the authors has ran out of patience with our silence, and bureaucratic > comments that parts of it should maybe a CLC proposal, nd has given up > on this proposal: > https://github.com/ghc-proposals/ghc-proposals/pull/546#issuecomment-1344604917 > > Cheers, > Joachim > > -- > Joachim Breitner > mail at joachim-breitner.de > http://www.joachim-breitner.de/ > > _______________________________________________ > ghc-steering-committee mailing list > ghc-steering-committee at haskell.org > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee From adam at well-typed.com Mon Dec 12 09:15:07 2022 From: adam at well-typed.com (Adam Gundry) Date: Mon, 12 Dec 2022 09:15:07 +0000 Subject: [ghc-steering-committee] Proposal #270: Support pun-free code. Recommendation: accept In-Reply-To: <0e9b3372-5034-f596-acd2-aecc3c7be701@well-typed.com> References: <5D0E3610-C73F-4850-9435-8D22069382BD@chrisdornan.com> <2da00f7f92f292bb16a4dfc53ec62d68ecf6edc9.camel@joachim-breitner.de> <3267a53a47cec3597c54bab8f8518b2c1613e1a8.camel@joachim-breitner.de> <0e9b3372-5034-f596-acd2-aecc3c7be701@well-typed.com> Message-ID: <089f0c63-ed84-186f-6f70-0372b95e4c3e@well-typed.com> Actually, reading https://gitlab.haskell.org/ghc/ghc/-/issues/22581 I realised I'm unclear how the proposed extensions to ExplicitNamespaces are supposed to work. The existing situation is apparently that for a (non-punned) data constructor, it is possible to use either a pattern or type qualifier in an import list (presumably because DataKinds means the constructor is in scope at both the term and type levels), and the imported constructor is then usable in both contexts. For example, the following is accepted at present: module M where data T = MkT {-# LANGUAGE ExplicitNamespaces #-} module N where import M (T(type MkT)) -- NB "type" import of a data constructor v = MkT -- usage at term level The present proposal says "With type specified in the import, only identifiers belonging to the type namespace will be brought into the scope." I'm not exactly sure how to interpret this, does it mean the following alternative will be accepted or rejected? module N where import M type (MkT) v = MkT I'm worried we will end up with a situation where ExplicitNamespaces does subtly different things depending on the position of the keyword. In general, I don't feel the extensions to ExplicitNamespaces included in the proposal are very clearly specified. Given the discussion about exactly which parts belong to ExplicitNamespaces/PatternSynonyms versus separate extensions, perhaps we should accept the parts relating to -Wpuns/-Wpun-bindings, but ask for the ExplicitNamespaces changes to be proposed separately? Cheers, Adam On 09/12/2022 11:11, Adam Gundry wrote: > I'm broadly in favour of accepting the proposal. I realise the history > is complex here, so I don't think we should ask anyone to rewrite things > further, though in general it would be nicer to have separate proposals > for -Wpuns/-Wpun-bindings (which is unambiguously fine) and for the > changes to imports (which as Joachim points out raise issues). > > I'm a bit concerned that the proposal does not motivate or specify > -Wpattern-namespace-qualified very well. > > > On 08/12/2022 08:33, Joachim Breitner wrote: >> ... >> >> This gives us (at least) these options: >> >> 1. Leave ExplicitNamespaces alone, add ExplicitNamespaces to GHC2023, >>     introduce one or two new extensions for the newer changes. >> 2. Extend ExplicitNamespaces, and don’t add it already to GHC2023, >>     disregarding issue #551. >> 3. Add ExplicitNamespaces to GHC2023, and still add it to GHC2023, >>     arguing that GHC20xx allows more liberal (backward-compatibile) >>     changes than, say, Haskell2010 would allow. >> >> Certainly 1 is the least bold move. I am not sure what the best way >> forwards is, and welcome other opinions. > > I would prefer a variant of 1: allow "data" as a keyword in import lists > under ExplicitNamespaces, but make the other changes under other > extensions. > > As I've said previously, I have a general preference for multiple small, > orthogonal extensions rather than changing existing extensions to add > unrelated features that happen to be in similar territory. I realise > this is controversial, of course. > > Cheers, > > Adam > > -- Adam Gundry, Haskell Consultant Well-Typed LLP, https://www.well-typed.com/ Registered in England & Wales, OC335890 27 Old Gloucester Street, London WC1N 3AX, England From simon.peytonjones at gmail.com Mon Dec 12 11:39:29 2022 From: simon.peytonjones at gmail.com (Simon Peyton Jones) Date: Mon, 12 Dec 2022 11:39:29 +0000 Subject: [ghc-steering-committee] Proposal #270: Support pun-free code. Recommendation: accept In-Reply-To: <089f0c63-ed84-186f-6f70-0372b95e4c3e@well-typed.com> References: <5D0E3610-C73F-4850-9435-8D22069382BD@chrisdornan.com> <2da00f7f92f292bb16a4dfc53ec62d68ecf6edc9.camel@joachim-breitner.de> <3267a53a47cec3597c54bab8f8518b2c1613e1a8.camel@joachim-breitner.de> <0e9b3372-5034-f596-acd2-aecc3c7be701@well-typed.com> <089f0c63-ed84-186f-6f70-0372b95e4c3e@well-typed.com> Message-ID: > > {-# LANGUAGE ExplicitNamespaces #-} > module N where > import M (T(type MkT)) -- NB "type" import of a data constructor > v = MkT -- usage at term level > Crumbs. I had not realised the proposal is to allow *nested* uses of 'type' in import lists, as you show above. In general, I don't feel the extensions to ExplicitNamespaces included > in the proposal are very clearly specified. > Actually isn't the proposal pretty clear on this, namely the first bullet of proposed change spec . It only covers import M *type * import M *data *as MD where I have emboldened the new bits. Nothing about the contents of import lists. Why did you think your example is covered by the proposal? Simon On Mon, 12 Dec 2022 at 09:15, Adam Gundry wrote: > Actually, reading https://gitlab.haskell.org/ghc/ghc/-/issues/22581 I > realised I'm unclear how the proposed extensions to ExplicitNamespaces > are supposed to work. The existing situation is apparently that for a > (non-punned) data constructor, it is possible to use either a pattern or > type qualifier in an import list (presumably because DataKinds means the > constructor is in scope at both the term and type levels), and the > imported constructor is then usable in both contexts. > > For example, the following is accepted at present: > > module M where > data T = MkT > > {-# LANGUAGE ExplicitNamespaces #-} > module N where > import M (T(type MkT)) -- NB "type" import of a data constructor > v = MkT -- usage at term level > > The present proposal says "With type specified in the import, only > identifiers belonging to the type namespace will be brought into the > scope." I'm not exactly sure how to interpret this, does it mean the > following alternative will be accepted or rejected? > > module N where > import M type (MkT) > v = MkT > > I'm worried we will end up with a situation where ExplicitNamespaces > does subtly different things depending on the position of the keyword. > > In general, I don't feel the extensions to ExplicitNamespaces included > in the proposal are very clearly specified. Given the discussion about > exactly which parts belong to ExplicitNamespaces/PatternSynonyms versus > separate extensions, perhaps we should accept the parts relating to > -Wpuns/-Wpun-bindings, but ask for the ExplicitNamespaces changes to be > proposed separately? > > Cheers, > > Adam > > > On 09/12/2022 11:11, Adam Gundry wrote: > > I'm broadly in favour of accepting the proposal. I realise the history > > is complex here, so I don't think we should ask anyone to rewrite things > > further, though in general it would be nicer to have separate proposals > > for -Wpuns/-Wpun-bindings (which is unambiguously fine) and for the > > changes to imports (which as Joachim points out raise issues). > > > > I'm a bit concerned that the proposal does not motivate or specify > > -Wpattern-namespace-qualified very well. > > > > > > On 08/12/2022 08:33, Joachim Breitner wrote: > >> ... > >> > >> This gives us (at least) these options: > >> > >> 1. Leave ExplicitNamespaces alone, add ExplicitNamespaces to GHC2023, > >> introduce one or two new extensions for the newer changes. > >> 2. Extend ExplicitNamespaces, and don’t add it already to GHC2023, > >> disregarding issue #551. > >> 3. Add ExplicitNamespaces to GHC2023, and still add it to GHC2023, > >> arguing that GHC20xx allows more liberal (backward-compatibile) > >> changes than, say, Haskell2010 would allow. > >> > >> Certainly 1 is the least bold move. I am not sure what the best way > >> forwards is, and welcome other opinions. > > > > I would prefer a variant of 1: allow "data" as a keyword in import lists > > under ExplicitNamespaces, but make the other changes under other > > extensions. > > > > As I've said previously, I have a general preference for multiple small, > > orthogonal extensions rather than changing existing extensions to add > > unrelated features that happen to be in similar territory. I realise > > this is controversial, of course. > > > > Cheers, > > > > Adam > > > > > > -- > Adam Gundry, Haskell Consultant > Well-Typed LLP, https://www.well-typed.com/ > > Registered in England & Wales, OC335890 > 27 Old Gloucester Street, London WC1N 3AX, England > > _______________________________________________ > ghc-steering-committee mailing list > ghc-steering-committee at haskell.org > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee > -------------- next part -------------- An HTML attachment was scrubbed... URL: From adam at well-typed.com Mon Dec 12 12:21:53 2022 From: adam at well-typed.com (Adam Gundry) Date: Mon, 12 Dec 2022 12:21:53 +0000 Subject: [ghc-steering-committee] Proposal #270: Support pun-free code. Recommendation: accept In-Reply-To: References: <5D0E3610-C73F-4850-9435-8D22069382BD@chrisdornan.com> <2da00f7f92f292bb16a4dfc53ec62d68ecf6edc9.camel@joachim-breitner.de> <3267a53a47cec3597c54bab8f8518b2c1613e1a8.camel@joachim-breitner.de> <0e9b3372-5034-f596-acd2-aecc3c7be701@well-typed.com> <089f0c63-ed84-186f-6f70-0372b95e4c3e@well-typed.com> Message-ID: <14cede64-5f45-b6d1-e17a-cd1bb9cd106a@well-typed.com> On 12/12/2022 11:39, Simon Peyton Jones wrote: >    {-# LANGUAGE ExplicitNamespaces #-} >    module N where >      import M (T(type MkT)) -- NB "type" import of a data constructor >      v = MkT                -- usage at term level > > > Crumbs.  I had not realised the proposal is to allow *nested* uses of > 'type' in import lists, as you show above. The nested use is already possible with ExplicitNamespaces. Currently it allows import M (T(type MkT)) import M (type MkT) import M (pattern MkT) whereas the proposal extends it to add the possibility to write import M type (MkT) import M data (MkT) import M (data MkT) > In general, I don't feel the extensions to ExplicitNamespaces included > in the proposal are very clearly specified. > > > Actually isn't the proposal pretty clear on this, namely the first > bullet of proposed change spec > .  It only covers > import M *type * > import M *data *as MD > where I have emboldened the new bits.  Nothing about the contents of > import lists.   Why did you think your example is covered by the proposal? I'm trying to understand what import M type (MkT) means where MkT is a data constructor (or if it raises some kind of error). This was by analogy to the existing import M (T(type MkT)) which means something today, albeit not necessarily a very sensible thing (per https://gitlab.haskell.org/ghc/ghc/-/issues/22581). I don't see a clear specification of the proposed (extended) semantics of ExplicitNamespaces in the proposal, but perhaps I've missed something? Cheers, Adam > On Mon, 12 Dec 2022 at 09:15, Adam Gundry > wrote: > > Actually, reading https://gitlab.haskell.org/ghc/ghc/-/issues/22581 > I > realised I'm unclear how the proposed extensions to ExplicitNamespaces > are supposed to work. The existing situation is apparently that for a > (non-punned) data constructor, it is possible to use either a > pattern or > type qualifier in an import list (presumably because DataKinds means > the > constructor is in scope at both the term and type levels), and the > imported constructor is then usable in both contexts. > > For example, the following is accepted at present: > >     module M where >       data T = MkT > >    {-# LANGUAGE ExplicitNamespaces #-} >    module N where >      import M (T(type MkT)) -- NB "type" import of a data constructor >      v = MkT                -- usage at term level > > The present proposal says "With type specified in the import, only > identifiers belonging to the type namespace will be brought into the > scope." I'm not exactly sure how to interpret this, does it mean the > following alternative will be accepted or rejected? > >    module N where >      import M type (MkT) >      v = MkT > > I'm worried we will end up with a situation where ExplicitNamespaces > does subtly different things depending on the position of the keyword. > > In general, I don't feel the extensions to ExplicitNamespaces included > in the proposal are very clearly specified. Given the discussion about > exactly which parts belong to ExplicitNamespaces/PatternSynonyms versus > separate extensions, perhaps we should accept the parts relating to > -Wpuns/-Wpun-bindings, but ask for the ExplicitNamespaces changes to be > proposed separately? > > Cheers, > > Adam > > > On 09/12/2022 11:11, Adam Gundry wrote: > > I'm broadly in favour of accepting the proposal. I realise the > history > > is complex here, so I don't think we should ask anyone to rewrite > things > > further, though in general it would be nicer to have separate > proposals > > for -Wpuns/-Wpun-bindings (which is unambiguously fine) and for the > > changes to imports (which as Joachim points out raise issues). > > > > I'm a bit concerned that the proposal does not motivate or specify > > -Wpattern-namespace-qualified very well. > > > > > > On 08/12/2022 08:33, Joachim Breitner wrote: > >> ... > >> > >> This gives us (at least) these options: > >> > >> 1. Leave ExplicitNamespaces alone, add ExplicitNamespaces to > GHC2023, > >>     introduce one or two new extensions for the newer changes. > >> 2. Extend ExplicitNamespaces, and don’t add it already to GHC2023, > >>     disregarding issue #551. > >> 3. Add ExplicitNamespaces to GHC2023, and still add it to GHC2023, > >>     arguing that GHC20xx allows more liberal (backward-compatibile) > >>     changes than, say, Haskell2010 would allow. > >> > >> Certainly 1 is the least bold move. I am not sure what the best way > >> forwards is, and welcome other opinions. > > > > I would prefer a variant of 1: allow "data" as a keyword in > import lists > > under ExplicitNamespaces, but make the other changes under other > > extensions. > > > > As I've said previously, I have a general preference for multiple > small, > > orthogonal extensions rather than changing existing extensions to > add > > unrelated features that happen to be in similar territory. I realise > > this is controversial, of course. > > > > Cheers, > > > > Adam -- Adam Gundry, Haskell Consultant Well-Typed LLP, https://www.well-typed.com/ Registered in England & Wales, OC335890 27 Old Gloucester Street, London WC1N 3AX, England From simon.peytonjones at gmail.com Mon Dec 12 16:04:32 2022 From: simon.peytonjones at gmail.com (Simon Peyton Jones) Date: Mon, 12 Dec 2022 16:04:32 +0000 Subject: [ghc-steering-committee] Modifiers (Was: #512: NoFieldSelectors as datatype annotation) In-Reply-To: References: <494656e83f8d1486621fab153ed8f85f13b82e1b.camel@joachim-breitner.de> <414422bd-7085-f244-626a-19711dfd0692@well-typed.com> <02620ae95fb4d0a07172c06ffa83281d293e4149.camel@joachim-breitner.de> <451cf30d-8fc6-a052-0c3d-707b5f7fbc92@well-typed.com> <9484dee9-2d77-98ae-5b4d-ebc51f19cb24@well-typed.com> Message-ID: Joachim Are you arguing to un-accept the modifiers proposal? I think that's a legitimate thing to do but, well, it needs a proposal. (A kind of drastic modification to an existing proposal, namely withdrawing it.) We should feel free to change our view in the light of experience -- and it is much easier to do so before the feature is implemented and in use. But I think it is not good to have a proposal that is accepted-but-with-doubt-cast-upon-it. Simon On Fri, 9 Dec 2022 at 18:47, Joachim Breitner wrote: > Hi, > > Am Freitag, dem 09.12.2022 um 12:38 +0000 schrieb Simon Peyton Jones: > > > > We can always re-open an accepted proposal, especially if it is not > > yet implemented! > > > > The motivations for modifiers I see are: > > * We have modifiers for linear types > > * It seem wrong to use pragmas (in {-# #-} comments) for things that > > are semantically meaningful like overlapping instances. > > We definitely want modifiers in some form. We currently use them a > > lot for {-# OVERLAPPABLE #-} etc. We could stick with the {-# prag > > #-} syntax. But it's a bit noisy, and it really isn't a comment. > > And (unlike the modifier) the pragma stuff doesn't have internal > > structure -- we could not use it for linear annotations. > > > > But I think we should decide what syntax we want for modifier-like > > things, and get it implemented, else it'll keep blocking other > > proposals, like this one from Matthew. > > I was more quiet during the modifier discussion than I should have, but > if we are opening this box again, I can share why I don’t feel to > confident about it: > > * Tying modifiers to types rules out their use for every feature that > is relevant before type-checking (parsing, renaming…) > For example, imagine we only had unqualified imports, and now want > to add qualified imports. This feels like a “modification” to me, > and a good “modifier syntax” scheme should be able to accommodate > it. But it affects renaming, and thus wouldn’t work with a type- > based thing. > > * The syntax might be too clumsy. Consider, again, adding qualified > imports to the syntax: We’d have to specify an optional parameter > (for the `qualified as Foo` part). How would that look like in Type > syntax? Would the qualifier be > data Quantified = Quantified (Maybe String) > and you need to write Nothing or Just? And quote the name? > > Even linear types, listed as one of the motivations, really wants to > have a nice syntax for the linear arrow, doesn’t it? > > I expect that many future modifiers on syntax benefit from custom > syntax to be ergonomic and preserve the aesthetics of Haskell code. > > TL;DR: I doubt that a one-scheme-fits all, type-based modifier syntax > covers enough use-cases to pay its weight, and am leaning towards > “just” coming up with custom syntax for new features (likely with new > context-dependent keywords where possible – as in deriving via). > > > Cheers, > Joachim > > > > -- > Joachim Breitner > mail at joachim-breitner.de > http://www.joachim-breitner.de/ > > _______________________________________________ > 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 mail at joachim-breitner.de Mon Dec 12 16:22:22 2022 From: mail at joachim-breitner.de (Joachim Breitner) Date: Mon, 12 Dec 2022 17:22:22 +0100 Subject: [ghc-steering-committee] Modifiers (Was: #512: NoFieldSelectors as datatype annotation) In-Reply-To: References: <494656e83f8d1486621fab153ed8f85f13b82e1b.camel@joachim-breitner.de> <414422bd-7085-f244-626a-19711dfd0692@well-typed.com> <02620ae95fb4d0a07172c06ffa83281d293e4149.camel@joachim-breitner.de> <451cf30d-8fc6-a052-0c3d-707b5f7fbc92@well-typed.com> <9484dee9-2d77-98ae-5b4d-ebc51f19cb24@well-typed.com> Message-ID: <13a361fc9689b0da5352085f4eab397d800af022.camel@joachim-breitner.de> Hi, it’s not “in the light of experience”, and there is nothing in here that I couldn’t have brought up when it was originally discussed, and when I should have (but didn’t for reasons I don’t quite remember; I think it was a time of limited bandwidth on my side, and I had the impression that there was a lot of enthusiasm). So I’d feel bad to actively suggest to unaccept it now – at least not unless it happens that my worries are more widely shared. Cheers, Joachim Am Montag, dem 12.12.2022 um 16:04 +0000 schrieb Simon Peyton Jones: > Joachim > > Are you arguing to un-accept the modifiers proposal?  I think that's > a legitimate thing to do but, well, it needs a proposal.  (A kind of > drastic modification to an existing proposal, namely withdrawing it.) > > We should feel free to change our view in the light of experience -- > and it is much easier to do so before the feature is implemented and > in use.  But I think it is not good to have a proposal that is > accepted-but-with-doubt-cast-upon-it. > > Simon > > On Fri, 9 Dec 2022 at 18:47, Joachim Breitner > wrote: > > Hi, > > > > Am Freitag, dem 09.12.2022 um 12:38 +0000 schrieb Simon Peyton > > Jones: > > > > > > We can always re-open an accepted proposal, especially if it is > > > not > > > yet implemented! > > > > > > The motivations for modifiers I see are: > > >  * We have modifiers for linear types > > >  * It seem wrong to use pragmas (in {-# #-} comments) for things > > > that > > > are semantically meaningful like overlapping instances. > > > We definitely want modifiers in some form.  We currently use them > > > a > > > lot for {-# OVERLAPPABLE #-} etc.  We could stick with the {-# > > > prag > > > #-} syntax.  But it's a bit noisy, and it really isn't a > > > comment.  > > > And (unlike the modifier) the pragma stuff doesn't have internal > > > structure -- we could not use it for linear annotations. > > > > > > But I think we should decide what syntax we want for modifier- > > > like > > > things, and get it implemented, else it'll keep blocking other > > > proposals, like this one from Matthew. > > > > I was more quiet during the modifier discussion than I should have, > > but > > if we are opening this box again, I can share why I don’t feel to > > confident about it: > > > >  * Tying modifiers to types rules out their use for every feature > > that > >    is relevant before type-checking (parsing, renaming…) > >    For example, imagine we only had unqualified imports, and now > > want > >    to add qualified imports. This feels like a “modification” to > > me, > >    and a good “modifier syntax” scheme should be able to > > accommodate  > >    it. But it affects renaming, and thus wouldn’t work with a type- > >    based thing. > > > >  * The syntax might be too clumsy. Consider, again, adding > > qualified > >    imports to the syntax: We’d have to specify an optional > > parameter > >    (for the `qualified as Foo` part). How would that look like in > > Type > >    syntax? Would the qualifier be > >       data Quantified = Quantified (Maybe String) > >    and you need to write Nothing or Just? And quote the name? > > > >    Even linear types, listed as one of the motivations, really > > wants to > >    have a nice syntax for the linear arrow, doesn’t it? > > > >    I expect that many future modifiers on syntax benefit from > > custom > >    syntax to be ergonomic and preserve the aesthetics of Haskell > > code. > > > > TL;DR: I doubt that a one-scheme-fits all, type-based modifier > > syntax > > covers enough use-cases to pay its weight, and am leaning towards > > “just” coming up with custom syntax for new features (likely with > > new > > context-dependent keywords where possible – as in deriving via).  > > > > > > Cheers, > > Joachim > > > > > > > > _______________________________________________ > > ghc-steering-committee mailing list > > ghc-steering-committee at haskell.org > > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee -- Joachim Breitner mail at joachim-breitner.de http://www.joachim-breitner.de/ From chris at chrisdornan.com Mon Dec 12 16:50:43 2022 From: chris at chrisdornan.com (Chris Dornan) Date: Mon, 12 Dec 2022 16:50:43 +0000 Subject: [ghc-steering-committee] Proposal #270: Support pun-free code. Recommendation: accept In-Reply-To: <14cede64-5f45-b6d1-e17a-cd1bb9cd106a@well-typed.com> References: <5D0E3610-C73F-4850-9435-8D22069382BD@chrisdornan.com> <2da00f7f92f292bb16a4dfc53ec62d68ecf6edc9.camel@joachim-breitner.de> <3267a53a47cec3597c54bab8f8518b2c1613e1a8.camel@joachim-breitner.de> <0e9b3372-5034-f596-acd2-aecc3c7be701@well-typed.com> <089f0c63-ed84-186f-6f70-0372b95e4c3e@well-typed.com> <14cede64-5f45-b6d1-e17a-cd1bb9cd106a@well-typed.com> Message-ID: <9B22308E-170D-4B86-BFF8-1E63D3DF5387@chrisdornan.com> I really think we should split this proposal into two, one to deal with warnings and the other to deal with namespaces. The warnings look to me ready to go. I am further thinking that we should really welcome the followup namespace proposal as an opportunity to clarify and properly document namespaces. I am sorry, I was added to the proposal very late thinking it was technically sound but I am realising it is far from the case. Finally, I am quite surprised at how little documentation there seems to be on ExplicitNamespaces. Should we be asking that revised documentation be propared as part of the proposal process and that the documentation be up to scratch? It seems the least we should be asking and much more important than requiring an implementation plan. This process is increasingly the only game in town when it comes to driving forward and defining Haskell and we need to make sure stuff is being written down properly. Chris > On 12 Dec 2022, at 12:21, Adam Gundry wrote: > > On 12/12/2022 11:39, Simon Peyton Jones wrote: >> {-# LANGUAGE ExplicitNamespaces #-} >> module N where >> import M (T(type MkT)) -- NB "type" import of a data constructor >> v = MkT -- usage at term level Crumbs. I had not realised the proposal is to allow *nested* uses of 'type' in import lists, as you show above. > > The nested use is already possible with ExplicitNamespaces. Currently it allows > > import M (T(type MkT)) > import M (type MkT) > import M (pattern MkT) > > whereas the proposal extends it to add the possibility to write > > import M type (MkT) > import M data (MkT) > import M (data MkT) > > >> In general, I don't feel the extensions to ExplicitNamespaces included >> in the proposal are very clearly specified. Actually isn't the proposal pretty clear on this, namely the first bullet of proposed change spec . It only covers >> import M *type * >> import M *data *as MD >> where I have emboldened the new bits. Nothing about the contents of import lists. Why did you think your example is covered by the proposal? > > I'm trying to understand what > > import M type (MkT) > > means where MkT is a data constructor (or if it raises some kind of error). This was by analogy to the existing > > import M (T(type MkT)) > > which means something today, albeit not necessarily a very sensible thing (per https://gitlab.haskell.org/ghc/ghc/-/issues/22581). > > I don't see a clear specification of the proposed (extended) semantics of ExplicitNamespaces in the proposal, but perhaps I've missed something? > > Cheers, > > Adam > > >> On Mon, 12 Dec 2022 at 09:15, Adam Gundry > wrote: >> Actually, reading https://gitlab.haskell.org/ghc/ghc/-/issues/22581 >> I >> realised I'm unclear how the proposed extensions to ExplicitNamespaces >> are supposed to work. The existing situation is apparently that for a >> (non-punned) data constructor, it is possible to use either a >> pattern or >> type qualifier in an import list (presumably because DataKinds means >> the >> constructor is in scope at both the term and type levels), and the >> imported constructor is then usable in both contexts. >> For example, the following is accepted at present: >> module M where >> data T = MkT >> {-# LANGUAGE ExplicitNamespaces #-} >> module N where >> import M (T(type MkT)) -- NB "type" import of a data constructor >> v = MkT -- usage at term level >> The present proposal says "With type specified in the import, only >> identifiers belonging to the type namespace will be brought into the >> scope." I'm not exactly sure how to interpret this, does it mean the >> following alternative will be accepted or rejected? >> module N where >> import M type (MkT) >> v = MkT >> I'm worried we will end up with a situation where ExplicitNamespaces >> does subtly different things depending on the position of the keyword. >> In general, I don't feel the extensions to ExplicitNamespaces included >> in the proposal are very clearly specified. Given the discussion about >> exactly which parts belong to ExplicitNamespaces/PatternSynonyms versus >> separate extensions, perhaps we should accept the parts relating to >> -Wpuns/-Wpun-bindings, but ask for the ExplicitNamespaces changes to be >> proposed separately? >> Cheers, >> Adam >> On 09/12/2022 11:11, Adam Gundry wrote: >> > I'm broadly in favour of accepting the proposal. I realise the >> history >> > is complex here, so I don't think we should ask anyone to rewrite >> things >> > further, though in general it would be nicer to have separate >> proposals >> > for -Wpuns/-Wpun-bindings (which is unambiguously fine) and for the >> > changes to imports (which as Joachim points out raise issues). >> > >> > I'm a bit concerned that the proposal does not motivate or specify >> > -Wpattern-namespace-qualified very well. >> > >> > >> > On 08/12/2022 08:33, Joachim Breitner wrote: >> >> ... >> >> >> >> This gives us (at least) these options: >> >> >> >> 1. Leave ExplicitNamespaces alone, add ExplicitNamespaces to >> GHC2023, >> >> introduce one or two new extensions for the newer changes. >> >> 2. Extend ExplicitNamespaces, and don’t add it already to GHC2023, >> >> disregarding issue #551. >> >> 3. Add ExplicitNamespaces to GHC2023, and still add it to GHC2023, >> >> arguing that GHC20xx allows more liberal (backward-compatibile) >> >> changes than, say, Haskell2010 would allow. >> >> >> >> Certainly 1 is the least bold move. I am not sure what the best way >> >> forwards is, and welcome other opinions. >> > >> > I would prefer a variant of 1: allow "data" as a keyword in >> import lists >> > under ExplicitNamespaces, but make the other changes under other >> > extensions. >> > >> > As I've said previously, I have a general preference for multiple >> small, >> > orthogonal extensions rather than changing existing extensions to >> add >> > unrelated features that happen to be in similar territory. I realise >> > this is controversial, of course. >> > >> > Cheers, >> > >> > Adam > > -- > Adam Gundry, Haskell Consultant > Well-Typed LLP, https://www.well-typed.com/ > > Registered in England & Wales, OC335890 > 27 Old Gloucester Street, London WC1N 3AX, England > > _______________________________________________ > ghc-steering-committee mailing list > ghc-steering-committee at haskell.org > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee -------------- next part -------------- An HTML attachment was scrubbed... URL: From chris at chrisdornan.com Mon Dec 12 18:46:47 2022 From: chris at chrisdornan.com (Chris Dornan) Date: Mon, 12 Dec 2022 18:46:47 +0000 Subject: [ghc-steering-committee] Please review #546: Make Symbol a newtype over String, Shepherd: Chris In-Reply-To: <32E74F1C-736A-4BF0-B906-57A60912BC02@chrisdornan.com> References: <555dcb045377d7eb674c5656ecdb47904f5bdbaf.camel@joachim-breitner.de> <7590f16bfc68285b7803ac82ea7e77285a336460.camel@joachim-breitner.de> <144726f8466b6b248f4851d69c2d8b73e1e8500a.camel@joachim-breitner.de> <32E74F1C-736A-4BF0-B906-57A60912BC02@chrisdornan.com> Message-ID: I have decided the simplest way to rescue the proposal is to resubmit it myself as #562 Chris > On 9 Dec 2022, at 19:46, Chris Dornan wrote: > > I am sorry, this is on me. I have also apologised to Oleg in the thread. I was trying to close out #270 so I could give it my full attention but just as it seems headed for resolution more complications emerge. > > I have offered to try and make the process work for Oleg but failing that I will try and find a new sponsor as the proposal seemed to be worthy. > > Chris > > > > > > >> On 9 Dec 2022, at 19:01, Joachim Breitner wrote: >> >> Hi, >> >> Am Freitag, dem 18.11.2022 um 09:20 +0100 schrieb Joachim Breitner: >>> Make Symbol a newtype over String >>> has been proposed by Oleg Grenus >>> >>> https://github.com/ghc-proposals/ghc-proposals/pull/546 >>> https://github.com/phadej/ghc-proposals/blob/symbol-type/proposals/0000-symbol-newtype-string.rst >>> >>> I suggest Chris Dornan shepherds this proposal. >> >> >> the authors has ran out of patience with our silence, and bureaucratic >> comments that parts of it should maybe a CLC proposal, nd has given up >> on this proposal: >> https://github.com/ghc-proposals/ghc-proposals/pull/546#issuecomment-1344604917 >> >> Cheers, >> Joachim >> >> -- >> Joachim Breitner >> mail at joachim-breitner.de >> http://www.joachim-breitner.de/ >> >> _______________________________________________ >> 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 adam at well-typed.com Mon Dec 12 20:00:38 2022 From: adam at well-typed.com (Adam Gundry) Date: Mon, 12 Dec 2022 20:00:38 +0000 Subject: [ghc-steering-committee] Proposal #270: Support pun-free code. Recommendation: accept In-Reply-To: References: <5D0E3610-C73F-4850-9435-8D22069382BD@chrisdornan.com> <2da00f7f92f292bb16a4dfc53ec62d68ecf6edc9.camel@joachim-breitner.de> <3267a53a47cec3597c54bab8f8518b2c1613e1a8.camel@joachim-breitner.de> <0e9b3372-5034-f596-acd2-aecc3c7be701@well-typed.com> <089f0c63-ed84-186f-6f70-0372b95e4c3e@well-typed.com> <14cede64-5f45-b6d1-e17a-cd1bb9cd106a@well-typed.com> Message-ID: <7250fa88-c7f0-72d7-0d7c-8eb4814406e2@well-typed.com> (Simon, I'm guessing this message should have gone to the committee list, so I'm including the full text below.) On 12/12/2022 13:04, Simon Peyton Jones wrote: > > The nested use is already possible with ExplicitNamespaces. > Currently it > > > Wow. I had no idea.  The user manual is entirely silent on this point > .  > Is there some proposal that specifies this behaviour, which the user > manual is failing to document?  Or is the implementation doing > something that is nowhere specified? > > I'm trying to understand what `import M type (MkT)` does > > > Well the proposal says > # With |type| specified in the import, only identifiers belonging to the > type namespace will be brought into the scope. > I took this saying "behave exactly as now, but post-filter the imports > to take only the ones from the type namespace".  Today `import M( MkT > )` will be rejected; so I assume it'll still be rejected. > > I agree that this point could be more clearly articulated. > > Simon > > On Mon, 12 Dec 2022 at 12:22, Adam Gundry wrote: > > On 12/12/2022 11:39, Simon Peyton Jones wrote: > >         {-# LANGUAGE ExplicitNamespaces #-} > >         module N where > >           import M (T(type MkT)) -- NB "type" import of a data > constructor > >           v = MkT                -- usage at term level > > > > > > Crumbs.  I had not realised the proposal is to allow *nested* > uses of > > 'type' in import lists, as you show above. > > The nested use is already possible with ExplicitNamespaces. > Currently it > allows > >      import M (T(type MkT)) >      import M (type MkT) >      import M (pattern MkT) > > whereas the proposal extends it to add the possibility to write > >      import M type (MkT) >      import M data (MkT) >      import M (data MkT) > > > >     In general, I don't feel the extensions to > ExplicitNamespaces included > >     in the proposal are very clearly specified. > > > > > > Actually isn't the proposal pretty clear on this, namely the first > > bullet of proposed change spec > > > . > It only covers > > import M *type * > > import M *data *as MD > > where I have emboldened the new bits.  Nothing about the > contents of > > import lists.   Why did you think your example is covered by the > proposal? > > I'm trying to understand what > >      import M type (MkT) > > means where MkT is a data constructor (or if it raises some kind of > error). This was by analogy to the existing > >      import M (T(type MkT)) > > which means something today, albeit not necessarily a very sensible > thing (per https://gitlab.haskell.org/ghc/ghc/-/issues/22581). > > I don't see a clear specification of the proposed (extended) > semantics > of ExplicitNamespaces in the proposal, but perhaps I've missed > something? > > Cheers, > > Adam > > > > On Mon, 12 Dec 2022 at 09:15, Adam Gundry > > wrote: > > > >     Actually, reading > https://gitlab.haskell.org/ghc/ghc/-/issues/22581 > >      I > >     realised I'm unclear how the proposed extensions to > ExplicitNamespaces > >     are supposed to work. The existing situation is apparently > that for a > >     (non-punned) data constructor, it is possible to use either a > >     pattern or > >     type qualifier in an import list (presumably because > DataKinds means > >     the > >     constructor is in scope at both the term and type levels), > and the > >     imported constructor is then usable in both contexts. > > > >     For example, the following is accepted at present: > > > >          module M where > >            data T = MkT > > > >         {-# LANGUAGE ExplicitNamespaces #-} > >         module N where > >           import M (T(type MkT)) -- NB "type" import of a data > constructor > >           v = MkT                -- usage at term level > > > >     The present proposal says "With type specified in the > import, only > >     identifiers belonging to the type namespace will be brought > into the > >     scope." I'm not exactly sure how to interpret this, does it > mean the > >     following alternative will be accepted or rejected? > > > >         module N where > >           import M type (MkT) > >           v = MkT > > > >     I'm worried we will end up with a situation where > ExplicitNamespaces > >     does subtly different things depending on the position of > the keyword. > > > >     In general, I don't feel the extensions to > ExplicitNamespaces included > >     in the proposal are very clearly specified. Given the > discussion about > >     exactly which parts belong to > ExplicitNamespaces/PatternSynonyms versus > >     separate extensions, perhaps we should accept the parts > relating to > >     -Wpuns/-Wpun-bindings, but ask for the ExplicitNamespaces > changes to be > >     proposed separately? > > > >     Cheers, > > > >     Adam > > > > > >     On 09/12/2022 11:11, Adam Gundry wrote: > >      > I'm broadly in favour of accepting the proposal. I > realise the > >     history > >      > is complex here, so I don't think we should ask anyone to > rewrite > >     things > >      > further, though in general it would be nicer to have separate > >     proposals > >      > for -Wpuns/-Wpun-bindings (which is unambiguously fine) > and for the > >      > changes to imports (which as Joachim points out raise > issues). > >      > > >      > I'm a bit concerned that the proposal does not motivate > or specify > >      > -Wpattern-namespace-qualified very well. > >      > > >      > > >      > On 08/12/2022 08:33, Joachim Breitner wrote: > >      >> ... > >      >> > >      >> This gives us (at least) these options: > >      >> > >      >> 1. Leave ExplicitNamespaces alone, add ExplicitNamespaces to > >     GHC2023, > >      >>     introduce one or two new extensions for the newer > changes. > >      >> 2. Extend ExplicitNamespaces, and don’t add it already > to GHC2023, > >      >>     disregarding issue #551. > >      >> 3. Add ExplicitNamespaces to GHC2023, and still add it > to GHC2023, > >      >>     arguing that GHC20xx allows more liberal > (backward-compatibile) > >      >>     changes than, say, Haskell2010 would allow. > >      >> > >      >> Certainly 1 is the least bold move. I am not sure what > the best way > >      >> forwards is, and welcome other opinions. > >      > > >      > I would prefer a variant of 1: allow "data" as a keyword in > >     import lists > >      > under ExplicitNamespaces, but make the other changes > under other > >      > extensions. > >      > > >      > As I've said previously, I have a general preference for > multiple > >     small, > >      > orthogonal extensions rather than changing existing > extensions to > >     add > >      > unrelated features that happen to be in similar > territory. I realise > >      > this is controversial, of course. > >      > > >      > Cheers, > >      > > >      > Adam > -- Adam Gundry, Haskell Consultant Well-Typed LLP,https://www.well-typed.com/ Registered in England & Wales, OC335890 27 Old Gloucester Street, London WC1N 3AX, England -------------- next part -------------- An HTML attachment was scrubbed... URL: From adam at well-typed.com Mon Dec 12 20:11:44 2022 From: adam at well-typed.com (Adam Gundry) Date: Mon, 12 Dec 2022 20:11:44 +0000 Subject: [ghc-steering-committee] Proposal #270: Support pun-free code. Recommendation: accept In-Reply-To: <9B22308E-170D-4B86-BFF8-1E63D3DF5387@chrisdornan.com> References: <5D0E3610-C73F-4850-9435-8D22069382BD@chrisdornan.com> <2da00f7f92f292bb16a4dfc53ec62d68ecf6edc9.camel@joachim-breitner.de> <3267a53a47cec3597c54bab8f8518b2c1613e1a8.camel@joachim-breitner.de> <0e9b3372-5034-f596-acd2-aecc3c7be701@well-typed.com> <089f0c63-ed84-186f-6f70-0372b95e4c3e@well-typed.com> <14cede64-5f45-b6d1-e17a-cd1bb9cd106a@well-typed.com> <9B22308E-170D-4B86-BFF8-1E63D3DF5387@chrisdornan.com> Message-ID: On 12/12/2022 16:50, Chris Dornan wrote: > I really think we should split this proposal into two, one to deal with > warnings and the other to deal with namespaces. The warnings look to me > ready to go. > > I am further thinking that we should really welcome the followup > namespace proposal as an opportunity to clarify and properly document > namespaces. > > I am sorry, I was added to the proposal very late thinking it > was technically sound but I am realising it is far from the case. > > Finally, I am quite surprised at how little documentation there seems to > be on ExplicitNamespaces. Should we be asking that revised documentation > be propared as part of the proposal process and that the documentation > be up to scratch? It seems the least we should be asking and much more > important than requiring an implementation plan. This process is > increasingly the only game in town when it comes to driving forward and > defining Haskell and we need to make sure stuff is being written down > properly. This is a bit of a tricky issue, I think. I agree that we should strive for a proper specification of ExplicitNamespaces. The current state seems to be sadly lacking, especially if we want ExplicitNamespaces to be in GHC2023. That said, there's a risk that proposal authors will be discouraged if proposing changes entails writing specifications for existing under-specified features! I wonder if anyone has attempted to extend "A Formal Specification of the Haskell 98 Module System" to more recent GHC extensions? Adam >> On 12 Dec 2022, at 12:21, Adam Gundry > > wrote: >> >> On 12/12/2022 11:39, Simon Peyton Jones wrote: >>>        {-# LANGUAGE ExplicitNamespaces #-} >>>        module N where >>>          import M (T(type MkT)) -- NB "type" import of a data constructor >>>          v = MkT                -- usage at term level Crumbs.  I had >>> not realised the proposal is to allow *nested* uses of 'type' in >>> import lists, as you show above. >> >> The nested use is already possible with ExplicitNamespaces. Currently >> it allows >> >>    import M (T(type MkT)) >>    import M (type MkT) >>    import M (pattern MkT) >> >> whereas the proposal extends it to add the possibility to write >> >>    import M type (MkT) >>    import M data (MkT) >>    import M (data MkT) >> >> >>>    In general, I don't feel the extensions to ExplicitNamespaces included >>>    in the proposal are very clearly specified. Actually isn't the >>> proposal pretty clear on this, namely the first bullet of proposed >>> change spec >>> >.  It only covers >>> import M *type * >>> import M *data *as MD >>> where I have emboldened the new bits.  Nothing about the contents of >>> import lists.   Why did you think your example is covered by the >>> proposal? >> >> I'm trying to understand what >> >>    import M type (MkT) >> >> means where MkT is a data constructor (or if it raises some kind of >> error). This was by analogy to the existing >> >>    import M (T(type MkT)) >> >> which means something today, albeit not necessarily a very sensible >> thing (per https://gitlab.haskell.org/ghc/ghc/-/issues/22581 >> ). >> >> I don't see a clear specification of the proposed (extended) semantics >> of ExplicitNamespaces in the proposal, but perhaps I've missed something? >> >> Cheers, >> >> Adam >> >> >>> On Mon, 12 Dec 2022 at 09:15, Adam Gundry >> >> >> wrote: >>>    Actually, reading >>> https://gitlab.haskell.org/ghc/ghc/-/issues/22581 >>> >>>    >> > I >>>    realised I'm unclear how the proposed extensions to ExplicitNamespaces >>>    are supposed to work. The existing situation is apparently that for a >>>    (non-punned) data constructor, it is possible to use either a >>>    pattern or >>>    type qualifier in an import list (presumably because DataKinds means >>>    the >>>    constructor is in scope at both the term and type levels), and the >>>    imported constructor is then usable in both contexts. >>>    For example, the following is accepted at present: >>>         module M where >>>           data T = MkT >>>        {-# LANGUAGE ExplicitNamespaces #-} >>>        module N where >>>          import M (T(type MkT)) -- NB "type" import of a data constructor >>>          v = MkT                -- usage at term level >>>    The present proposal says "With type specified in the import, only >>>    identifiers belonging to the type namespace will be brought into the >>>    scope." I'm not exactly sure how to interpret this, does it mean the >>>    following alternative will be accepted or rejected? >>>        module N where >>>          import M type (MkT) >>>          v = MkT >>>    I'm worried we will end up with a situation where ExplicitNamespaces >>>    does subtly different things depending on the position of the keyword. >>>    In general, I don't feel the extensions to ExplicitNamespaces included >>>    in the proposal are very clearly specified. Given the discussion about >>>    exactly which parts belong to ExplicitNamespaces/PatternSynonyms >>> versus >>>    separate extensions, perhaps we should accept the parts relating to >>>    -Wpuns/-Wpun-bindings, but ask for the ExplicitNamespaces changes >>> to be >>>    proposed separately? >>>    Cheers, >>>    Adam >>>    On 09/12/2022 11:11, Adam Gundry wrote: >>>     > I'm broadly in favour of accepting the proposal. I realise the >>>    history >>>     > is complex here, so I don't think we should ask anyone to rewrite >>>    things >>>     > further, though in general it would be nicer to have separate >>>    proposals >>>     > for -Wpuns/-Wpun-bindings (which is unambiguously fine) and for the >>>     > changes to imports (which as Joachim points out raise issues). >>>     > >>>     > I'm a bit concerned that the proposal does not motivate or specify >>>     > -Wpattern-namespace-qualified very well. >>>     > >>>     > >>>     > On 08/12/2022 08:33, Joachim Breitner wrote: >>>     >> ... >>>     >> >>>     >> This gives us (at least) these options: >>>     >> >>>     >> 1. Leave ExplicitNamespaces alone, add ExplicitNamespaces to >>>    GHC2023, >>>     >>     introduce one or two new extensions for the newer changes. >>>     >> 2. Extend ExplicitNamespaces, and don’t add it already to GHC2023, >>>     >>     disregarding issue #551. >>>     >> 3. Add ExplicitNamespaces to GHC2023, and still add it to GHC2023, >>>     >>     arguing that GHC20xx allows more liberal >>> (backward-compatibile) >>>     >>     changes than, say, Haskell2010 would allow. >>>     >> >>>     >> Certainly 1 is the least bold move. I am not sure what the >>> best way >>>     >> forwards is, and welcome other opinions. >>>     > >>>     > I would prefer a variant of 1: allow "data" as a keyword in >>>    import lists >>>     > under ExplicitNamespaces, but make the other changes under other >>>     > extensions. >>>     > >>>     > As I've said previously, I have a general preference for multiple >>>    small, >>>     > orthogonal extensions rather than changing existing extensions to >>>    add >>>     > unrelated features that happen to be in similar territory. I >>> realise >>>     > this is controversial, of course. >>>     > >>>     > Cheers, >>>     > >>>     > Adam -- Adam Gundry, Haskell Consultant Well-Typed LLP, https://www.well-typed.com/ Registered in England & Wales, OC335890 27 Old Gloucester Street, London WC1N 3AX, England From chris at chrisdornan.com Mon Dec 12 22:05:32 2022 From: chris at chrisdornan.com (Chris Dornan) Date: Mon, 12 Dec 2022 22:05:32 +0000 Subject: [ghc-steering-committee] Proposal #270: Support pun-free code. Recommendation: accept In-Reply-To: References: <5D0E3610-C73F-4850-9435-8D22069382BD@chrisdornan.com> <2da00f7f92f292bb16a4dfc53ec62d68ecf6edc9.camel@joachim-breitner.de> <3267a53a47cec3597c54bab8f8518b2c1613e1a8.camel@joachim-breitner.de> <0e9b3372-5034-f596-acd2-aecc3c7be701@well-typed.com> <089f0c63-ed84-186f-6f70-0372b95e4c3e@well-typed.com> <14cede64-5f45-b6d1-e17a-cd1bb9cd106a@well-typed.com> <9B22308E-170D-4B86-BFF8-1E63D3DF5387@chrisdornan.com> Message-ID: <84D37F3F-FC1D-4B57-BE99-B355419E8EA4@chrisdornan.com> In this case, for sure, responsibility for fixing up namespace documentation should not fall on the author of this proposal. I am thinking more that they should be strongly encouraged to submit the follow-up proposal and we provide or identify whatever assistance necessary to get the job done. It will definitely get us to a better place in my view. It sounds like we are in strong agreement. Chris > On 12 Dec 2022, at 20:11, Adam Gundry wrote: > > On 12/12/2022 16:50, Chris Dornan wrote: >> I really think we should split this proposal into two, one to deal with warnings and the other to deal with namespaces. The warnings look to me ready to go. >> I am further thinking that we should really welcome the followup namespace proposal as an opportunity to clarify and properly document namespaces. >> I am sorry, I was added to the proposal very late thinking it was technically sound but I am realising it is far from the case. >> Finally, I am quite surprised at how little documentation there seems to be on ExplicitNamespaces. Should we be asking that revised documentation be propared as part of the proposal process and that the documentation be up to scratch? It seems the least we should be asking and much more important than requiring an implementation plan. This process is increasingly the only game in town when it comes to driving forward and defining Haskell and we need to make sure stuff is being written down properly. > > This is a bit of a tricky issue, I think. I agree that we should strive for a proper specification of ExplicitNamespaces. The current state seems to be sadly lacking, especially if we want ExplicitNamespaces to be in GHC2023. That said, there's a risk that proposal authors will be discouraged if proposing changes entails writing specifications for existing under-specified features! > > I wonder if anyone has attempted to extend "A Formal Specification of the Haskell 98 Module System" to more recent GHC extensions? > > Adam > > >>> On 12 Dec 2022, at 12:21, Adam Gundry > wrote: >>> >>> On 12/12/2022 11:39, Simon Peyton Jones wrote: >>>> {-# LANGUAGE ExplicitNamespaces #-} >>>> module N where >>>> import M (T(type MkT)) -- NB "type" import of a data constructor >>>> v = MkT -- usage at term level Crumbs. I had not realised the proposal is to allow *nested* uses of 'type' in import lists, as you show above. >>> >>> The nested use is already possible with ExplicitNamespaces. Currently it allows >>> >>> import M (T(type MkT)) >>> import M (type MkT) >>> import M (pattern MkT) >>> >>> whereas the proposal extends it to add the possibility to write >>> >>> import M type (MkT) >>> import M data (MkT) >>> import M (data MkT) >>> >>> >>>> In general, I don't feel the extensions to ExplicitNamespaces included >>>> in the proposal are very clearly specified. Actually isn't the proposal pretty clear on this, namely the first bullet of proposed change spec >. It only covers >>>> import M *type * >>>> import M *data *as MD >>>> where I have emboldened the new bits. Nothing about the contents of import lists. Why did you think your example is covered by the proposal? >>> >>> I'm trying to understand what >>> >>> import M type (MkT) >>> >>> means where MkT is a data constructor (or if it raises some kind of error). This was by analogy to the existing >>> >>> import M (T(type MkT)) >>> >>> which means something today, albeit not necessarily a very sensible thing (per https://gitlab.haskell.org/ghc/ghc/-/issues/22581 ). >>> >>> I don't see a clear specification of the proposed (extended) semantics of ExplicitNamespaces in the proposal, but perhaps I've missed something? >>> >>> Cheers, >>> >>> Adam >>> >>> >>>> On Mon, 12 Dec 2022 at 09:15, Adam Gundry >> wrote: >>>> Actually, reading https://gitlab.haskell.org/ghc/ghc/-/issues/22581 >>>> > I >>>> realised I'm unclear how the proposed extensions to ExplicitNamespaces >>>> are supposed to work. The existing situation is apparently that for a >>>> (non-punned) data constructor, it is possible to use either a >>>> pattern or >>>> type qualifier in an import list (presumably because DataKinds means >>>> the >>>> constructor is in scope at both the term and type levels), and the >>>> imported constructor is then usable in both contexts. >>>> For example, the following is accepted at present: >>>> module M where >>>> data T = MkT >>>> {-# LANGUAGE ExplicitNamespaces #-} >>>> module N where >>>> import M (T(type MkT)) -- NB "type" import of a data constructor >>>> v = MkT -- usage at term level >>>> The present proposal says "With type specified in the import, only >>>> identifiers belonging to the type namespace will be brought into the >>>> scope." I'm not exactly sure how to interpret this, does it mean the >>>> following alternative will be accepted or rejected? >>>> module N where >>>> import M type (MkT) >>>> v = MkT >>>> I'm worried we will end up with a situation where ExplicitNamespaces >>>> does subtly different things depending on the position of the keyword. >>>> In general, I don't feel the extensions to ExplicitNamespaces included >>>> in the proposal are very clearly specified. Given the discussion about >>>> exactly which parts belong to ExplicitNamespaces/PatternSynonyms versus >>>> separate extensions, perhaps we should accept the parts relating to >>>> -Wpuns/-Wpun-bindings, but ask for the ExplicitNamespaces changes to be >>>> proposed separately? >>>> Cheers, >>>> Adam >>>> On 09/12/2022 11:11, Adam Gundry wrote: >>>> > I'm broadly in favour of accepting the proposal. I realise the >>>> history >>>> > is complex here, so I don't think we should ask anyone to rewrite >>>> things >>>> > further, though in general it would be nicer to have separate >>>> proposals >>>> > for -Wpuns/-Wpun-bindings (which is unambiguously fine) and for the >>>> > changes to imports (which as Joachim points out raise issues). >>>> > >>>> > I'm a bit concerned that the proposal does not motivate or specify >>>> > -Wpattern-namespace-qualified very well. >>>> > >>>> > >>>> > On 08/12/2022 08:33, Joachim Breitner wrote: >>>> >> ... >>>> >> >>>> >> This gives us (at least) these options: >>>> >> >>>> >> 1. Leave ExplicitNamespaces alone, add ExplicitNamespaces to >>>> GHC2023, >>>> >> introduce one or two new extensions for the newer changes. >>>> >> 2. Extend ExplicitNamespaces, and don’t add it already to GHC2023, >>>> >> disregarding issue #551. >>>> >> 3. Add ExplicitNamespaces to GHC2023, and still add it to GHC2023, >>>> >> arguing that GHC20xx allows more liberal (backward-compatibile) >>>> >> changes than, say, Haskell2010 would allow. >>>> >> >>>> >> Certainly 1 is the least bold move. I am not sure what the best way >>>> >> forwards is, and welcome other opinions. >>>> > >>>> > I would prefer a variant of 1: allow "data" as a keyword in >>>> import lists >>>> > under ExplicitNamespaces, but make the other changes under other >>>> > extensions. >>>> > >>>> > As I've said previously, I have a general preference for multiple >>>> small, >>>> > orthogonal extensions rather than changing existing extensions to >>>> add >>>> > unrelated features that happen to be in similar territory. I realise >>>> > this is controversial, of course. >>>> > >>>> > Cheers, >>>> > >>>> > Adam > > > -- > Adam Gundry, Haskell Consultant > Well-Typed LLP, https://www.well-typed.com/ > > Registered in England & Wales, OC335890 > 27 Old Gloucester Street, London WC1N 3AX, England > > _______________________________________________ > ghc-steering-committee mailing list > ghc-steering-committee at haskell.org > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee From simon.peytonjones at gmail.com Tue Dec 13 09:01:56 2022 From: simon.peytonjones at gmail.com (Simon Peyton Jones) Date: Tue, 13 Dec 2022 09:01:56 +0000 Subject: [ghc-steering-committee] Proposal #270: Support pun-free code. Recommendation: accept In-Reply-To: <84D37F3F-FC1D-4B57-BE99-B355419E8EA4@chrisdornan.com> References: <5D0E3610-C73F-4850-9435-8D22069382BD@chrisdornan.com> <2da00f7f92f292bb16a4dfc53ec62d68ecf6edc9.camel@joachim-breitner.de> <3267a53a47cec3597c54bab8f8518b2c1613e1a8.camel@joachim-breitner.de> <0e9b3372-5034-f596-acd2-aecc3c7be701@well-typed.com> <089f0c63-ed84-186f-6f70-0372b95e4c3e@well-typed.com> <14cede64-5f45-b6d1-e17a-cd1bb9cd106a@well-typed.com> <9B22308E-170D-4B86-BFF8-1E63D3DF5387@chrisdornan.com> <84D37F3F-FC1D-4B57-BE99-B355419E8EA4@chrisdornan.com> Message-ID: I still don't get the "split in two" thing. The proposal is quite clear about the delta to ExplicitNameSpaces. The fact that the latter is not well specified isn't the current author's fault; and the delta makes sense as part of this proposal. I think we should accept this one, and politely ask the author if they would consider (as a favour) writing a delta to the ExplicitNameSpaces proposal (I assume there is one?) to clarify it. Simon On Mon, 12 Dec 2022 at 22:05, Chris Dornan wrote: > In this case, for sure, responsibility for fixing up namespace > documentation should not fall on the author of this proposal. I am thinking > more that they should be strongly encouraged to submit the follow-up > proposal and we provide or identify whatever assistance necessary to get > the job done. It will definitely get us to a better place in my view. > > It sounds like we are in strong agreement. > > Chris > > > > > On 12 Dec 2022, at 20:11, Adam Gundry wrote: > > > > On 12/12/2022 16:50, Chris Dornan wrote: > >> I really think we should split this proposal into two, one to deal with > warnings and the other to deal with namespaces. The warnings look to me > ready to go. > >> I am further thinking that we should really welcome the followup > namespace proposal as an opportunity to clarify and properly document > namespaces. > >> I am sorry, I was added to the proposal very late thinking it was > technically sound but I am realising it is far from the case. > >> Finally, I am quite surprised at how little documentation there seems > to be on ExplicitNamespaces. Should we be asking that revised documentation > be propared as part of the proposal process and that the documentation be > up to scratch? It seems the least we should be asking and much more > important than requiring an implementation plan. This process is > increasingly the only game in town when it comes to driving forward and > defining Haskell and we need to make sure stuff is being written down > properly. > > > > This is a bit of a tricky issue, I think. I agree that we should strive > for a proper specification of ExplicitNamespaces. The current state seems > to be sadly lacking, especially if we want ExplicitNamespaces to be in > GHC2023. That said, there's a risk that proposal authors will be > discouraged if proposing changes entails writing specifications for > existing under-specified features! > > > > I wonder if anyone has attempted to extend "A Formal Specification of > the Haskell 98 Module System" to more recent GHC extensions? > > > > Adam > > > > > >>> On 12 Dec 2022, at 12:21, Adam Gundry adam at well-typed.com>> wrote: > >>> > >>> On 12/12/2022 11:39, Simon Peyton Jones wrote: > >>>> {-# LANGUAGE ExplicitNamespaces #-} > >>>> module N where > >>>> import M (T(type MkT)) -- NB "type" import of a data > constructor > >>>> v = MkT -- usage at term level Crumbs. I had > not realised the proposal is to allow *nested* uses of 'type' in import > lists, as you show above. > >>> > >>> The nested use is already possible with ExplicitNamespaces. Currently > it allows > >>> > >>> import M (T(type MkT)) > >>> import M (type MkT) > >>> import M (pattern MkT) > >>> > >>> whereas the proposal extends it to add the possibility to write > >>> > >>> import M type (MkT) > >>> import M data (MkT) > >>> import M (data MkT) > >>> > >>> > >>>> In general, I don't feel the extensions to ExplicitNamespaces > included > >>>> in the proposal are very clearly specified. Actually isn't the > proposal pretty clear on this, namely the first bullet of proposed change > spec < > https://github.com/hithroc/ghc-proposals/blob/master/proposals/0000-support-pun-free-code.md#2-proposed-change-specification > < > https://github.com/hithroc/ghc-proposals/blob/master/proposals/0000-support-pun-free-code.md#2-proposed-change-specification>>. > It only covers > >>>> import M *type * > >>>> import M *data *as MD > >>>> where I have emboldened the new bits. Nothing about the contents of > import lists. Why did you think your example is covered by the proposal? > >>> > >>> I'm trying to understand what > >>> > >>> import M type (MkT) > >>> > >>> means where MkT is a data constructor (or if it raises some kind of > error). This was by analogy to the existing > >>> > >>> import M (T(type MkT)) > >>> > >>> which means something today, albeit not necessarily a very sensible > thing (per https://gitlab.haskell.org/ghc/ghc/-/issues/22581 < > https://gitlab.haskell.org/ghc/ghc/-/issues/22581>). > >>> > >>> I don't see a clear specification of the proposed (extended) semantics > of ExplicitNamespaces in the proposal, but perhaps I've missed something? > >>> > >>> Cheers, > >>> > >>> Adam > >>> > >>> > >>>> On Mon, 12 Dec 2022 at 09:15, Adam Gundry adam at well-typed.com>>> wrote: > >>>> Actually, reading > https://gitlab.haskell.org/ghc/ghc/-/issues/22581 < > https://gitlab.haskell.org/ghc/ghc/-/issues/22581> > >>>> https://gitlab.haskell.org/ghc/ghc/-/issues/22581>> I > >>>> realised I'm unclear how the proposed extensions to > ExplicitNamespaces > >>>> are supposed to work. The existing situation is apparently that > for a > >>>> (non-punned) data constructor, it is possible to use either a > >>>> pattern or > >>>> type qualifier in an import list (presumably because DataKinds > means > >>>> the > >>>> constructor is in scope at both the term and type levels), and the > >>>> imported constructor is then usable in both contexts. > >>>> For example, the following is accepted at present: > >>>> module M where > >>>> data T = MkT > >>>> {-# LANGUAGE ExplicitNamespaces #-} > >>>> module N where > >>>> import M (T(type MkT)) -- NB "type" import of a data > constructor > >>>> v = MkT -- usage at term level > >>>> The present proposal says "With type specified in the import, only > >>>> identifiers belonging to the type namespace will be brought into > the > >>>> scope." I'm not exactly sure how to interpret this, does it mean > the > >>>> following alternative will be accepted or rejected? > >>>> module N where > >>>> import M type (MkT) > >>>> v = MkT > >>>> I'm worried we will end up with a situation where > ExplicitNamespaces > >>>> does subtly different things depending on the position of the > keyword. > >>>> In general, I don't feel the extensions to ExplicitNamespaces > included > >>>> in the proposal are very clearly specified. Given the discussion > about > >>>> exactly which parts belong to ExplicitNamespaces/PatternSynonyms > versus > >>>> separate extensions, perhaps we should accept the parts relating to > >>>> -Wpuns/-Wpun-bindings, but ask for the ExplicitNamespaces changes > to be > >>>> proposed separately? > >>>> Cheers, > >>>> Adam > >>>> On 09/12/2022 11:11, Adam Gundry wrote: > >>>> > I'm broadly in favour of accepting the proposal. I realise the > >>>> history > >>>> > is complex here, so I don't think we should ask anyone to > rewrite > >>>> things > >>>> > further, though in general it would be nicer to have separate > >>>> proposals > >>>> > for -Wpuns/-Wpun-bindings (which is unambiguously fine) and for > the > >>>> > changes to imports (which as Joachim points out raise issues). > >>>> > > >>>> > I'm a bit concerned that the proposal does not motivate or > specify > >>>> > -Wpattern-namespace-qualified very well. > >>>> > > >>>> > > >>>> > On 08/12/2022 08:33, Joachim Breitner wrote: > >>>> >> ... > >>>> >> > >>>> >> This gives us (at least) these options: > >>>> >> > >>>> >> 1. Leave ExplicitNamespaces alone, add ExplicitNamespaces to > >>>> GHC2023, > >>>> >> introduce one or two new extensions for the newer changes. > >>>> >> 2. Extend ExplicitNamespaces, and don’t add it already to > GHC2023, > >>>> >> disregarding issue #551. > >>>> >> 3. Add ExplicitNamespaces to GHC2023, and still add it to > GHC2023, > >>>> >> arguing that GHC20xx allows more liberal > (backward-compatibile) > >>>> >> changes than, say, Haskell2010 would allow. > >>>> >> > >>>> >> Certainly 1 is the least bold move. I am not sure what the > best way > >>>> >> forwards is, and welcome other opinions. > >>>> > > >>>> > I would prefer a variant of 1: allow "data" as a keyword in > >>>> import lists > >>>> > under ExplicitNamespaces, but make the other changes under other > >>>> > extensions. > >>>> > > >>>> > As I've said previously, I have a general preference for > multiple > >>>> small, > >>>> > orthogonal extensions rather than changing existing extensions > to > >>>> add > >>>> > unrelated features that happen to be in similar territory. I > realise > >>>> > this is controversial, of course. > >>>> > > >>>> > Cheers, > >>>> > > >>>> > Adam > > > > > > -- > > Adam Gundry, Haskell Consultant > > Well-Typed LLP, https://www.well-typed.com/ > > > > Registered in England & Wales, OC335890 > > 27 Old Gloucester Street, London WC1N 3AX, England > > > > _______________________________________________ > > ghc-steering-committee mailing list > > ghc-steering-committee at haskell.org > > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee > > _______________________________________________ > ghc-steering-committee mailing list > ghc-steering-committee at haskell.org > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee > -------------- next part -------------- An HTML attachment was scrubbed... URL: From arnaud.spiwack at tweag.io Tue Dec 13 09:42:45 2022 From: arnaud.spiwack at tweag.io (Arnaud Spiwack) Date: Tue, 13 Dec 2022 10:42:45 +0100 Subject: [ghc-steering-committee] Why not?, rather than, why? In-Reply-To: References: <10594AD6-665D-4674-8E96-78AB6C61973A@chrisdornan.com> <6D754A68-7BC5-48AF-A6A8-B307D9FD02EB@chrisdornan.com> <010f0184f74380f9-b587b4d5-59af-4f09-8efe-4ad1745243ce-000000@us-east-2.amazonses.com> Message-ID: Thanks Richard for answering more comprehensively than I could have done myself. Simon: do you feel that Richard's email answers your question? On Fri, 9 Dec 2022 at 19:57, Joachim Breitner wrote: > Hi, > > this categorization is very helpful, I’ve been thinking about that as > well recently. Especially it’s worth keeping in mind that some language > extensions probably wouldn’t be language extensions these days, but > some other kind of flag (CPP, Safe, Trustworthy), and as you say > shouldn’t get in the way of finding a more coherent story for the > others. > > I think we should keep separate the category > > F: Enables new language features with not just a local (usually) > syntactic effect. (Litmus test: will a user of a module with that > extension tell). Mostly all the type-level feature extension (GADTs, > LinearTypes, TypeFamilies etc.) > > Some of these are also guarded by “new syntax” of sorts, but I think > they are fundamentally different from your category A. These are, in a > way, the most interesting ones! > > Cheers, > Joachim > > Am Freitag, dem 09.12.2022 um 14:21 +0000 schrieb Richard Eisenberg: > > Glancing through the list of extensions, I see a few broad > > categories: > > > > A. Extensions that simply enable new syntax. If users still want fine > > control over whether this syntax is allowed, each such extension > > could be converted to a warning -- but then all these extensions > > (except ones that are still experimental!) would be on by default. > > Maybe the warnings would be -Werror by default -- not sure. Examples: > > GADTSyntax, Arrows, InstanceSigs, StandaloneDeriving, and many more. > > > > B. Extensions that allow violation of some general principle that > > holds elsewhere. These should be replaced by modifiers or pragmas and > > be enabled locally. Examples: OverlappingInstances (this is already > > done!), NoMonomorphismRestriction, DeepSubsumption(*), > > UndecidableSuperClasses, NoMonoLocalBinds, etc. > > > > (*): Given the hue and cry about this one, perhaps there should be a > > flag to control the behavior. > > > > C. Extensions that change the compilation pipeline. These need to > > remain as configuration flags. Examples: CPP, TemplateHaskell. > > > > D. Extensions that create variants of the language by changing > > semantics of existing constructs. I'm not quite sure what to do with > > these, but they probably need to remain configuration flags. Even > > better if they could be enabled locally within a file, though. We > > should probably try to avoid doing this in the future, though the > > pain may be worth it. Examples: RebindableSyntax, Strict, > > OverloadedXXX, etc. > > > > Maybe some extensions fail to be categorized here, but this covers > > the vast, vast majority. > > -- > Joachim Breitner > mail at joachim-breitner.de > http://www.joachim-breitner.de/ > > _______________________________________________ > ghc-steering-committee mailing list > ghc-steering-committee at haskell.org > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee > -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.peytonjones at gmail.com Tue Dec 13 09:59:28 2022 From: simon.peytonjones at gmail.com (Simon Peyton Jones) Date: Tue, 13 Dec 2022 09:59:28 +0000 Subject: [ghc-steering-committee] Why not?, rather than, why? In-Reply-To: References: <10594AD6-665D-4674-8E96-78AB6C61973A@chrisdornan.com> <6D754A68-7BC5-48AF-A6A8-B307D9FD02EB@chrisdornan.com> <010f0184f74380f9-b587b4d5-59af-4f09-8efe-4ad1745243ce-000000@us-east-2.amazonses.com> Message-ID: > > Thanks Richard for answering more comprehensively than I could have done > myself. Simon: do you feel that Richard's email answers your question? > It contributes to an answer. *The problem(s) we seek to solve* Richard says We, as a committee, struggle to figure out a policy around extensions. This policy would help inform decisions such as: * whether proposal X needs to come with an extension, can modify a previous one, or needs no extension at all * how to evolve the set of extensions that are part of GHC20XX / the default set of extensions Beyond these real-world challenges that the committee has faced, we might also want to consider * how better to communicate the role extensions play in the Haskell language (anecdotes suggest the current story is off-putting to newcomers) * whether some extensions ought to be retired I'm OK with those as goals, although I have not found myself stuck on them. E.g. most proposals do come with an extension because they are, well, an extension. And user opinions frankly differ about the value and tempo of GHC20XX. *The proposed solution(s)* Richard comes up with a couple of categorisations, which are indeed helpful. But he stops short of any concrete proposals. 1. Declare that extensions are *experimental language features*, being evaluated for inclusion in the language proper. Gating some new syntax behind an extension theoretically allows us to experiment, improve, etc., until we are happy, and then we merge the feature into the language, with no extension needed. 2. Declare that extensions are *configuration flags*, meant to exist in perpetuity. In this way, extensions are a more powerful form of warning flag: not only can they dictate which programs are accepted, but sometimes they can be used to change the semantics of an accepted program. 3. Organize the set of extensions around an idea of *language levels*, where we classify different extensions according to the expected level of expertise of users working in the extended language. These aren't either/or choices. It's clear that - some really are configuration flags (Safe, RebindableSyntax; maybe punning) - some are definitely local, thin ice (UndecidableSuperclasses) -- the more we can turn these into local modifiers the better - some are really part of the language we'd like to see (PolyKinds, MultiParamTypeClasses) - some are experimental in the "Haskell as a laboratory" sense (Linear) I think that *classifying *them might be helpful; *choosing one *of these paths over the others seems infeasible to me. *What next?* I suppose the next step is for some motivated person to write a draft policy paper, so we can say "This is the GHC steering committee's policy on extensions". Maybe it too can be a GHC proposal (rather like the design principles one). It can certainly include the categorisations Richard suggests. Simon On Tue, 13 Dec 2022 at 09:43, Arnaud Spiwack wrote: > Thanks Richard for answering more comprehensively than I could have done > myself. Simon: do you feel that Richard's email answers your question? > > On Fri, 9 Dec 2022 at 19:57, Joachim Breitner > wrote: > >> Hi, >> >> this categorization is very helpful, I’ve been thinking about that as >> well recently. Especially it’s worth keeping in mind that some language >> extensions probably wouldn’t be language extensions these days, but >> some other kind of flag (CPP, Safe, Trustworthy), and as you say >> shouldn’t get in the way of finding a more coherent story for the >> others. >> >> I think we should keep separate the category >> >> F: Enables new language features with not just a local (usually) >> syntactic effect. (Litmus test: will a user of a module with that >> extension tell). Mostly all the type-level feature extension (GADTs, >> LinearTypes, TypeFamilies etc.) >> >> Some of these are also guarded by “new syntax” of sorts, but I think >> they are fundamentally different from your category A. These are, in a >> way, the most interesting ones! >> >> Cheers, >> Joachim >> >> Am Freitag, dem 09.12.2022 um 14:21 +0000 schrieb Richard Eisenberg: >> > Glancing through the list of extensions, I see a few broad >> > categories: >> > >> > A. Extensions that simply enable new syntax. If users still want fine >> > control over whether this syntax is allowed, each such extension >> > could be converted to a warning -- but then all these extensions >> > (except ones that are still experimental!) would be on by default. >> > Maybe the warnings would be -Werror by default -- not sure. Examples: >> > GADTSyntax, Arrows, InstanceSigs, StandaloneDeriving, and many more. >> > >> > B. Extensions that allow violation of some general principle that >> > holds elsewhere. These should be replaced by modifiers or pragmas and >> > be enabled locally. Examples: OverlappingInstances (this is already >> > done!), NoMonomorphismRestriction, DeepSubsumption(*), >> > UndecidableSuperClasses, NoMonoLocalBinds, etc. >> > >> > (*): Given the hue and cry about this one, perhaps there should be a >> > flag to control the behavior. >> > >> > C. Extensions that change the compilation pipeline. These need to >> > remain as configuration flags. Examples: CPP, TemplateHaskell. >> > >> > D. Extensions that create variants of the language by changing >> > semantics of existing constructs. I'm not quite sure what to do with >> > these, but they probably need to remain configuration flags. Even >> > better if they could be enabled locally within a file, though. We >> > should probably try to avoid doing this in the future, though the >> > pain may be worth it. Examples: RebindableSyntax, Strict, >> > OverloadedXXX, etc. >> > >> > Maybe some extensions fail to be categorized here, but this covers >> > the vast, vast majority. >> >> -- >> Joachim Breitner >> mail at joachim-breitner.de >> http://www.joachim-breitner.de/ >> >> _______________________________________________ >> 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 chris at chrisdornan.com Tue Dec 13 15:50:55 2022 From: chris at chrisdornan.com (Chris Dornan) Date: Tue, 13 Dec 2022 15:50:55 +0000 Subject: [ghc-steering-committee] Proposal #270: Support pun-free code. Recommendation: accept In-Reply-To: References: <5D0E3610-C73F-4850-9435-8D22069382BD@chrisdornan.com> <2da00f7f92f292bb16a4dfc53ec62d68ecf6edc9.camel@joachim-breitner.de> <3267a53a47cec3597c54bab8f8518b2c1613e1a8.camel@joachim-breitner.de> <0e9b3372-5034-f596-acd2-aecc3c7be701@well-typed.com> <089f0c63-ed84-186f-6f70-0372b95e4c3e@well-typed.com> <14cede64-5f45-b6d1-e17a-cd1bb9cd106a@well-typed.com> <9B22308E-170D-4B86-BFF8-1E63D3DF5387@chrisdornan.com> <84D37F3F-FC1D-4B57-BE99-B355419E8EA4@chrisdornan.com> Message-ID: <428DC3AB-9C06-4950-9151-7B22F5079A1A@chrisdornan.com> Although the two aspects of the proposal were motivated by the same problem they are doing completely different things. As long as it was easier to deal with them together the path of least resistance was to keep them bundled up, but it is becoming ever clearer that they are tied up in divergent organisational as well as technical concerns. The warnings are well understood and ready to go with a patch whereas, as this thread illustrates, nobody seems to properly understand what is going on with ExplicitNameSpaces; we are still confident that we can sort it all out and confident that we want to sort it all out but still there is work to be done. Added to this there is the fact that the problems with namespaces are entirely inherited from an existing extension that is poorly documented and, as we have just discovered, poorly understood. For all the reasons explained in the proposal we are likely to be leaning more heavily on ExplicitNameSpaces as we develop DH so we really need sort out what it does and get it written down. Here is the kicker — when we do sort out ExplicitNameSpaces and write it up properly we are going to want it attached to language extension dedicated to managing ExplicitNameSpaces, not an extension bundled up with some enabled warnings. I am happy to work with Artyom to get the new proposal set up etc. Chris > On 13 Dec 2022, at 09:01, Simon Peyton Jones wrote: > > I still don't get the "split in two" thing. The proposal is quite clear about the delta to ExplicitNameSpaces. The fact that the latter is not well specified isn't the current author's fault; and the delta makes sense as part of this proposal. > > I think we should accept this one, and politely ask the author if they would consider (as a favour) writing a delta to the ExplicitNameSpaces proposal (I assume there is one?) to clarify it. > > Simon > > On Mon, 12 Dec 2022 at 22:05, Chris Dornan > wrote: > In this case, for sure, responsibility for fixing up namespace documentation should not fall on the author of this proposal. I am thinking more that they should be strongly encouraged to submit the follow-up proposal and we provide or identify whatever assistance necessary to get the job done. It will definitely get us to a better place in my view. > > It sounds like we are in strong agreement. > > Chris > > > > > On 12 Dec 2022, at 20:11, Adam Gundry > wrote: > > > > On 12/12/2022 16:50, Chris Dornan wrote: > >> I really think we should split this proposal into two, one to deal with warnings and the other to deal with namespaces. The warnings look to me ready to go. > >> I am further thinking that we should really welcome the followup namespace proposal as an opportunity to clarify and properly document namespaces. > >> I am sorry, I was added to the proposal very late thinking it was technically sound but I am realising it is far from the case. > >> Finally, I am quite surprised at how little documentation there seems to be on ExplicitNamespaces. Should we be asking that revised documentation be propared as part of the proposal process and that the documentation be up to scratch? It seems the least we should be asking and much more important than requiring an implementation plan. This process is increasingly the only game in town when it comes to driving forward and defining Haskell and we need to make sure stuff is being written down properly. > > > > This is a bit of a tricky issue, I think. I agree that we should strive for a proper specification of ExplicitNamespaces. The current state seems to be sadly lacking, especially if we want ExplicitNamespaces to be in GHC2023. That said, there's a risk that proposal authors will be discouraged if proposing changes entails writing specifications for existing under-specified features! > > > > I wonder if anyone has attempted to extend "A Formal Specification of the Haskell 98 Module System" to more recent GHC extensions? > > > > Adam > > > > > >>> On 12 Dec 2022, at 12:21, Adam Gundry >> wrote: > >>> > >>> On 12/12/2022 11:39, Simon Peyton Jones wrote: > >>>> {-# LANGUAGE ExplicitNamespaces #-} > >>>> module N where > >>>> import M (T(type MkT)) -- NB "type" import of a data constructor > >>>> v = MkT -- usage at term level Crumbs. I had not realised the proposal is to allow *nested* uses of 'type' in import lists, as you show above. > >>> > >>> The nested use is already possible with ExplicitNamespaces. Currently it allows > >>> > >>> import M (T(type MkT)) > >>> import M (type MkT) > >>> import M (pattern MkT) > >>> > >>> whereas the proposal extends it to add the possibility to write > >>> > >>> import M type (MkT) > >>> import M data (MkT) > >>> import M (data MkT) > >>> > >>> > >>>> In general, I don't feel the extensions to ExplicitNamespaces included > >>>> in the proposal are very clearly specified. Actually isn't the proposal pretty clear on this, namely the first bullet of proposed change spec >>. It only covers > >>>> import M *type * > >>>> import M *data *as MD > >>>> where I have emboldened the new bits. Nothing about the contents of import lists. Why did you think your example is covered by the proposal? > >>> > >>> I'm trying to understand what > >>> > >>> import M type (MkT) > >>> > >>> means where MkT is a data constructor (or if it raises some kind of error). This was by analogy to the existing > >>> > >>> import M (T(type MkT)) > >>> > >>> which means something today, albeit not necessarily a very sensible thing (per https://gitlab.haskell.org/ghc/ghc/-/issues/22581 >). > >>> > >>> I don't see a clear specification of the proposed (extended) semantics of ExplicitNamespaces in the proposal, but perhaps I've missed something? > >>> > >>> Cheers, > >>> > >>> Adam > >>> > >>> > >>>> On Mon, 12 Dec 2022 at 09:15, Adam Gundry > >>> wrote: > >>>> Actually, reading https://gitlab.haskell.org/ghc/ghc/-/issues/22581 > > >>>> >> I > >>>> realised I'm unclear how the proposed extensions to ExplicitNamespaces > >>>> are supposed to work. The existing situation is apparently that for a > >>>> (non-punned) data constructor, it is possible to use either a > >>>> pattern or > >>>> type qualifier in an import list (presumably because DataKinds means > >>>> the > >>>> constructor is in scope at both the term and type levels), and the > >>>> imported constructor is then usable in both contexts. > >>>> For example, the following is accepted at present: > >>>> module M where > >>>> data T = MkT > >>>> {-# LANGUAGE ExplicitNamespaces #-} > >>>> module N where > >>>> import M (T(type MkT)) -- NB "type" import of a data constructor > >>>> v = MkT -- usage at term level > >>>> The present proposal says "With type specified in the import, only > >>>> identifiers belonging to the type namespace will be brought into the > >>>> scope." I'm not exactly sure how to interpret this, does it mean the > >>>> following alternative will be accepted or rejected? > >>>> module N where > >>>> import M type (MkT) > >>>> v = MkT > >>>> I'm worried we will end up with a situation where ExplicitNamespaces > >>>> does subtly different things depending on the position of the keyword. > >>>> In general, I don't feel the extensions to ExplicitNamespaces included > >>>> in the proposal are very clearly specified. Given the discussion about > >>>> exactly which parts belong to ExplicitNamespaces/PatternSynonyms versus > >>>> separate extensions, perhaps we should accept the parts relating to > >>>> -Wpuns/-Wpun-bindings, but ask for the ExplicitNamespaces changes to be > >>>> proposed separately? > >>>> Cheers, > >>>> Adam > >>>> On 09/12/2022 11:11, Adam Gundry wrote: > >>>> > I'm broadly in favour of accepting the proposal. I realise the > >>>> history > >>>> > is complex here, so I don't think we should ask anyone to rewrite > >>>> things > >>>> > further, though in general it would be nicer to have separate > >>>> proposals > >>>> > for -Wpuns/-Wpun-bindings (which is unambiguously fine) and for the > >>>> > changes to imports (which as Joachim points out raise issues). > >>>> > > >>>> > I'm a bit concerned that the proposal does not motivate or specify > >>>> > -Wpattern-namespace-qualified very well. > >>>> > > >>>> > > >>>> > On 08/12/2022 08:33, Joachim Breitner wrote: > >>>> >> ... > >>>> >> > >>>> >> This gives us (at least) these options: > >>>> >> > >>>> >> 1. Leave ExplicitNamespaces alone, add ExplicitNamespaces to > >>>> GHC2023, > >>>> >> introduce one or two new extensions for the newer changes. > >>>> >> 2. Extend ExplicitNamespaces, and don’t add it already to GHC2023, > >>>> >> disregarding issue #551. > >>>> >> 3. Add ExplicitNamespaces to GHC2023, and still add it to GHC2023, > >>>> >> arguing that GHC20xx allows more liberal (backward-compatibile) > >>>> >> changes than, say, Haskell2010 would allow. > >>>> >> > >>>> >> Certainly 1 is the least bold move. I am not sure what the best way > >>>> >> forwards is, and welcome other opinions. > >>>> > > >>>> > I would prefer a variant of 1: allow "data" as a keyword in > >>>> import lists > >>>> > under ExplicitNamespaces, but make the other changes under other > >>>> > extensions. > >>>> > > >>>> > As I've said previously, I have a general preference for multiple > >>>> small, > >>>> > orthogonal extensions rather than changing existing extensions to > >>>> add > >>>> > unrelated features that happen to be in similar territory. I realise > >>>> > this is controversial, of course. > >>>> > > >>>> > Cheers, > >>>> > > >>>> > Adam > > > > > > -- > > Adam Gundry, Haskell Consultant > > Well-Typed LLP, https://www.well-typed.com/ > > > > Registered in England & Wales, OC335890 > > 27 Old Gloucester Street, London WC1N 3AX, England > > > > _______________________________________________ > > ghc-steering-committee mailing list > > ghc-steering-committee at haskell.org > > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee > > _______________________________________________ > ghc-steering-committee mailing list > ghc-steering-committee at haskell.org > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee -------------- next part -------------- An HTML attachment was scrubbed... URL: From chris at chrisdornan.com Tue Dec 13 17:08:58 2022 From: chris at chrisdornan.com (Chris Dornan) Date: Tue, 13 Dec 2022 17:08:58 +0000 Subject: [ghc-steering-committee] Why not?, rather than, why? In-Reply-To: References: <10594AD6-665D-4674-8E96-78AB6C61973A@chrisdornan.com> <6D754A68-7BC5-48AF-A6A8-B307D9FD02EB@chrisdornan.com> <010f0184f74380f9-b587b4d5-59af-4f09-8efe-4ad1745243ce-000000@us-east-2.amazonses.com> Message-ID: <3E3D9896-8C1E-4484-95D6-0BCD1E2C6F43@chrisdornan.com> It is very fashionable to dunk on GHC language extensions but I think it is worth considering where we would be without them — probably Haskell 98 and a nice Wikipedia page explaining how influential Haskell was — a remarkable academic experiment, but practically speaking, like FP and KRC and Hope, a dead programming language. I had a period in the late naughties away from Haskell and I thought it was great to be able to work with the familiar Haskell 98 and page in the developments as I needed them, and easily locate documentation, papers and articles on those proposals. The modularity that extensions provide is a real practical strength that is often overlooked. Further to that, I find it quite difficult to get my head around the sheer vitality of Haskell today. It was tempting to conclude that Haskell2010 would be the last harrah but building Haskell code bases in 2022 is really quite different and a *much* more rewarding and more productive exercise in my opinion, thanks to generics and the ingenious exploration of newtype, especially with DerivingVia. This is really quite separate from all the work on TLP and DH — I am talking about the very practical business of building, organising and maintaining non-trivial Haskell code bases. I love the way we have become keen to learn from other successes like Rust but I fear we could repeat past mistakes in a dash to force Haskell, and the Haskell community, into a particular shape so that it can compete. I think we should have more confidence in what has got us to where we are — and there is no doubt in my mind that it is the enduring vitality of Haskell that flows from its open philosophy, open to allcomers and open to creative experimentation. I think the intrinsic diversity we see at all levels of the community is important to that creative process which is why I get a little despondent when I see calls to eliminate that diversity. People see the language extensions in different ways depending on the problems they are trying to solve and those problems are arising in great array of different contexts — and that feeds vitality is what keeps us moving forward (like the proverbial shark). I understand that we can’t just allow ourselves to suffer a chaotic heat death and we need a continuous effort to analyse and organise, but I look at the diversity of thought and approaches and see the basis of a vibrant future. I just ask that we seek to organise and not to develop a monoculture. Which is all by way of saying that I think the diversity we see in the extensions and the different ways of understanding them as important to the whole enterprise and take care with any drives to rationalise them into a more coherent structure. Chris > On 13 Dec 2022, at 09:59, Simon Peyton Jones wrote: > > Thanks Richard for answering more comprehensively than I could have done myself. Simon: do you feel that Richard's email answers your question? > > It contributes to an answer. > > The problem(s) we seek to solve > > Richard says > > We, as a committee, struggle to figure out a policy around extensions. This policy would help inform decisions such as: > * whether proposal X needs to come with an extension, can modify a previous one, or needs no extension at all > * how to evolve the set of extensions that are part of GHC20XX / the default set of extensions > Beyond these real-world challenges that the committee has faced, we might also want to consider > * how better to communicate the role extensions play in the Haskell language (anecdotes suggest the current story is off-putting to newcomers) > * whether some extensions ought to be retired > > I'm OK with those as goals, although I have not found myself stuck on them. E.g. most proposals do come with an extension because they are, well, an extension. And user opinions frankly differ about the value and tempo of GHC20XX. > > The proposed solution(s) > > Richard comes up with a couple of categorisations, which are indeed helpful. But he stops short of any concrete proposals. > > 1. Declare that extensions are experimental language features, being evaluated for inclusion in the language proper. Gating some new syntax behind an extension theoretically allows us to experiment, improve, etc., until we are happy, and then we merge the feature into the language, with no extension needed. > 2. Declare that extensions are configuration flags, meant to exist in perpetuity. In this way, extensions are a more powerful form of warning flag: not only can they dictate which programs are accepted, but sometimes they can be used to change the semantics of an accepted program. > 3. Organize the set of extensions around an idea of language levels, where we classify different extensions according to the expected level of expertise of users working in the extended language. > > These aren't either/or choices. It's clear that > some really are configuration flags (Safe, RebindableSyntax; maybe punning) > some are definitely local, thin ice (UndecidableSuperclasses) -- the more we can turn these into local modifiers the better > some are really part of the language we'd like to see (PolyKinds, MultiParamTypeClasses) > some are experimental in the "Haskell as a laboratory" sense (Linear) > I think that classifying them might be helpful; choosing one of these paths over the others seems infeasible to me. > > What next? > > I suppose the next step is for some motivated person to write a draft policy paper, so we can say "This is the GHC steering committee's policy on extensions". Maybe it too can be a GHC proposal (rather like the design principles one). It can certainly include the categorisations Richard suggests. > > Simon > > > > On Tue, 13 Dec 2022 at 09:43, Arnaud Spiwack > wrote: > Thanks Richard for answering more comprehensively than I could have done myself. Simon: do you feel that Richard's email answers your question? > > On Fri, 9 Dec 2022 at 19:57, Joachim Breitner > wrote: > Hi, > > this categorization is very helpful, I’ve been thinking about that as > well recently. Especially it’s worth keeping in mind that some language > extensions probably wouldn’t be language extensions these days, but > some other kind of flag (CPP, Safe, Trustworthy), and as you say > shouldn’t get in the way of finding a more coherent story for the > others. > > I think we should keep separate the category > > F: Enables new language features with not just a local (usually) > syntactic effect. (Litmus test: will a user of a module with that > extension tell). Mostly all the type-level feature extension (GADTs, > LinearTypes, TypeFamilies etc.) > > Some of these are also guarded by “new syntax” of sorts, but I think > they are fundamentally different from your category A. These are, in a > way, the most interesting ones! > > Cheers, > Joachim > > Am Freitag, dem 09.12.2022 um 14:21 +0000 schrieb Richard Eisenberg: > > Glancing through the list of extensions, I see a few broad > > categories: > > > > A. Extensions that simply enable new syntax. If users still want fine > > control over whether this syntax is allowed, each such extension > > could be converted to a warning -- but then all these extensions > > (except ones that are still experimental!) would be on by default. > > Maybe the warnings would be -Werror by default -- not sure. Examples: > > GADTSyntax, Arrows, InstanceSigs, StandaloneDeriving, and many more. > > > > B. Extensions that allow violation of some general principle that > > holds elsewhere. These should be replaced by modifiers or pragmas and > > be enabled locally. Examples: OverlappingInstances (this is already > > done!), NoMonomorphismRestriction, DeepSubsumption(*), > > UndecidableSuperClasses, NoMonoLocalBinds, etc. > > > > (*): Given the hue and cry about this one, perhaps there should be a > > flag to control the behavior. > > > > C. Extensions that change the compilation pipeline. These need to > > remain as configuration flags. Examples: CPP, TemplateHaskell. > > > > D. Extensions that create variants of the language by changing > > semantics of existing constructs. I'm not quite sure what to do with > > these, but they probably need to remain configuration flags. Even > > better if they could be enabled locally within a file, though. We > > should probably try to avoid doing this in the future, though the > > pain may be worth it. Examples: RebindableSyntax, Strict, > > OverloadedXXX, etc. > > > > Maybe some extensions fail to be categorized here, but this covers > > the vast, vast majority. > > -- > Joachim Breitner > mail at joachim-breitner.de > http://www.joachim-breitner.de/ > > _______________________________________________ > 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.peytonjones at gmail.com Tue Dec 13 17:47:06 2022 From: simon.peytonjones at gmail.com (Simon Peyton Jones) Date: Tue, 13 Dec 2022 17:47:06 +0000 Subject: [ghc-steering-committee] Why not?, rather than, why? In-Reply-To: <3E3D9896-8C1E-4484-95D6-0BCD1E2C6F43@chrisdornan.com> References: <10594AD6-665D-4674-8E96-78AB6C61973A@chrisdornan.com> <6D754A68-7BC5-48AF-A6A8-B307D9FD02EB@chrisdornan.com> <010f0184f74380f9-b587b4d5-59af-4f09-8efe-4ad1745243ce-000000@us-east-2.amazonses.com> <3E3D9896-8C1E-4484-95D6-0BCD1E2C6F43@chrisdornan.com> Message-ID: > > there is no doubt in my mind that it is the enduring vitality of Haskell > that flows from its open philosophy, open to allcomers and open to creative > experimentation. > Strong +1 Simon On Tue, 13 Dec 2022 at 17:09, Chris Dornan wrote: > It is very fashionable to dunk on GHC language extensions but I think it > is worth considering where we would be without them — probably Haskell 98 > and a nice Wikipedia page explaining how influential Haskell was — a > remarkable academic experiment, but practically speaking, like FP and KRC > and Hope, a dead programming language. > > I had a period in the late naughties away from Haskell and I thought it > was great to be able to work with the familiar Haskell 98 and page in the > developments as I needed them, and easily locate documentation, papers and > articles on those proposals. The modularity that extensions provide is a > real practical strength that is often overlooked. > > Further to that, I find it quite difficult to get my head around the sheer > vitality of Haskell today. It was tempting to conclude that Haskell2010 > would be the last harrah but building Haskell code bases in 2022 is really > quite different and a *much* more rewarding and more productive exercise in > my opinion, thanks to generics and the ingenious exploration of newtype, > especially with DerivingVia. This is really quite separate from all the > work on TLP and DH — I am talking about the very practical business of > building, organising and maintaining non-trivial Haskell code bases. > > I love the way we have become keen to learn from other successes like Rust > but I fear we could repeat past mistakes in a dash to force Haskell, and > the Haskell community, into a particular shape so that it can compete. I > think we should have more confidence in what has got us to where we are — > and there is no doubt in my mind that it is the enduring vitality of > Haskell that flows from its open philosophy, open to allcomers and open to > creative experimentation. > > I think the intrinsic diversity we see at all levels of the community is > important to that creative process which is why I get a little despondent > when I see calls to eliminate that diversity. People see the language > extensions in different ways depending on the problems they are trying to > solve and those problems are arising in great array of different contexts — > and that feeds vitality is what keeps us moving forward (like the > proverbial shark). > > I understand that we can’t just allow ourselves to suffer a chaotic heat > death and we need a continuous effort to analyse and organise, but I look > at the diversity of thought and approaches and see the basis of a vibrant > future. I just ask that we seek to organise and not to develop a > monoculture. > > Which is all by way of saying that I think the diversity we see in the > extensions and the different ways of understanding them as important to the > whole enterprise and take care with any drives to rationalise them into a > more coherent structure. > > Chris > > > On 13 Dec 2022, at 09:59, Simon Peyton Jones > wrote: > > Thanks Richard for answering more comprehensively than I could have done >> myself. Simon: do you feel that Richard's email answers your question? >> > > It contributes to an answer. > > *The problem(s) we seek to solve* > > Richard says > > We, as a committee, struggle to figure out a policy around extensions. > This policy would help inform decisions such as: > * whether proposal X needs to come with an extension, can modify a > previous one, or needs no extension at all > * how to evolve the set of extensions that are part of GHC20XX / the > default set of extensions > Beyond these real-world challenges that the committee has faced, we might > also want to consider > * how better to communicate the role extensions play in the Haskell > language (anecdotes suggest the current story is off-putting to newcomers) > * whether some extensions ought to be retired > > I'm OK with those as goals, although I have not found myself stuck on > them. E.g. most proposals do come with an extension because they are, > well, an extension. And user opinions frankly differ about the value and > tempo of GHC20XX. > > *The proposed solution(s)* > > Richard comes up with a couple of categorisations, which are indeed > helpful. But he stops short of any concrete proposals. > > 1. Declare that extensions are *experimental language features*, being > evaluated for inclusion in the language proper. Gating some new syntax > behind an extension theoretically allows us to experiment, improve, etc., > until we are happy, and then we merge the feature into the language, with > no extension needed. > 2. Declare that extensions are *configuration flags*, meant to exist in > perpetuity. In this way, extensions are a more powerful form of warning > flag: not only can they dictate which programs are accepted, but sometimes > they can be used to change the semantics of an accepted program. > 3. Organize the set of extensions around an idea of *language levels*, > where we classify different extensions according to the expected level of > expertise of users working in the extended language. > > These aren't either/or choices. It's clear that > > - some really are configuration flags (Safe, RebindableSyntax; maybe > punning) > - some are definitely local, thin ice (UndecidableSuperclasses) -- the > more we can turn these into local modifiers the better > - some are really part of the language we'd like to see (PolyKinds, > MultiParamTypeClasses) > - some are experimental in the "Haskell as a laboratory" sense (Linear) > > I think that *classifying *them might be helpful; *choosing one *of these > paths over the others seems infeasible to me. > > *What next?* > > I suppose the next step is for some motivated person to write a draft > policy paper, so we can say "This is the GHC steering committee's policy on > extensions". Maybe it too can be a GHC proposal (rather like the design > principles one). It can certainly include the categorisations Richard > suggests. > > Simon > > > > On Tue, 13 Dec 2022 at 09:43, Arnaud Spiwack > wrote: > >> Thanks Richard for answering more comprehensively than I could have done >> myself. Simon: do you feel that Richard's email answers your question? >> >> On Fri, 9 Dec 2022 at 19:57, Joachim Breitner >> wrote: >> >>> Hi, >>> >>> this categorization is very helpful, I’ve been thinking about that as >>> well recently. Especially it’s worth keeping in mind that some language >>> extensions probably wouldn’t be language extensions these days, but >>> some other kind of flag (CPP, Safe, Trustworthy), and as you say >>> shouldn’t get in the way of finding a more coherent story for the >>> others. >>> >>> I think we should keep separate the category >>> >>> F: Enables new language features with not just a local (usually) >>> syntactic effect. (Litmus test: will a user of a module with that >>> extension tell). Mostly all the type-level feature extension (GADTs, >>> LinearTypes, TypeFamilies etc.) >>> >>> Some of these are also guarded by “new syntax” of sorts, but I think >>> they are fundamentally different from your category A. These are, in a >>> way, the most interesting ones! >>> >>> Cheers, >>> Joachim >>> >>> Am Freitag, dem 09.12.2022 um 14:21 +0000 schrieb Richard Eisenberg: >>> > Glancing through the list of extensions, I see a few broad >>> > categories: >>> > >>> > A. Extensions that simply enable new syntax. If users still want fine >>> > control over whether this syntax is allowed, each such extension >>> > could be converted to a warning -- but then all these extensions >>> > (except ones that are still experimental!) would be on by default. >>> > Maybe the warnings would be -Werror by default -- not sure. Examples: >>> > GADTSyntax, Arrows, InstanceSigs, StandaloneDeriving, and many more. >>> > >>> > B. Extensions that allow violation of some general principle that >>> > holds elsewhere. These should be replaced by modifiers or pragmas and >>> > be enabled locally. Examples: OverlappingInstances (this is already >>> > done!), NoMonomorphismRestriction, DeepSubsumption(*), >>> > UndecidableSuperClasses, NoMonoLocalBinds, etc. >>> > >>> > (*): Given the hue and cry about this one, perhaps there should be a >>> > flag to control the behavior. >>> > >>> > C. Extensions that change the compilation pipeline. These need to >>> > remain as configuration flags. Examples: CPP, TemplateHaskell. >>> > >>> > D. Extensions that create variants of the language by changing >>> > semantics of existing constructs. I'm not quite sure what to do with >>> > these, but they probably need to remain configuration flags. Even >>> > better if they could be enabled locally within a file, though. We >>> > should probably try to avoid doing this in the future, though the >>> > pain may be worth it. Examples: RebindableSyntax, Strict, >>> > OverloadedXXX, etc. >>> > >>> > Maybe some extensions fail to be categorized here, but this covers >>> > the vast, vast majority. >>> >>> -- >>> Joachim Breitner >>> mail at joachim-breitner.de >>> http://www.joachim-breitner.de/ >>> >>> _______________________________________________ >>> 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 > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From arnaud.spiwack at tweag.io Wed Dec 14 07:08:55 2022 From: arnaud.spiwack at tweag.io (Arnaud Spiwack) Date: Wed, 14 Dec 2022 08:08:55 +0100 Subject: [ghc-steering-committee] Proposal #532: Clean up and simplify the treatment of implicit bindings. Recommendation: partially accept (maybe) Message-ID: Dear all, Proposal https://github.com/ghc-proposals/ghc-proposals/pull/532 Rendered link for the proposal (although several other files are modified): https://github.com/Ericson2314/ghc-proposals/blob/type-variables/proposals/0532-type-variable-scoping.rst John Ericson proposes to amend Richard's recent Modern Scoped Type Variables Proposal [ https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0448-type-variable-scoping.rst ] There are two essential parts to the change: 1. The Explicit Binding Principle is modified 2. Change the two extensions introduced by Proposal #285 [ https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0285-no-implicit-binds.rst ], -XImplicitForalls and -XPatternSignatureBinds (so that they can be deactivated), and consolidated in Richard's proposal (where -XPatternSignatureBinds is turned into a binding) into a single -XImplicitBinds extension --------- The new Explicit Binding Principle is now somewhat stronger, in that it requires that there is a form with an explicit binder which “regardless of the context, is unambiguously a binding site”. The Lexical Binding Principle is changed, as well, to refer to this new change but it's not substantial. I personally don't think this change to the principles is valuable, it simply blurs the distinction between the Explicit Binding Principle and the Lexical Binding Principle. I find the current phrasing more useful. And I don't think the semantics of the conjunction is actually changed. So I recommend that we reject the changes to the Principles. ------------ John makes a good point: `-XPatternSignature` being a warning has a limitation. This is pointed out in section “Unified Namespacing and extension monotonicity” of the patch to the Modern Scoped Type Variables Proposal. Namely that in t = Int (x :: t) = 0 The current semantics is to have `t` be a binder (because `t` is not bound in the type namespace). If we add a warning for pattern signatures binders, `t` will still be a binder. But we are starting to introduce a new semantics where failing to lookup `t` in the type namespace, we will fall back to look it up in the term namespace instead. The current semantics of considering `t` a binder in this case is at odds with the fallback strategy. (crucially for this recommendation, the same issue occurs in signatures where `forall`-s are implicitly inferred) (Context: At the time where #285 was proposed, I was in favour of a single extension. Simon PJ strongly pushed for two extensions.) My inclination today is that we have a choice: we can either - consider the problem above to be a serious issue, in which case we probably want to eventually deprecate both implicit foralls and pattern signature binds. If this is the case, then they should be gated behind an extension (see also the discussion on the meaning of extensions that we're currently having). I find it healthy to have a single extension for both features because the problem that the extension is solving is the same, hence, in this case, I recommend accepting the changes. - be happy that the semantics is a little quirky, with the fallback happening only when an explicit forall is specified (and never in pattern signatures). In which case both should probably be warnings, it makes sense for the warnings to be separate categories as these are two different features. In this case I recommend rejection of the proposed changes. ------------ I realise I'm leaving a big choice hanging. It's a big decision, I think, which we should weigh carefully (which is kind of funny because the proposed change itself is rather small). Personally, I'd be happy with all implicit foralls and pattern signature binds to be deprecated (so I'm actually taking a position I guess). But I'm not sure that it's super realistic considering the quantity of Haskell that has been written so far. I imagine that there are millions of implicit foralls on Hackage. PS: I'll be on holiday for the next three weeks (starting on Friday night), so you'll have a little while to debate this while I'm away. -------------- next part -------------- An HTML attachment was scrubbed... URL: From marlowsd at gmail.com Wed Dec 14 11:05:12 2022 From: marlowsd at gmail.com (Simon Marlow) Date: Wed, 14 Dec 2022 11:05:12 +0000 Subject: [ghc-steering-committee] Why not?, rather than, why? In-Reply-To: References: <10594AD6-665D-4674-8E96-78AB6C61973A@chrisdornan.com> <6D754A68-7BC5-48AF-A6A8-B307D9FD02EB@chrisdornan.com> <010f0184f74380f9-b587b4d5-59af-4f09-8efe-4ad1745243ce-000000@us-east-2.amazonses.com> Message-ID: Yes, thankyou Richard! I agree with virtually everything. > B. Extensions that allow violation of some general principle that holds elsewhere. These should be replaced by modifiers or pragmas and be enabled locally. Examples: OverlappingInstances (this is already done!), NoMonomorphismRestriction, DeepSubsumption(*), UndecidableSuperClasses, NoMonoLocalBinds, etc. I think it's worth making a further distinction according to whether the relaxation is thought to be unsound or not-well-founded for some reason (NoMonoLocalBinds, DeepSubsumption) and those that are well understood and not problematic at all (NoMonomorphismRestriction). The latter should just be treated like the syntax extensions: either experimental or enabled by default. > C. Extensions that change the compilation pipeline. These need to remain as configuration flags. Examples: CPP, TemplateHaskell. It's clear that CPP needs to remain as a flag because it does bad things to the syntax like breaking multiline strings and doing strange things to `##`. But it's less clear to me that TemplateHaskell is in this category. Isn't it just an extension that enables new syntax? Yes there are *practical* reasons why we might not want it on by default, because it makes compilation slower and whatnot, but isn't that all it is? > D. Extensions that create variants of the language by changing semantics of existing constructs. I'm not quite sure what to do with these, but they probably need to remain configuration flags. Even better if they could be enabled locally within a file, though. We should probably try to avoid doing this in the future, though the pain may be worth it. Examples: RebindableSyntax, Strict, OverloadedXXX, etc. Again I think we could refine this. Clearly RebindableSyntax and Strict are not features that we would ever want to be on by default, but OverloadedStrings definitely is, and for me belongs in the category of language extensions that are either in GHC20xx now or will be later. Cheers Simon On Tue, 13 Dec 2022 at 09:43, Arnaud Spiwack wrote: > Thanks Richard for answering more comprehensively than I could have done > myself. Simon: do you feel that Richard's email answers your question? > > On Fri, 9 Dec 2022 at 19:57, Joachim Breitner > wrote: > >> Hi, >> >> this categorization is very helpful, I’ve been thinking about that as >> well recently. Especially it’s worth keeping in mind that some language >> extensions probably wouldn’t be language extensions these days, but >> some other kind of flag (CPP, Safe, Trustworthy), and as you say >> shouldn’t get in the way of finding a more coherent story for the >> others. >> >> I think we should keep separate the category >> >> F: Enables new language features with not just a local (usually) >> syntactic effect. (Litmus test: will a user of a module with that >> extension tell). Mostly all the type-level feature extension (GADTs, >> LinearTypes, TypeFamilies etc.) >> >> Some of these are also guarded by “new syntax” of sorts, but I think >> they are fundamentally different from your category A. These are, in a >> way, the most interesting ones! >> >> Cheers, >> Joachim >> >> Am Freitag, dem 09.12.2022 um 14:21 +0000 schrieb Richard Eisenberg: >> > Glancing through the list of extensions, I see a few broad >> > categories: >> > >> > A. Extensions that simply enable new syntax. If users still want fine >> > control over whether this syntax is allowed, each such extension >> > could be converted to a warning -- but then all these extensions >> > (except ones that are still experimental!) would be on by default. >> > Maybe the warnings would be -Werror by default -- not sure. Examples: >> > GADTSyntax, Arrows, InstanceSigs, StandaloneDeriving, and many more. >> > >> > B. Extensions that allow violation of some general principle that >> > holds elsewhere. These should be replaced by modifiers or pragmas and >> > be enabled locally. Examples: OverlappingInstances (this is already >> > done!), NoMonomorphismRestriction, DeepSubsumption(*), >> > UndecidableSuperClasses, NoMonoLocalBinds, etc. >> > >> > (*): Given the hue and cry about this one, perhaps there should be a >> > flag to control the behavior. >> > >> > C. Extensions that change the compilation pipeline. These need to >> > remain as configuration flags. Examples: CPP, TemplateHaskell. >> > >> > D. Extensions that create variants of the language by changing >> > semantics of existing constructs. I'm not quite sure what to do with >> > these, but they probably need to remain configuration flags. Even >> > better if they could be enabled locally within a file, though. We >> > should probably try to avoid doing this in the future, though the >> > pain may be worth it. Examples: RebindableSyntax, Strict, >> > OverloadedXXX, etc. >> > >> > Maybe some extensions fail to be categorized here, but this covers >> > the vast, vast majority. >> >> -- >> Joachim Breitner >> mail at joachim-breitner.de >> http://www.joachim-breitner.de/ >> >> _______________________________________________ >> 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 lists at richarde.dev Thu Dec 15 00:35:24 2022 From: lists at richarde.dev (Richard Eisenberg) Date: Thu, 15 Dec 2022 00:35:24 +0000 Subject: [ghc-steering-committee] Modifiers (Was: #512: NoFieldSelectors as datatype annotation) In-Reply-To: <13a361fc9689b0da5352085f4eab397d800af022.camel@joachim-breitner.de> References: <494656e83f8d1486621fab153ed8f85f13b82e1b.camel@joachim-breitner.de> <414422bd-7085-f244-626a-19711dfd0692@well-typed.com> <02620ae95fb4d0a07172c06ffa83281d293e4149.camel@joachim-breitner.de> <451cf30d-8fc6-a052-0c3d-707b5f7fbc92@well-typed.com> <9484dee9-2d77-98ae-5b4d-ebc51f19cb24@well-typed.com> <13a361fc9689b0da5352085f4eab397d800af022.camel@joachim-breitner.de> Message-ID: <010f01851335159c-3a5c2057-9560-4a8c-bb45-1bec9a193786-000000@us-east-2.amazonses.com> It's true that making modifiers type-based may be wrong. I wanted to have some way to e.g. import names, etc., for use in modifiers. But maybe that makes them less useful. Despite this potential flaw, I really think that keeping modifiers around in some form is the right idea. Indeed, perhaps modifiers allow us to have a way forward toward new ideas in the language: new ideas are born as modifiers, and the popular ones get reified with better syntax once we discover usage patterns. One strong argument in favor of modifiers is their success in other languages. I know Java has annotations (which are quite similar -- and type-based) but OCaml also has "attributes", which are quite like modifiers. OCaml attributes are not type-based: they're just strings attached to a parsed payload (such as an expression or a few other syntactic categories). This extra room in the syntax allows for a rich ecosystem of so-called ppxes (the plural of ppx), which Haskellers would call source plugins. Some attributes are interpreted by the OCaml compiler itself, but the rest are just for consumption and manipulation by ppxes -- including OCaml's entire "deriving" mechanism. Yes, the concrete syntax is pretty ugly, but the syntactic space has allowed for a wealth of growth and creativity that would not otherwise be possible. I conjecture modifiers can offer a similar wellspring for GHC. Richard > On Dec 12, 2022, at 11:22 AM, Joachim Breitner wrote: > > Hi, > > it’s not “in the light of experience”, and there is nothing in here > that I couldn’t have brought up when it was originally discussed, and > when I should have (but didn’t for reasons I don’t quite remember; I > think it was a time of limited bandwidth on my side, and I had the > impression that there was a lot of enthusiasm). So I’d feel bad to > actively suggest to unaccept it now – at least not unless it happens > that my worries are more widely shared. > > Cheers, > Joachim > > > > Am Montag, dem 12.12.2022 um 16:04 +0000 schrieb Simon Peyton Jones: >> Joachim >> >> Are you arguing to un-accept the modifiers proposal? I think that's >> a legitimate thing to do but, well, it needs a proposal. (A kind of >> drastic modification to an existing proposal, namely withdrawing it.) >> >> We should feel free to change our view in the light of experience -- >> and it is much easier to do so before the feature is implemented and >> in use. But I think it is not good to have a proposal that is >> accepted-but-with-doubt-cast-upon-it. >> >> Simon >> >> On Fri, 9 Dec 2022 at 18:47, Joachim Breitner >> wrote: >>> Hi, >>> >>> Am Freitag, dem 09.12.2022 um 12:38 +0000 schrieb Simon Peyton >>> Jones: >>>> >>>> We can always re-open an accepted proposal, especially if it is >>>> not >>>> yet implemented! >>>> >>>> The motivations for modifiers I see are: >>>> * We have modifiers for linear types >>>> * It seem wrong to use pragmas (in {-# #-} comments) for things >>>> that >>>> are semantically meaningful like overlapping instances. >>>> We definitely want modifiers in some form. We currently use them >>>> a >>>> lot for {-# OVERLAPPABLE #-} etc. We could stick with the {-# >>>> prag >>>> #-} syntax. But it's a bit noisy, and it really isn't a >>>> comment. >>>> And (unlike the modifier) the pragma stuff doesn't have internal >>>> structure -- we could not use it for linear annotations. >>>> >>>> But I think we should decide what syntax we want for modifier- >>>> like >>>> things, and get it implemented, else it'll keep blocking other >>>> proposals, like this one from Matthew. >>> >>> I was more quiet during the modifier discussion than I should have, >>> but >>> if we are opening this box again, I can share why I don’t feel to >>> confident about it: >>> >>> * Tying modifiers to types rules out their use for every feature >>> that >>> is relevant before type-checking (parsing, renaming…) >>> For example, imagine we only had unqualified imports, and now >>> want >>> to add qualified imports. This feels like a “modification” to >>> me, >>> and a good “modifier syntax” scheme should be able to >>> accommodate >>> it. But it affects renaming, and thus wouldn’t work with a type- >>> based thing. >>> >>> * The syntax might be too clumsy. Consider, again, adding >>> qualified >>> imports to the syntax: We’d have to specify an optional >>> parameter >>> (for the `qualified as Foo` part). How would that look like in >>> Type >>> syntax? Would the qualifier be >>> data Quantified = Quantified (Maybe String) >>> and you need to write Nothing or Just? And quote the name? >>> >>> Even linear types, listed as one of the motivations, really >>> wants to >>> have a nice syntax for the linear arrow, doesn’t it? >>> >>> I expect that many future modifiers on syntax benefit from >>> custom >>> syntax to be ergonomic and preserve the aesthetics of Haskell >>> code. >>> >>> TL;DR: I doubt that a one-scheme-fits all, type-based modifier >>> syntax >>> covers enough use-cases to pay its weight, and am leaning towards >>> “just” coming up with custom syntax for new features (likely with >>> new >>> context-dependent keywords where possible – as in deriving via). >>> >>> >>> Cheers, >>> Joachim >>> >>> >>> >>> _______________________________________________ >>> ghc-steering-committee mailing list >>> ghc-steering-committee at haskell.org >>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee > > -- > Joachim Breitner > mail at joachim-breitner.de > http://www.joachim-breitner.de/ > > _______________________________________________ > 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 lists at richarde.dev Thu Dec 15 00:47:59 2022 From: lists at richarde.dev (Richard Eisenberg) Date: Thu, 15 Dec 2022 00:47:59 +0000 Subject: [ghc-steering-committee] Proposal #270: Support pun-free code. Recommendation: accept In-Reply-To: <428DC3AB-9C06-4950-9151-7B22F5079A1A@chrisdornan.com> References: <5D0E3610-C73F-4850-9435-8D22069382BD@chrisdornan.com> <2da00f7f92f292bb16a4dfc53ec62d68ecf6edc9.camel@joachim-breitner.de> <3267a53a47cec3597c54bab8f8518b2c1613e1a8.camel@joachim-breitner.de> <0e9b3372-5034-f596-acd2-aecc3c7be701@well-typed.com> <089f0c63-ed84-186f-6f70-0372b95e4c3e@well-typed.com> <14cede64-5f45-b6d1-e17a-cd1bb9cd106a@well-typed.com> <9B22308E-170D-4B86-BFF8-1E63D3DF5387@chrisdornan.com> <84D37F3F-FC1D-4B57-BE99-B355419E8EA4@chrisdornan.com> <428DC3AB-9C06-4950-9151-7B22F5079A1A@chrisdornan.com> Message-ID: <010f018513409c8d-ac89ef3e-401c-4612-81b1-aee295530f2a-000000@us-east-2.amazonses.com> I strongly oppose requesting that the proposal be split. I agree that the two parts of the proposal can notionally be separated. But sometimes I feel that, in the face of difficult decisions, this committee has punted by requesting formatting changes of proposals. My case in point is around #448 about scoped type variables. That proposal arose out of a smattering of other proposals... but the committee deemed that the other proposals were too separate and needed to be considered as a whole. So, with some effort, I put them all in one. Then members of the committee said that the proposal was too big and to break it up! I refused, and had to hold my ground despite several requests. In the end, half was accepted, and at that point I took the other half and re-proposed it. I actually don't mind that last part -- I think partial acceptance is a reasonable action. But the formatting and reformatting is quite a bit of work, and I'm not convinced it really helped our debate. I'm worried we're repeating this here. Richard > On Dec 13, 2022, at 10:50 AM, Chris Dornan wrote: > > Although the two aspects of the proposal were motivated by the same problem they are doing completely different things. As long as it was easier to deal with them together the path of least resistance was to keep them bundled up, but it is becoming ever clearer that they are tied up in divergent organisational as well as technical concerns. The warnings are well understood and ready to go with a patch whereas, as this thread illustrates, nobody seems to properly understand what is going on with ExplicitNameSpaces; we are still confident that we can sort it all out and confident that we want to sort it all out but still there is work to be done. > > Added to this there is the fact that the problems with namespaces are entirely inherited from an existing extension that is poorly documented and, as we have just discovered, poorly understood. For all the reasons explained in the proposal we are likely to be leaning more heavily on ExplicitNameSpaces as we develop DH so we really need sort out what it does and get it written down. Here is the kicker — when we do sort out ExplicitNameSpaces and write it up properly we are going to want it attached to language extension dedicated to managing ExplicitNameSpaces, not an extension bundled up with some enabled warnings. > > I am happy to work with Artyom to get the new proposal set up etc. > > Chris > > >> On 13 Dec 2022, at 09:01, Simon Peyton Jones > wrote: >> >> I still don't get the "split in two" thing. The proposal is quite clear about the delta to ExplicitNameSpaces. The fact that the latter is not well specified isn't the current author's fault; and the delta makes sense as part of this proposal. >> >> I think we should accept this one, and politely ask the author if they would consider (as a favour) writing a delta to the ExplicitNameSpaces proposal (I assume there is one?) to clarify it. >> >> Simon >> >> On Mon, 12 Dec 2022 at 22:05, Chris Dornan > wrote: >> In this case, for sure, responsibility for fixing up namespace documentation should not fall on the author of this proposal. I am thinking more that they should be strongly encouraged to submit the follow-up proposal and we provide or identify whatever assistance necessary to get the job done. It will definitely get us to a better place in my view. >> >> It sounds like we are in strong agreement. >> >> Chris >> >> >> >> > On 12 Dec 2022, at 20:11, Adam Gundry > wrote: >> > >> > On 12/12/2022 16:50, Chris Dornan wrote: >> >> I really think we should split this proposal into two, one to deal with warnings and the other to deal with namespaces. The warnings look to me ready to go. >> >> I am further thinking that we should really welcome the followup namespace proposal as an opportunity to clarify and properly document namespaces. >> >> I am sorry, I was added to the proposal very late thinking it was technically sound but I am realising it is far from the case. >> >> Finally, I am quite surprised at how little documentation there seems to be on ExplicitNamespaces. Should we be asking that revised documentation be propared as part of the proposal process and that the documentation be up to scratch? It seems the least we should be asking and much more important than requiring an implementation plan. This process is increasingly the only game in town when it comes to driving forward and defining Haskell and we need to make sure stuff is being written down properly. >> > >> > This is a bit of a tricky issue, I think. I agree that we should strive for a proper specification of ExplicitNamespaces. The current state seems to be sadly lacking, especially if we want ExplicitNamespaces to be in GHC2023. That said, there's a risk that proposal authors will be discouraged if proposing changes entails writing specifications for existing under-specified features! >> > >> > I wonder if anyone has attempted to extend "A Formal Specification of the Haskell 98 Module System" to more recent GHC extensions? >> > >> > Adam >> > >> > >> >>> On 12 Dec 2022, at 12:21, Adam Gundry >> wrote: >> >>> >> >>> On 12/12/2022 11:39, Simon Peyton Jones wrote: >> >>>> {-# LANGUAGE ExplicitNamespaces #-} >> >>>> module N where >> >>>> import M (T(type MkT)) -- NB "type" import of a data constructor >> >>>> v = MkT -- usage at term level Crumbs. I had not realised the proposal is to allow *nested* uses of 'type' in import lists, as you show above. >> >>> >> >>> The nested use is already possible with ExplicitNamespaces. Currently it allows >> >>> >> >>> import M (T(type MkT)) >> >>> import M (type MkT) >> >>> import M (pattern MkT) >> >>> >> >>> whereas the proposal extends it to add the possibility to write >> >>> >> >>> import M type (MkT) >> >>> import M data (MkT) >> >>> import M (data MkT) >> >>> >> >>> >> >>>> In general, I don't feel the extensions to ExplicitNamespaces included >> >>>> in the proposal are very clearly specified. Actually isn't the proposal pretty clear on this, namely the first bullet of proposed change spec >>. It only covers >> >>>> import M *type * >> >>>> import M *data *as MD >> >>>> where I have emboldened the new bits. Nothing about the contents of import lists. Why did you think your example is covered by the proposal? >> >>> >> >>> I'm trying to understand what >> >>> >> >>> import M type (MkT) >> >>> >> >>> means where MkT is a data constructor (or if it raises some kind of error). This was by analogy to the existing >> >>> >> >>> import M (T(type MkT)) >> >>> >> >>> which means something today, albeit not necessarily a very sensible thing (per https://gitlab.haskell.org/ghc/ghc/-/issues/22581 >). >> >>> >> >>> I don't see a clear specification of the proposed (extended) semantics of ExplicitNamespaces in the proposal, but perhaps I've missed something? >> >>> >> >>> Cheers, >> >>> >> >>> Adam >> >>> >> >>> >> >>>> On Mon, 12 Dec 2022 at 09:15, Adam Gundry > >>> wrote: >> >>>> Actually, reading https://gitlab.haskell.org/ghc/ghc/-/issues/22581 > >> >>>> >> I >> >>>> realised I'm unclear how the proposed extensions to ExplicitNamespaces >> >>>> are supposed to work. The existing situation is apparently that for a >> >>>> (non-punned) data constructor, it is possible to use either a >> >>>> pattern or >> >>>> type qualifier in an import list (presumably because DataKinds means >> >>>> the >> >>>> constructor is in scope at both the term and type levels), and the >> >>>> imported constructor is then usable in both contexts. >> >>>> For example, the following is accepted at present: >> >>>> module M where >> >>>> data T = MkT >> >>>> {-# LANGUAGE ExplicitNamespaces #-} >> >>>> module N where >> >>>> import M (T(type MkT)) -- NB "type" import of a data constructor >> >>>> v = MkT -- usage at term level >> >>>> The present proposal says "With type specified in the import, only >> >>>> identifiers belonging to the type namespace will be brought into the >> >>>> scope." I'm not exactly sure how to interpret this, does it mean the >> >>>> following alternative will be accepted or rejected? >> >>>> module N where >> >>>> import M type (MkT) >> >>>> v = MkT >> >>>> I'm worried we will end up with a situation where ExplicitNamespaces >> >>>> does subtly different things depending on the position of the keyword. >> >>>> In general, I don't feel the extensions to ExplicitNamespaces included >> >>>> in the proposal are very clearly specified. Given the discussion about >> >>>> exactly which parts belong to ExplicitNamespaces/PatternSynonyms versus >> >>>> separate extensions, perhaps we should accept the parts relating to >> >>>> -Wpuns/-Wpun-bindings, but ask for the ExplicitNamespaces changes to be >> >>>> proposed separately? >> >>>> Cheers, >> >>>> Adam >> >>>> On 09/12/2022 11:11, Adam Gundry wrote: >> >>>> > I'm broadly in favour of accepting the proposal. I realise the >> >>>> history >> >>>> > is complex here, so I don't think we should ask anyone to rewrite >> >>>> things >> >>>> > further, though in general it would be nicer to have separate >> >>>> proposals >> >>>> > for -Wpuns/-Wpun-bindings (which is unambiguously fine) and for the >> >>>> > changes to imports (which as Joachim points out raise issues). >> >>>> > >> >>>> > I'm a bit concerned that the proposal does not motivate or specify >> >>>> > -Wpattern-namespace-qualified very well. >> >>>> > >> >>>> > >> >>>> > On 08/12/2022 08:33, Joachim Breitner wrote: >> >>>> >> ... >> >>>> >> >> >>>> >> This gives us (at least) these options: >> >>>> >> >> >>>> >> 1. Leave ExplicitNamespaces alone, add ExplicitNamespaces to >> >>>> GHC2023, >> >>>> >> introduce one or two new extensions for the newer changes. >> >>>> >> 2. Extend ExplicitNamespaces, and don’t add it already to GHC2023, >> >>>> >> disregarding issue #551. >> >>>> >> 3. Add ExplicitNamespaces to GHC2023, and still add it to GHC2023, >> >>>> >> arguing that GHC20xx allows more liberal (backward-compatibile) >> >>>> >> changes than, say, Haskell2010 would allow. >> >>>> >> >> >>>> >> Certainly 1 is the least bold move. I am not sure what the best way >> >>>> >> forwards is, and welcome other opinions. >> >>>> > >> >>>> > I would prefer a variant of 1: allow "data" as a keyword in >> >>>> import lists >> >>>> > under ExplicitNamespaces, but make the other changes under other >> >>>> > extensions. >> >>>> > >> >>>> > As I've said previously, I have a general preference for multiple >> >>>> small, >> >>>> > orthogonal extensions rather than changing existing extensions to >> >>>> add >> >>>> > unrelated features that happen to be in similar territory. I realise >> >>>> > this is controversial, of course. >> >>>> > >> >>>> > Cheers, >> >>>> > >> >>>> > Adam >> > >> > >> > -- >> > Adam Gundry, Haskell Consultant >> > Well-Typed LLP, https://www.well-typed.com/ >> > >> > Registered in England & Wales, OC335890 >> > 27 Old Gloucester Street, London WC1N 3AX, England >> > >> > _______________________________________________ >> > ghc-steering-committee mailing list >> > ghc-steering-committee at haskell.org >> > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee >> >> _______________________________________________ >> ghc-steering-committee mailing list >> ghc-steering-committee at haskell.org >> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee > > _______________________________________________ > ghc-steering-committee mailing list > ghc-steering-committee at haskell.org > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee -------------- next part -------------- An HTML attachment was scrubbed... URL: From chris at chrisdornan.com Thu Dec 15 00:55:11 2022 From: chris at chrisdornan.com (Chris Dornan) Date: Thu, 15 Dec 2022 00:55:11 +0000 Subject: [ghc-steering-committee] Proposal #270: Support pun-free code. Recommendation: accept In-Reply-To: <010f018513409c8d-ac89ef3e-401c-4612-81b1-aee295530f2a-000000@us-east-2.amazonses.com> References: <5D0E3610-C73F-4850-9435-8D22069382BD@chrisdornan.com> <2da00f7f92f292bb16a4dfc53ec62d68ecf6edc9.camel@joachim-breitner.de> <3267a53a47cec3597c54bab8f8518b2c1613e1a8.camel@joachim-breitner.de> <0e9b3372-5034-f596-acd2-aecc3c7be701@well-typed.com> <089f0c63-ed84-186f-6f70-0372b95e4c3e@well-typed.com> <14cede64-5f45-b6d1-e17a-cd1bb9cd106a@well-typed.com> <9B22308E-170D-4B86-BFF8-1E63D3DF5387@chrisdornan.com> <84D37F3F-FC1D-4B57-BE99-B355419E8EA4@chrisdornan.com> <428DC3AB-9C06-4950-9151-7B22F5079A1A@chrisdornan.com> <010f018513409c8d-ac89ef3e-401c-4612-81b1-aee295530f2a-000000@us-east-2.amazonses.com> Message-ID: For reasons I have made entirely clear I _strongly_ desire this split — are you offering to take over shepherding this proposal Richard? Because I am now totally stymied and unable to manage the process. > On 15 Dec 2022, at 00:47, Richard Eisenberg wrote: > > I strongly oppose requesting that the proposal be split. I agree that the two parts of the proposal can notionally be separated. But sometimes I feel that, in the face of difficult decisions, this committee has punted by requesting formatting changes of proposals. My case in point is around #448 about scoped type variables. That proposal arose out of a smattering of other proposals... but the committee deemed that the other proposals were too separate and needed to be considered as a whole. So, with some effort, I put them all in one. Then members of the committee said that the proposal was too big and to break it up! I refused, and had to hold my ground despite several requests. In the end, half was accepted, and at that point I took the other half and re-proposed it. I actually don't mind that last part -- I think partial acceptance is a reasonable action. But the formatting and reformatting is quite a bit of work, and I'm not convinced it really helped our debate. I'm worried we're repeating this here. > > Richard > >> On Dec 13, 2022, at 10:50 AM, Chris Dornan > wrote: >> >> Although the two aspects of the proposal were motivated by the same problem they are doing completely different things. As long as it was easier to deal with them together the path of least resistance was to keep them bundled up, but it is becoming ever clearer that they are tied up in divergent organisational as well as technical concerns. The warnings are well understood and ready to go with a patch whereas, as this thread illustrates, nobody seems to properly understand what is going on with ExplicitNameSpaces; we are still confident that we can sort it all out and confident that we want to sort it all out but still there is work to be done. >> >> Added to this there is the fact that the problems with namespaces are entirely inherited from an existing extension that is poorly documented and, as we have just discovered, poorly understood. For all the reasons explained in the proposal we are likely to be leaning more heavily on ExplicitNameSpaces as we develop DH so we really need sort out what it does and get it written down. Here is the kicker — when we do sort out ExplicitNameSpaces and write it up properly we are going to want it attached to language extension dedicated to managing ExplicitNameSpaces, not an extension bundled up with some enabled warnings. >> >> I am happy to work with Artyom to get the new proposal set up etc. >> >> Chris >> >> >>> On 13 Dec 2022, at 09:01, Simon Peyton Jones > wrote: >>> >>> I still don't get the "split in two" thing. The proposal is quite clear about the delta to ExplicitNameSpaces. The fact that the latter is not well specified isn't the current author's fault; and the delta makes sense as part of this proposal. >>> >>> I think we should accept this one, and politely ask the author if they would consider (as a favour) writing a delta to the ExplicitNameSpaces proposal (I assume there is one?) to clarify it. >>> >>> Simon >>> >>> On Mon, 12 Dec 2022 at 22:05, Chris Dornan > wrote: >>> In this case, for sure, responsibility for fixing up namespace documentation should not fall on the author of this proposal. I am thinking more that they should be strongly encouraged to submit the follow-up proposal and we provide or identify whatever assistance necessary to get the job done. It will definitely get us to a better place in my view. >>> >>> It sounds like we are in strong agreement. >>> >>> Chris >>> >>> >>> >>> > On 12 Dec 2022, at 20:11, Adam Gundry > wrote: >>> > >>> > On 12/12/2022 16:50, Chris Dornan wrote: >>> >> I really think we should split this proposal into two, one to deal with warnings and the other to deal with namespaces. The warnings look to me ready to go. >>> >> I am further thinking that we should really welcome the followup namespace proposal as an opportunity to clarify and properly document namespaces. >>> >> I am sorry, I was added to the proposal very late thinking it was technically sound but I am realising it is far from the case. >>> >> Finally, I am quite surprised at how little documentation there seems to be on ExplicitNamespaces. Should we be asking that revised documentation be propared as part of the proposal process and that the documentation be up to scratch? It seems the least we should be asking and much more important than requiring an implementation plan. This process is increasingly the only game in town when it comes to driving forward and defining Haskell and we need to make sure stuff is being written down properly. >>> > >>> > This is a bit of a tricky issue, I think. I agree that we should strive for a proper specification of ExplicitNamespaces. The current state seems to be sadly lacking, especially if we want ExplicitNamespaces to be in GHC2023. That said, there's a risk that proposal authors will be discouraged if proposing changes entails writing specifications for existing under-specified features! >>> > >>> > I wonder if anyone has attempted to extend "A Formal Specification of the Haskell 98 Module System" to more recent GHC extensions? >>> > >>> > Adam >>> > >>> > >>> >>> On 12 Dec 2022, at 12:21, Adam Gundry >> wrote: >>> >>> >>> >>> On 12/12/2022 11:39, Simon Peyton Jones wrote: >>> >>>> {-# LANGUAGE ExplicitNamespaces #-} >>> >>>> module N where >>> >>>> import M (T(type MkT)) -- NB "type" import of a data constructor >>> >>>> v = MkT -- usage at term level Crumbs. I had not realised the proposal is to allow *nested* uses of 'type' in import lists, as you show above. >>> >>> >>> >>> The nested use is already possible with ExplicitNamespaces. Currently it allows >>> >>> >>> >>> import M (T(type MkT)) >>> >>> import M (type MkT) >>> >>> import M (pattern MkT) >>> >>> >>> >>> whereas the proposal extends it to add the possibility to write >>> >>> >>> >>> import M type (MkT) >>> >>> import M data (MkT) >>> >>> import M (data MkT) >>> >>> >>> >>> >>> >>>> In general, I don't feel the extensions to ExplicitNamespaces included >>> >>>> in the proposal are very clearly specified. Actually isn't the proposal pretty clear on this, namely the first bullet of proposed change spec >>. It only covers >>> >>>> import M *type * >>> >>>> import M *data *as MD >>> >>>> where I have emboldened the new bits. Nothing about the contents of import lists. Why did you think your example is covered by the proposal? >>> >>> >>> >>> I'm trying to understand what >>> >>> >>> >>> import M type (MkT) >>> >>> >>> >>> means where MkT is a data constructor (or if it raises some kind of error). This was by analogy to the existing >>> >>> >>> >>> import M (T(type MkT)) >>> >>> >>> >>> which means something today, albeit not necessarily a very sensible thing (per https://gitlab.haskell.org/ghc/ghc/-/issues/22581 >). >>> >>> >>> >>> I don't see a clear specification of the proposed (extended) semantics of ExplicitNamespaces in the proposal, but perhaps I've missed something? >>> >>> >>> >>> Cheers, >>> >>> >>> >>> Adam >>> >>> >>> >>> >>> >>>> On Mon, 12 Dec 2022 at 09:15, Adam Gundry > >>> wrote: >>> >>>> Actually, reading https://gitlab.haskell.org/ghc/ghc/-/issues/22581 > >>> >>>> >> I >>> >>>> realised I'm unclear how the proposed extensions to ExplicitNamespaces >>> >>>> are supposed to work. The existing situation is apparently that for a >>> >>>> (non-punned) data constructor, it is possible to use either a >>> >>>> pattern or >>> >>>> type qualifier in an import list (presumably because DataKinds means >>> >>>> the >>> >>>> constructor is in scope at both the term and type levels), and the >>> >>>> imported constructor is then usable in both contexts. >>> >>>> For example, the following is accepted at present: >>> >>>> module M where >>> >>>> data T = MkT >>> >>>> {-# LANGUAGE ExplicitNamespaces #-} >>> >>>> module N where >>> >>>> import M (T(type MkT)) -- NB "type" import of a data constructor >>> >>>> v = MkT -- usage at term level >>> >>>> The present proposal says "With type specified in the import, only >>> >>>> identifiers belonging to the type namespace will be brought into the >>> >>>> scope." I'm not exactly sure how to interpret this, does it mean the >>> >>>> following alternative will be accepted or rejected? >>> >>>> module N where >>> >>>> import M type (MkT) >>> >>>> v = MkT >>> >>>> I'm worried we will end up with a situation where ExplicitNamespaces >>> >>>> does subtly different things depending on the position of the keyword. >>> >>>> In general, I don't feel the extensions to ExplicitNamespaces included >>> >>>> in the proposal are very clearly specified. Given the discussion about >>> >>>> exactly which parts belong to ExplicitNamespaces/PatternSynonyms versus >>> >>>> separate extensions, perhaps we should accept the parts relating to >>> >>>> -Wpuns/-Wpun-bindings, but ask for the ExplicitNamespaces changes to be >>> >>>> proposed separately? >>> >>>> Cheers, >>> >>>> Adam >>> >>>> On 09/12/2022 11:11, Adam Gundry wrote: >>> >>>> > I'm broadly in favour of accepting the proposal. I realise the >>> >>>> history >>> >>>> > is complex here, so I don't think we should ask anyone to rewrite >>> >>>> things >>> >>>> > further, though in general it would be nicer to have separate >>> >>>> proposals >>> >>>> > for -Wpuns/-Wpun-bindings (which is unambiguously fine) and for the >>> >>>> > changes to imports (which as Joachim points out raise issues). >>> >>>> > >>> >>>> > I'm a bit concerned that the proposal does not motivate or specify >>> >>>> > -Wpattern-namespace-qualified very well. >>> >>>> > >>> >>>> > >>> >>>> > On 08/12/2022 08:33, Joachim Breitner wrote: >>> >>>> >> ... >>> >>>> >> >>> >>>> >> This gives us (at least) these options: >>> >>>> >> >>> >>>> >> 1. Leave ExplicitNamespaces alone, add ExplicitNamespaces to >>> >>>> GHC2023, >>> >>>> >> introduce one or two new extensions for the newer changes. >>> >>>> >> 2. Extend ExplicitNamespaces, and don’t add it already to GHC2023, >>> >>>> >> disregarding issue #551. >>> >>>> >> 3. Add ExplicitNamespaces to GHC2023, and still add it to GHC2023, >>> >>>> >> arguing that GHC20xx allows more liberal (backward-compatibile) >>> >>>> >> changes than, say, Haskell2010 would allow. >>> >>>> >> >>> >>>> >> Certainly 1 is the least bold move. I am not sure what the best way >>> >>>> >> forwards is, and welcome other opinions. >>> >>>> > >>> >>>> > I would prefer a variant of 1: allow "data" as a keyword in >>> >>>> import lists >>> >>>> > under ExplicitNamespaces, but make the other changes under other >>> >>>> > extensions. >>> >>>> > >>> >>>> > As I've said previously, I have a general preference for multiple >>> >>>> small, >>> >>>> > orthogonal extensions rather than changing existing extensions to >>> >>>> add >>> >>>> > unrelated features that happen to be in similar territory. I realise >>> >>>> > this is controversial, of course. >>> >>>> > >>> >>>> > Cheers, >>> >>>> > >>> >>>> > Adam >>> > >>> > >>> > -- >>> > Adam Gundry, Haskell Consultant >>> > Well-Typed LLP, https://www.well-typed.com/ >>> > >>> > Registered in England & Wales, OC335890 >>> > 27 Old Gloucester Street, London WC1N 3AX, England >>> > >>> > _______________________________________________ >>> > ghc-steering-committee mailing list >>> > ghc-steering-committee at haskell.org >>> > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee >>> >>> _______________________________________________ >>> ghc-steering-committee mailing list >>> ghc-steering-committee at haskell.org >>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee >> >> _______________________________________________ >> ghc-steering-committee mailing list >> ghc-steering-committee at haskell.org >> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee > -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.peytonjones at gmail.com Thu Dec 15 08:14:50 2022 From: simon.peytonjones at gmail.com (Simon Peyton Jones) Date: Thu, 15 Dec 2022 08:14:50 +0000 Subject: [ghc-steering-committee] Proposal #270: Support pun-free code. Recommendation: accept In-Reply-To: References: <5D0E3610-C73F-4850-9435-8D22069382BD@chrisdornan.com> <2da00f7f92f292bb16a4dfc53ec62d68ecf6edc9.camel@joachim-breitner.de> <3267a53a47cec3597c54bab8f8518b2c1613e1a8.camel@joachim-breitner.de> <0e9b3372-5034-f596-acd2-aecc3c7be701@well-typed.com> <089f0c63-ed84-186f-6f70-0372b95e4c3e@well-typed.com> <14cede64-5f45-b6d1-e17a-cd1bb9cd106a@well-typed.com> <9B22308E-170D-4B86-BFF8-1E63D3DF5387@chrisdornan.com> <84D37F3F-FC1D-4B57-BE99-B355419E8EA4@chrisdornan.com> <428DC3AB-9C06-4950-9151-7B22F5079A1A@chrisdornan.com> <010f018513409c8d-ac89ef3e-401c-4612-81b1-aee295530f2a-000000@us-east-2.amazonses.com> Message-ID: I recommend acceptance as-is. I see no difficulty with the namespace part of the proposal. Yes, the *existing *namespace extension is ill specified. But this proposal does not make that situation worse (the delta is clearly specified), and it seems unfair of us to penalise this proposal because of the pre-existing situation. Of course, it would be better still to have a new, subsequent proposal that clarifies the ExplicitNameSpaceProposal. Perhaps we could invite Artyom write it, as a favour to the community. Or perhaps a member of the committee might like to. Simon On Thu, 15 Dec 2022 at 00:55, Chris Dornan wrote: > For reasons I have made entirely clear I _strongly_ desire this split — > are you offering to take over shepherding this proposal Richard? Because I > am now totally stymied and unable to manage the process. > > On 15 Dec 2022, at 00:47, Richard Eisenberg wrote: > > I strongly oppose requesting that the proposal be split. I agree that the > two parts of the proposal can notionally be separated. But sometimes I feel > that, in the face of difficult decisions, this committee has punted by > requesting formatting changes of proposals. My case in point is around #448 > about scoped type variables. That proposal arose out of a smattering of > other proposals... but the committee deemed that the other proposals were > too separate and needed to be considered as a whole. So, with some effort, > I put them all in one. Then members of the committee said that the proposal > was too big and to break it up! I refused, and had to hold my ground > despite several requests. In the end, half was accepted, and at that point > I took the other half and re-proposed it. I actually don't mind that last > part -- I think partial acceptance is a reasonable action. But the > formatting and reformatting is quite a bit of work, and I'm not convinced > it really helped our debate. I'm worried we're repeating this here. > > Richard > > On Dec 13, 2022, at 10:50 AM, Chris Dornan wrote: > > Although the two aspects of the proposal were motivated by the same > problem they are doing completely different things. As long as it was > easier to deal with them together the path of least resistance was to keep > them bundled up, but it is becoming ever clearer that they are tied up in > divergent organisational as well as technical concerns. The warnings are > well understood and ready to go with a patch whereas, as this thread > illustrates, nobody seems to properly understand what is going on with > ExplicitNameSpaces; we are still confident that we can sort it all out and > confident that we want to sort it all out but still there is work to be > done. > > Added to this there is the fact that the problems with namespaces are > entirely inherited from an existing extension that is poorly documented > and, as we have just discovered, poorly understood. For all the reasons > explained in the proposal we are likely to be leaning more heavily on > ExplicitNameSpaces as we develop DH so we really need sort out what it > does and get it written down. Here is the kicker — when we do sort out > ExplicitNameSpaces and write it up properly we are going to want it > attached to language extension dedicated to managing ExplicitNameSpaces, > not an extension bundled up with some enabled warnings. > > I am happy to work with Artyom to get the new proposal set up etc. > > Chris > > > On 13 Dec 2022, at 09:01, Simon Peyton Jones > wrote: > > I still don't get the "split in two" thing. The proposal is quite clear > about the delta to ExplicitNameSpaces. The fact that the latter is not > well specified isn't the current author's fault; and the delta makes sense > as part of this proposal. > > I think we should accept this one, and politely ask the author if they > would consider (as a favour) writing a delta to the ExplicitNameSpaces > proposal (I assume there is one?) to clarify it. > > Simon > > On Mon, 12 Dec 2022 at 22:05, Chris Dornan wrote: > >> In this case, for sure, responsibility for fixing up namespace >> documentation should not fall on the author of this proposal. I am thinking >> more that they should be strongly encouraged to submit the follow-up >> proposal and we provide or identify whatever assistance necessary to get >> the job done. It will definitely get us to a better place in my view. >> >> It sounds like we are in strong agreement. >> >> Chris >> >> >> >> > On 12 Dec 2022, at 20:11, Adam Gundry wrote: >> > >> > On 12/12/2022 16:50, Chris Dornan wrote: >> >> I really think we should split this proposal into two, one to deal >> with warnings and the other to deal with namespaces. The warnings look to >> me ready to go. >> >> I am further thinking that we should really welcome the followup >> namespace proposal as an opportunity to clarify and properly document >> namespaces. >> >> I am sorry, I was added to the proposal very late thinking it was >> technically sound but I am realising it is far from the case. >> >> Finally, I am quite surprised at how little documentation there seems >> to be on ExplicitNamespaces. Should we be asking that revised documentation >> be propared as part of the proposal process and that the documentation be >> up to scratch? It seems the least we should be asking and much more >> important than requiring an implementation plan. This process is >> increasingly the only game in town when it comes to driving forward and >> defining Haskell and we need to make sure stuff is being written down >> properly. >> > >> > This is a bit of a tricky issue, I think. I agree that we should strive >> for a proper specification of ExplicitNamespaces. The current state seems >> to be sadly lacking, especially if we want ExplicitNamespaces to be in >> GHC2023. That said, there's a risk that proposal authors will be >> discouraged if proposing changes entails writing specifications for >> existing under-specified features! >> > >> > I wonder if anyone has attempted to extend "A Formal Specification of >> the Haskell 98 Module System" to more recent GHC extensions? >> > >> > Adam >> > >> > >> >>> On 12 Dec 2022, at 12:21, Adam Gundry > adam at well-typed.com>> wrote: >> >>> >> >>> On 12/12/2022 11:39, Simon Peyton Jones wrote: >> >>>> {-# LANGUAGE ExplicitNamespaces #-} >> >>>> module N where >> >>>> import M (T(type MkT)) -- NB "type" import of a data >> constructor >> >>>> v = MkT -- usage at term level Crumbs. I >> had not realised the proposal is to allow *nested* uses of 'type' in import >> lists, as you show above. >> >>> >> >>> The nested use is already possible with ExplicitNamespaces. Currently >> it allows >> >>> >> >>> import M (T(type MkT)) >> >>> import M (type MkT) >> >>> import M (pattern MkT) >> >>> >> >>> whereas the proposal extends it to add the possibility to write >> >>> >> >>> import M type (MkT) >> >>> import M data (MkT) >> >>> import M (data MkT) >> >>> >> >>> >> >>>> In general, I don't feel the extensions to ExplicitNamespaces >> included >> >>>> in the proposal are very clearly specified. Actually isn't the >> proposal pretty clear on this, namely the first bullet of proposed change >> spec < >> https://github.com/hithroc/ghc-proposals/blob/master/proposals/0000-support-pun-free-code.md#2-proposed-change-specification >> < >> https://github.com/hithroc/ghc-proposals/blob/master/proposals/0000-support-pun-free-code.md#2-proposed-change-specification>>. >> It only covers >> >>>> import M *type * >> >>>> import M *data *as MD >> >>>> where I have emboldened the new bits. Nothing about the contents of >> import lists. Why did you think your example is covered by the proposal? >> >>> >> >>> I'm trying to understand what >> >>> >> >>> import M type (MkT) >> >>> >> >>> means where MkT is a data constructor (or if it raises some kind of >> error). This was by analogy to the existing >> >>> >> >>> import M (T(type MkT)) >> >>> >> >>> which means something today, albeit not necessarily a very sensible >> thing (per https://gitlab.haskell.org/ghc/ghc/-/issues/22581 < >> https://gitlab.haskell.org/ghc/ghc/-/issues/22581>). >> >>> >> >>> I don't see a clear specification of the proposed (extended) >> semantics of ExplicitNamespaces in the proposal, but perhaps I've missed >> something? >> >>> >> >>> Cheers, >> >>> >> >>> Adam >> >>> >> >>> >> >>>> On Mon, 12 Dec 2022 at 09:15, Adam Gundry > > adam at well-typed.com>>> wrote: >> >>>> Actually, reading >> https://gitlab.haskell.org/ghc/ghc/-/issues/22581 < >> https://gitlab.haskell.org/ghc/ghc/-/issues/22581> >> >>>> > https://gitlab.haskell.org/ghc/ghc/-/issues/22581>> I >> >>>> realised I'm unclear how the proposed extensions to >> ExplicitNamespaces >> >>>> are supposed to work. The existing situation is apparently that >> for a >> >>>> (non-punned) data constructor, it is possible to use either a >> >>>> pattern or >> >>>> type qualifier in an import list (presumably because DataKinds >> means >> >>>> the >> >>>> constructor is in scope at both the term and type levels), and the >> >>>> imported constructor is then usable in both contexts. >> >>>> For example, the following is accepted at present: >> >>>> module M where >> >>>> data T = MkT >> >>>> {-# LANGUAGE ExplicitNamespaces #-} >> >>>> module N where >> >>>> import M (T(type MkT)) -- NB "type" import of a data >> constructor >> >>>> v = MkT -- usage at term level >> >>>> The present proposal says "With type specified in the import, only >> >>>> identifiers belonging to the type namespace will be brought into >> the >> >>>> scope." I'm not exactly sure how to interpret this, does it mean >> the >> >>>> following alternative will be accepted or rejected? >> >>>> module N where >> >>>> import M type (MkT) >> >>>> v = MkT >> >>>> I'm worried we will end up with a situation where >> ExplicitNamespaces >> >>>> does subtly different things depending on the position of the >> keyword. >> >>>> In general, I don't feel the extensions to ExplicitNamespaces >> included >> >>>> in the proposal are very clearly specified. Given the discussion >> about >> >>>> exactly which parts belong to ExplicitNamespaces/PatternSynonyms >> versus >> >>>> separate extensions, perhaps we should accept the parts relating >> to >> >>>> -Wpuns/-Wpun-bindings, but ask for the ExplicitNamespaces changes >> to be >> >>>> proposed separately? >> >>>> Cheers, >> >>>> Adam >> >>>> On 09/12/2022 11:11, Adam Gundry wrote: >> >>>> > I'm broadly in favour of accepting the proposal. I realise the >> >>>> history >> >>>> > is complex here, so I don't think we should ask anyone to >> rewrite >> >>>> things >> >>>> > further, though in general it would be nicer to have separate >> >>>> proposals >> >>>> > for -Wpuns/-Wpun-bindings (which is unambiguously fine) and >> for the >> >>>> > changes to imports (which as Joachim points out raise issues). >> >>>> > >> >>>> > I'm a bit concerned that the proposal does not motivate or >> specify >> >>>> > -Wpattern-namespace-qualified very well. >> >>>> > >> >>>> > >> >>>> > On 08/12/2022 08:33, Joachim Breitner wrote: >> >>>> >> ... >> >>>> >> >> >>>> >> This gives us (at least) these options: >> >>>> >> >> >>>> >> 1. Leave ExplicitNamespaces alone, add ExplicitNamespaces to >> >>>> GHC2023, >> >>>> >> introduce one or two new extensions for the newer changes. >> >>>> >> 2. Extend ExplicitNamespaces, and don’t add it already to >> GHC2023, >> >>>> >> disregarding issue #551. >> >>>> >> 3. Add ExplicitNamespaces to GHC2023, and still add it to >> GHC2023, >> >>>> >> arguing that GHC20xx allows more liberal >> (backward-compatibile) >> >>>> >> changes than, say, Haskell2010 would allow. >> >>>> >> >> >>>> >> Certainly 1 is the least bold move. I am not sure what the >> best way >> >>>> >> forwards is, and welcome other opinions. >> >>>> > >> >>>> > I would prefer a variant of 1: allow "data" as a keyword in >> >>>> import lists >> >>>> > under ExplicitNamespaces, but make the other changes under >> other >> >>>> > extensions. >> >>>> > >> >>>> > As I've said previously, I have a general preference for >> multiple >> >>>> small, >> >>>> > orthogonal extensions rather than changing existing extensions >> to >> >>>> add >> >>>> > unrelated features that happen to be in similar territory. I >> realise >> >>>> > this is controversial, of course. >> >>>> > >> >>>> > Cheers, >> >>>> > >> >>>> > Adam >> > >> > >> > -- >> > Adam Gundry, Haskell Consultant >> > Well-Typed LLP, https://www.well-typed.com/ >> > >> > Registered in England & Wales, OC335890 >> > 27 Old Gloucester Street, London WC1N 3AX, England >> > >> > _______________________________________________ >> > ghc-steering-committee mailing list >> > ghc-steering-committee at haskell.org >> > >> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee >> >> _______________________________________________ >> ghc-steering-committee mailing list >> ghc-steering-committee at haskell.org >> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee >> > > _______________________________________________ > ghc-steering-committee mailing list > ghc-steering-committee at haskell.org > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From chris at chrisdornan.com Thu Dec 15 09:03:52 2022 From: chris at chrisdornan.com (Chris Dornan) Date: Thu, 15 Dec 2022 09:03:52 +0000 Subject: [ghc-steering-committee] Proposal #270: Support pun-free code. Recommendation: accept In-Reply-To: References: <5D0E3610-C73F-4850-9435-8D22069382BD@chrisdornan.com> <2da00f7f92f292bb16a4dfc53ec62d68ecf6edc9.camel@joachim-breitner.de> <3267a53a47cec3597c54bab8f8518b2c1613e1a8.camel@joachim-breitner.de> <0e9b3372-5034-f596-acd2-aecc3c7be701@well-typed.com> <089f0c63-ed84-186f-6f70-0372b95e4c3e@well-typed.com> <14cede64-5f45-b6d1-e17a-cd1bb9cd106a@well-typed.com> <9B22308E-170D-4B86-BFF8-1E63D3DF5387@chrisdornan.com> <84D37F3F-FC1D-4B57-BE99-B355419E8EA4@chrisdornan.com> <428DC3AB-9C06-4950-9151-7B22F5079A1A@chrisdornan.com> <010f018513409c8d-ac89ef3e-401c-4612-81b1-aee295530f2a-000000@us-east-2.amazonses.com> Message-ID: <15DCEFF4-853E-4A8C-BFC6-0C30584E90EE@chrisdornan.com> I am so tempted to take this up — it just gets us right out of the doom loop that seems to be dogging this proposal, which I have come to think is incredibly valuable, as much for the analysis and insight the proposal has generated as for tools it proposes. My only reservation is that I think it somewhat suboptimal to couple such diverse mechanisms as the warnings and import name spaces. However, if we do the follow up then we can recast the extension as primarily about warning and implying thew new cleaned-up namespace extension. So the pragmatist in me says yes, let’s do it, provided the rest of the committee is OK with that. If so I will organise the follow up — I will invite Artyom and, of course, I would love any input I can get from Adam and Richard and anyone else on the committee or elsewhere. (Getting Adam onto the committee was a major coup in my opinion — but I knew that already from elsewhere.) In general I think it would be good if we could establish a precedent where the appointed shepherd is trusted to manage the process. Here we can see how multiple inputs into the managerial process are leading to compromises that could be compromising the technical outcome, just to escape ourselves (we hope it all work out in the end, of course). When it comes to technical matters, of course, everyone must have a veto but for organisational matters I think things will go much better if each person appointed to manage the process is left to it, unless a serious problem is seen, in which case a “have you considered this” would probably be in order. Chris > On 15 Dec 2022, at 08:14, Simon Peyton Jones wrote: > > I recommend acceptance as-is. > > I see no difficulty with the namespace part of the proposal. Yes, the existing namespace extension is ill specified. But this proposal does not make that situation worse (the delta is clearly specified), and it seems unfair of us to penalise this proposal because of the pre-existing situation. > > Of course, it would be better still to have a new, subsequent proposal that clarifies the ExplicitNameSpaceProposal. Perhaps we could invite Artyom write it, as a favour to the community. Or perhaps a member of the committee might like to. > > Simon > > On Thu, 15 Dec 2022 at 00:55, Chris Dornan > wrote: > For reasons I have made entirely clear I _strongly_ desire this split — are you offering to take over shepherding this proposal Richard? Because I am now totally stymied and unable to manage the process. > >> On 15 Dec 2022, at 00:47, Richard Eisenberg > wrote: >> >> I strongly oppose requesting that the proposal be split. I agree that the two parts of the proposal can notionally be separated. But sometimes I feel that, in the face of difficult decisions, this committee has punted by requesting formatting changes of proposals. My case in point is around #448 about scoped type variables. That proposal arose out of a smattering of other proposals... but the committee deemed that the other proposals were too separate and needed to be considered as a whole. So, with some effort, I put them all in one. Then members of the committee said that the proposal was too big and to break it up! I refused, and had to hold my ground despite several requests. In the end, half was accepted, and at that point I took the other half and re-proposed it. I actually don't mind that last part -- I think partial acceptance is a reasonable action. But the formatting and reformatting is quite a bit of work, and I'm not convinced it really helped our debate. I'm worried we're repeating this here. >> >> Richard >> >>> On Dec 13, 2022, at 10:50 AM, Chris Dornan > wrote: >>> >>> Although the two aspects of the proposal were motivated by the same problem they are doing completely different things. As long as it was easier to deal with them together the path of least resistance was to keep them bundled up, but it is becoming ever clearer that they are tied up in divergent organisational as well as technical concerns. The warnings are well understood and ready to go with a patch whereas, as this thread illustrates, nobody seems to properly understand what is going on with ExplicitNameSpaces; we are still confident that we can sort it all out and confident that we want to sort it all out but still there is work to be done. >>> >>> Added to this there is the fact that the problems with namespaces are entirely inherited from an existing extension that is poorly documented and, as we have just discovered, poorly understood. For all the reasons explained in the proposal we are likely to be leaning more heavily on ExplicitNameSpaces as we develop DH so we really need sort out what it does and get it written down. Here is the kicker — when we do sort out ExplicitNameSpaces and write it up properly we are going to want it attached to language extension dedicated to managing ExplicitNameSpaces, not an extension bundled up with some enabled warnings. >>> >>> I am happy to work with Artyom to get the new proposal set up etc. >>> >>> Chris >>> >>> >>>> On 13 Dec 2022, at 09:01, Simon Peyton Jones > wrote: >>>> >>>> I still don't get the "split in two" thing. The proposal is quite clear about the delta to ExplicitNameSpaces. The fact that the latter is not well specified isn't the current author's fault; and the delta makes sense as part of this proposal. >>>> >>>> I think we should accept this one, and politely ask the author if they would consider (as a favour) writing a delta to the ExplicitNameSpaces proposal (I assume there is one?) to clarify it. >>>> >>>> Simon >>>> >>>> On Mon, 12 Dec 2022 at 22:05, Chris Dornan > wrote: >>>> In this case, for sure, responsibility for fixing up namespace documentation should not fall on the author of this proposal. I am thinking more that they should be strongly encouraged to submit the follow-up proposal and we provide or identify whatever assistance necessary to get the job done. It will definitely get us to a better place in my view. >>>> >>>> It sounds like we are in strong agreement. >>>> >>>> Chris >>>> >>>> >>>> >>>> > On 12 Dec 2022, at 20:11, Adam Gundry > wrote: >>>> > >>>> > On 12/12/2022 16:50, Chris Dornan wrote: >>>> >> I really think we should split this proposal into two, one to deal with warnings and the other to deal with namespaces. The warnings look to me ready to go. >>>> >> I am further thinking that we should really welcome the followup namespace proposal as an opportunity to clarify and properly document namespaces. >>>> >> I am sorry, I was added to the proposal very late thinking it was technically sound but I am realising it is far from the case. >>>> >> Finally, I am quite surprised at how little documentation there seems to be on ExplicitNamespaces. Should we be asking that revised documentation be propared as part of the proposal process and that the documentation be up to scratch? It seems the least we should be asking and much more important than requiring an implementation plan. This process is increasingly the only game in town when it comes to driving forward and defining Haskell and we need to make sure stuff is being written down properly. >>>> > >>>> > This is a bit of a tricky issue, I think. I agree that we should strive for a proper specification of ExplicitNamespaces. The current state seems to be sadly lacking, especially if we want ExplicitNamespaces to be in GHC2023. That said, there's a risk that proposal authors will be discouraged if proposing changes entails writing specifications for existing under-specified features! >>>> > >>>> > I wonder if anyone has attempted to extend "A Formal Specification of the Haskell 98 Module System" to more recent GHC extensions? >>>> > >>>> > Adam >>>> > >>>> > >>>> >>> On 12 Dec 2022, at 12:21, Adam Gundry >> wrote: >>>> >>> >>>> >>> On 12/12/2022 11:39, Simon Peyton Jones wrote: >>>> >>>> {-# LANGUAGE ExplicitNamespaces #-} >>>> >>>> module N where >>>> >>>> import M (T(type MkT)) -- NB "type" import of a data constructor >>>> >>>> v = MkT -- usage at term level Crumbs. I had not realised the proposal is to allow *nested* uses of 'type' in import lists, as you show above. >>>> >>> >>>> >>> The nested use is already possible with ExplicitNamespaces. Currently it allows >>>> >>> >>>> >>> import M (T(type MkT)) >>>> >>> import M (type MkT) >>>> >>> import M (pattern MkT) >>>> >>> >>>> >>> whereas the proposal extends it to add the possibility to write >>>> >>> >>>> >>> import M type (MkT) >>>> >>> import M data (MkT) >>>> >>> import M (data MkT) >>>> >>> >>>> >>> >>>> >>>> In general, I don't feel the extensions to ExplicitNamespaces included >>>> >>>> in the proposal are very clearly specified. Actually isn't the proposal pretty clear on this, namely the first bullet of proposed change spec >>. It only covers >>>> >>>> import M *type * >>>> >>>> import M *data *as MD >>>> >>>> where I have emboldened the new bits. Nothing about the contents of import lists. Why did you think your example is covered by the proposal? >>>> >>> >>>> >>> I'm trying to understand what >>>> >>> >>>> >>> import M type (MkT) >>>> >>> >>>> >>> means where MkT is a data constructor (or if it raises some kind of error). This was by analogy to the existing >>>> >>> >>>> >>> import M (T(type MkT)) >>>> >>> >>>> >>> which means something today, albeit not necessarily a very sensible thing (per https://gitlab.haskell.org/ghc/ghc/-/issues/22581 >). >>>> >>> >>>> >>> I don't see a clear specification of the proposed (extended) semantics of ExplicitNamespaces in the proposal, but perhaps I've missed something? >>>> >>> >>>> >>> Cheers, >>>> >>> >>>> >>> Adam >>>> >>> >>>> >>> >>>> >>>> On Mon, 12 Dec 2022 at 09:15, Adam Gundry > >>> wrote: >>>> >>>> Actually, reading https://gitlab.haskell.org/ghc/ghc/-/issues/22581 > >>>> >>>> >> I >>>> >>>> realised I'm unclear how the proposed extensions to ExplicitNamespaces >>>> >>>> are supposed to work. The existing situation is apparently that for a >>>> >>>> (non-punned) data constructor, it is possible to use either a >>>> >>>> pattern or >>>> >>>> type qualifier in an import list (presumably because DataKinds means >>>> >>>> the >>>> >>>> constructor is in scope at both the term and type levels), and the >>>> >>>> imported constructor is then usable in both contexts. >>>> >>>> For example, the following is accepted at present: >>>> >>>> module M where >>>> >>>> data T = MkT >>>> >>>> {-# LANGUAGE ExplicitNamespaces #-} >>>> >>>> module N where >>>> >>>> import M (T(type MkT)) -- NB "type" import of a data constructor >>>> >>>> v = MkT -- usage at term level >>>> >>>> The present proposal says "With type specified in the import, only >>>> >>>> identifiers belonging to the type namespace will be brought into the >>>> >>>> scope." I'm not exactly sure how to interpret this, does it mean the >>>> >>>> following alternative will be accepted or rejected? >>>> >>>> module N where >>>> >>>> import M type (MkT) >>>> >>>> v = MkT >>>> >>>> I'm worried we will end up with a situation where ExplicitNamespaces >>>> >>>> does subtly different things depending on the position of the keyword. >>>> >>>> In general, I don't feel the extensions to ExplicitNamespaces included >>>> >>>> in the proposal are very clearly specified. Given the discussion about >>>> >>>> exactly which parts belong to ExplicitNamespaces/PatternSynonyms versus >>>> >>>> separate extensions, perhaps we should accept the parts relating to >>>> >>>> -Wpuns/-Wpun-bindings, but ask for the ExplicitNamespaces changes to be >>>> >>>> proposed separately? >>>> >>>> Cheers, >>>> >>>> Adam >>>> >>>> On 09/12/2022 11:11, Adam Gundry wrote: >>>> >>>> > I'm broadly in favour of accepting the proposal. I realise the >>>> >>>> history >>>> >>>> > is complex here, so I don't think we should ask anyone to rewrite >>>> >>>> things >>>> >>>> > further, though in general it would be nicer to have separate >>>> >>>> proposals >>>> >>>> > for -Wpuns/-Wpun-bindings (which is unambiguously fine) and for the >>>> >>>> > changes to imports (which as Joachim points out raise issues). >>>> >>>> > >>>> >>>> > I'm a bit concerned that the proposal does not motivate or specify >>>> >>>> > -Wpattern-namespace-qualified very well. >>>> >>>> > >>>> >>>> > >>>> >>>> > On 08/12/2022 08:33, Joachim Breitner wrote: >>>> >>>> >> ... >>>> >>>> >> >>>> >>>> >> This gives us (at least) these options: >>>> >>>> >> >>>> >>>> >> 1. Leave ExplicitNamespaces alone, add ExplicitNamespaces to >>>> >>>> GHC2023, >>>> >>>> >> introduce one or two new extensions for the newer changes. >>>> >>>> >> 2. Extend ExplicitNamespaces, and don’t add it already to GHC2023, >>>> >>>> >> disregarding issue #551. >>>> >>>> >> 3. Add ExplicitNamespaces to GHC2023, and still add it to GHC2023, >>>> >>>> >> arguing that GHC20xx allows more liberal (backward-compatibile) >>>> >>>> >> changes than, say, Haskell2010 would allow. >>>> >>>> >> >>>> >>>> >> Certainly 1 is the least bold move. I am not sure what the best way >>>> >>>> >> forwards is, and welcome other opinions. >>>> >>>> > >>>> >>>> > I would prefer a variant of 1: allow "data" as a keyword in >>>> >>>> import lists >>>> >>>> > under ExplicitNamespaces, but make the other changes under other >>>> >>>> > extensions. >>>> >>>> > >>>> >>>> > As I've said previously, I have a general preference for multiple >>>> >>>> small, >>>> >>>> > orthogonal extensions rather than changing existing extensions to >>>> >>>> add >>>> >>>> > unrelated features that happen to be in similar territory. I realise >>>> >>>> > this is controversial, of course. >>>> >>>> > >>>> >>>> > Cheers, >>>> >>>> > >>>> >>>> > Adam >>>> > >>>> > >>>> > -- >>>> > Adam Gundry, Haskell Consultant >>>> > Well-Typed LLP, https://www.well-typed.com/ >>>> > >>>> > Registered in England & Wales, OC335890 >>>> > 27 Old Gloucester Street, London WC1N 3AX, England >>>> > >>>> > _______________________________________________ >>>> > ghc-steering-committee mailing list >>>> > ghc-steering-committee at haskell.org >>>> > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee >>>> >>>> _______________________________________________ >>>> ghc-steering-committee mailing list >>>> ghc-steering-committee at haskell.org >>>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee >>> >>> _______________________________________________ >>> ghc-steering-committee mailing list >>> ghc-steering-committee at haskell.org >>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mail at joachim-breitner.de Thu Dec 15 09:43:12 2022 From: mail at joachim-breitner.de (Joachim Breitner) Date: Thu, 15 Dec 2022 10:43:12 +0100 Subject: [ghc-steering-committee] Modifiers (Was: #512: NoFieldSelectors as datatype annotation) In-Reply-To: <010f01851335159c-3a5c2057-9560-4a8c-bb45-1bec9a193786-000000@us-east-2.amazonses.com> References: <494656e83f8d1486621fab153ed8f85f13b82e1b.camel@joachim-breitner.de> <414422bd-7085-f244-626a-19711dfd0692@well-typed.com> <02620ae95fb4d0a07172c06ffa83281d293e4149.camel@joachim-breitner.de> <451cf30d-8fc6-a052-0c3d-707b5f7fbc92@well-typed.com> <9484dee9-2d77-98ae-5b4d-ebc51f19cb24@well-typed.com> <13a361fc9689b0da5352085f4eab397d800af022.camel@joachim-breitner.de> <010f01851335159c-3a5c2057-9560-4a8c-bb45-1bec9a193786-000000@us-east-2.amazonses.com> Message-ID: <484c0bbb4e295d68c07365eec521ddc643ac184f.camel@joachim-breitner.de> Hi Richard, thanks, comparing Modifiers to the annotations and attributes in other languages indeed puts this into a perspective that makes more sense to me. It seems I have assumed a broader scope for modifiers (maybe because “modify” sounds much stronger than “annotate” or “attribut…ize”). So I conclude the goal is not to necessarily to remove _all_ kind of pragmas, but only maybe those that fit the pattern (e.g. don’t affect parsing and renaming). Is that right? So my straw man “could qualified imports be modifiers” is simply out of scope (heh). Especially the potential use case for plugins (which do benefit from an extensible, namespaced scheme that does not require changes to parsing) – essentially a variant of the ANN pragma – is convincing. Turning back to NoFieldSelectors, however, I notice that NoFieldSelectors _does_ affect renaming already, because it affects whether a symbol with the field’s name is in scope (which, in particular, has further effects with implicit binders etc…), doesn't it? So would modifiers, if we had them, even work here? Cheers, Joachim -- Joachim Breitner mail at joachim-breitner.de http://www.joachim-breitner.de/ From simon.peytonjones at gmail.com Thu Dec 15 12:04:36 2022 From: simon.peytonjones at gmail.com (Simon Peyton Jones) Date: Thu, 15 Dec 2022 12:04:36 +0000 Subject: [ghc-steering-committee] Modifiers (Was: #512: NoFieldSelectors as datatype annotation) In-Reply-To: <484c0bbb4e295d68c07365eec521ddc643ac184f.camel@joachim-breitner.de> References: <494656e83f8d1486621fab153ed8f85f13b82e1b.camel@joachim-breitner.de> <414422bd-7085-f244-626a-19711dfd0692@well-typed.com> <02620ae95fb4d0a07172c06ffa83281d293e4149.camel@joachim-breitner.de> <451cf30d-8fc6-a052-0c3d-707b5f7fbc92@well-typed.com> <9484dee9-2d77-98ae-5b4d-ebc51f19cb24@well-typed.com> <13a361fc9689b0da5352085f4eab397d800af022.camel@joachim-breitner.de> <010f01851335159c-3a5c2057-9560-4a8c-bb45-1bec9a193786-000000@us-east-2.amazonses.com> <484c0bbb4e295d68c07365eec521ddc643ac184f.camel@joachim-breitner.de> Message-ID: Hmm. - We have an accepted proposal for modifiers. - As of today we have a willing implementer, Georgi: https://gitlab.haskell.org/ghc/ghc/-/issues/22624 And yet some doubt is being expressed in this thread about whether the accepted proposal is the one we really want. @rae Georgi says you are going to mentor him. Do you feel able to help us converge on a design we are all content with; quite possibly just reaffirming the current accepted proposal? Simon On Thu, 15 Dec 2022 at 09:43, Joachim Breitner wrote: > Hi Richard, > > thanks, comparing Modifiers to the annotations and attributes in other > languages indeed puts this into a perspective that makes more sense to > me. It seems I have assumed a broader scope for modifiers (maybe > because “modify” sounds much stronger than “annotate” or > “attribut…ize”). So I conclude the goal is not to necessarily to remove > _all_ kind of pragmas, but only maybe those that fit the pattern (e.g. > don’t affect parsing and renaming). Is that right? > > So my straw man “could qualified imports be modifiers” is simply out of > scope (heh). > > Especially the potential use case for plugins (which do benefit from an > extensible, namespaced scheme that does not require changes to parsing) > – essentially a variant of the ANN pragma – is convincing. > > Turning back to NoFieldSelectors, however, I notice that > NoFieldSelectors _does_ affect renaming already, because it affects > whether a symbol with the field’s name is in scope (which, in > particular, has further effects with implicit binders etc…), doesn't > it? So would modifiers, if we had them, even work here? > > > Cheers, > Joachim > -- > Joachim Breitner > mail at joachim-breitner.de > http://www.joachim-breitner.de/ > > _______________________________________________ > 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 chris at chrisdornan.com Thu Dec 15 16:49:49 2022 From: chris at chrisdornan.com (Chris Dornan) Date: Thu, 15 Dec 2022 16:49:49 +0000 Subject: [ghc-steering-committee] Proposal #270: Support pun-free code. Recommendation: accept In-Reply-To: References: <5D0E3610-C73F-4850-9435-8D22069382BD@chrisdornan.com> <2da00f7f92f292bb16a4dfc53ec62d68ecf6edc9.camel@joachim-breitner.de> <3267a53a47cec3597c54bab8f8518b2c1613e1a8.camel@joachim-breitner.de> <0e9b3372-5034-f596-acd2-aecc3c7be701@well-typed.com> <089f0c63-ed84-186f-6f70-0372b95e4c3e@well-typed.com> <14cede64-5f45-b6d1-e17a-cd1bb9cd106a@well-typed.com> <9B22308E-170D-4B86-BFF8-1E63D3DF5387@chrisdornan.com> <84D37F3F-FC1D-4B57-BE99-B355419E8EA4@chrisdornan.com> <428DC3AB-9C06-4950-9151-7B22F5079A1A@chrisdornan.com> <010f018513409c8d-ac89ef3e-401c-4612-81b1-aee295530f2a-000000@us-east-2.amazonses.com> Message-ID: Does anybody object to us accepting #270 now? Speak now, etc. > On 15 Dec 2022, at 08:14, Simon Peyton Jones wrote: > > I recommend acceptance as-is. > > I see no difficulty with the namespace part of the proposal. Yes, the existing namespace extension is ill specified. But this proposal does not make that situation worse (the delta is clearly specified), and it seems unfair of us to penalise this proposal because of the pre-existing situation. > > Of course, it would be better still to have a new, subsequent proposal that clarifies the ExplicitNameSpaceProposal. Perhaps we could invite Artyom write it, as a favour to the community. Or perhaps a member of the committee might like to. > > Simon > > On Thu, 15 Dec 2022 at 00:55, Chris Dornan > wrote: > For reasons I have made entirely clear I _strongly_ desire this split — are you offering to take over shepherding this proposal Richard? Because I am now totally stymied and unable to manage the process. > >> On 15 Dec 2022, at 00:47, Richard Eisenberg > wrote: >> >> I strongly oppose requesting that the proposal be split. I agree that the two parts of the proposal can notionally be separated. But sometimes I feel that, in the face of difficult decisions, this committee has punted by requesting formatting changes of proposals. My case in point is around #448 about scoped type variables. That proposal arose out of a smattering of other proposals... but the committee deemed that the other proposals were too separate and needed to be considered as a whole. So, with some effort, I put them all in one. Then members of the committee said that the proposal was too big and to break it up! I refused, and had to hold my ground despite several requests. In the end, half was accepted, and at that point I took the other half and re-proposed it. I actually don't mind that last part -- I think partial acceptance is a reasonable action. But the formatting and reformatting is quite a bit of work, and I'm not convinced it really helped our debate. I'm worried we're repeating this here. >> >> Richard >> >>> On Dec 13, 2022, at 10:50 AM, Chris Dornan > wrote: >>> >>> Although the two aspects of the proposal were motivated by the same problem they are doing completely different things. As long as it was easier to deal with them together the path of least resistance was to keep them bundled up, but it is becoming ever clearer that they are tied up in divergent organisational as well as technical concerns. The warnings are well understood and ready to go with a patch whereas, as this thread illustrates, nobody seems to properly understand what is going on with ExplicitNameSpaces; we are still confident that we can sort it all out and confident that we want to sort it all out but still there is work to be done. >>> >>> Added to this there is the fact that the problems with namespaces are entirely inherited from an existing extension that is poorly documented and, as we have just discovered, poorly understood. For all the reasons explained in the proposal we are likely to be leaning more heavily on ExplicitNameSpaces as we develop DH so we really need sort out what it does and get it written down. Here is the kicker — when we do sort out ExplicitNameSpaces and write it up properly we are going to want it attached to language extension dedicated to managing ExplicitNameSpaces, not an extension bundled up with some enabled warnings. >>> >>> I am happy to work with Artyom to get the new proposal set up etc. >>> >>> Chris >>> >>> >>>> On 13 Dec 2022, at 09:01, Simon Peyton Jones > wrote: >>>> >>>> I still don't get the "split in two" thing. The proposal is quite clear about the delta to ExplicitNameSpaces. The fact that the latter is not well specified isn't the current author's fault; and the delta makes sense as part of this proposal. >>>> >>>> I think we should accept this one, and politely ask the author if they would consider (as a favour) writing a delta to the ExplicitNameSpaces proposal (I assume there is one?) to clarify it. >>>> >>>> Simon >>>> >>>> On Mon, 12 Dec 2022 at 22:05, Chris Dornan > wrote: >>>> In this case, for sure, responsibility for fixing up namespace documentation should not fall on the author of this proposal. I am thinking more that they should be strongly encouraged to submit the follow-up proposal and we provide or identify whatever assistance necessary to get the job done. It will definitely get us to a better place in my view. >>>> >>>> It sounds like we are in strong agreement. >>>> >>>> Chris >>>> >>>> >>>> >>>> > On 12 Dec 2022, at 20:11, Adam Gundry > wrote: >>>> > >>>> > On 12/12/2022 16:50, Chris Dornan wrote: >>>> >> I really think we should split this proposal into two, one to deal with warnings and the other to deal with namespaces. The warnings look to me ready to go. >>>> >> I am further thinking that we should really welcome the followup namespace proposal as an opportunity to clarify and properly document namespaces. >>>> >> I am sorry, I was added to the proposal very late thinking it was technically sound but I am realising it is far from the case. >>>> >> Finally, I am quite surprised at how little documentation there seems to be on ExplicitNamespaces. Should we be asking that revised documentation be propared as part of the proposal process and that the documentation be up to scratch? It seems the least we should be asking and much more important than requiring an implementation plan. This process is increasingly the only game in town when it comes to driving forward and defining Haskell and we need to make sure stuff is being written down properly. >>>> > >>>> > This is a bit of a tricky issue, I think. I agree that we should strive for a proper specification of ExplicitNamespaces. The current state seems to be sadly lacking, especially if we want ExplicitNamespaces to be in GHC2023. That said, there's a risk that proposal authors will be discouraged if proposing changes entails writing specifications for existing under-specified features! >>>> > >>>> > I wonder if anyone has attempted to extend "A Formal Specification of the Haskell 98 Module System" to more recent GHC extensions? >>>> > >>>> > Adam >>>> > >>>> > >>>> >>> On 12 Dec 2022, at 12:21, Adam Gundry >> wrote: >>>> >>> >>>> >>> On 12/12/2022 11:39, Simon Peyton Jones wrote: >>>> >>>> {-# LANGUAGE ExplicitNamespaces #-} >>>> >>>> module N where >>>> >>>> import M (T(type MkT)) -- NB "type" import of a data constructor >>>> >>>> v = MkT -- usage at term level Crumbs. I had not realised the proposal is to allow *nested* uses of 'type' in import lists, as you show above. >>>> >>> >>>> >>> The nested use is already possible with ExplicitNamespaces. Currently it allows >>>> >>> >>>> >>> import M (T(type MkT)) >>>> >>> import M (type MkT) >>>> >>> import M (pattern MkT) >>>> >>> >>>> >>> whereas the proposal extends it to add the possibility to write >>>> >>> >>>> >>> import M type (MkT) >>>> >>> import M data (MkT) >>>> >>> import M (data MkT) >>>> >>> >>>> >>> >>>> >>>> In general, I don't feel the extensions to ExplicitNamespaces included >>>> >>>> in the proposal are very clearly specified. Actually isn't the proposal pretty clear on this, namely the first bullet of proposed change spec >>. It only covers >>>> >>>> import M *type * >>>> >>>> import M *data *as MD >>>> >>>> where I have emboldened the new bits. Nothing about the contents of import lists. Why did you think your example is covered by the proposal? >>>> >>> >>>> >>> I'm trying to understand what >>>> >>> >>>> >>> import M type (MkT) >>>> >>> >>>> >>> means where MkT is a data constructor (or if it raises some kind of error). This was by analogy to the existing >>>> >>> >>>> >>> import M (T(type MkT)) >>>> >>> >>>> >>> which means something today, albeit not necessarily a very sensible thing (per https://gitlab.haskell.org/ghc/ghc/-/issues/22581 >). >>>> >>> >>>> >>> I don't see a clear specification of the proposed (extended) semantics of ExplicitNamespaces in the proposal, but perhaps I've missed something? >>>> >>> >>>> >>> Cheers, >>>> >>> >>>> >>> Adam >>>> >>> >>>> >>> >>>> >>>> On Mon, 12 Dec 2022 at 09:15, Adam Gundry > >>> wrote: >>>> >>>> Actually, reading https://gitlab.haskell.org/ghc/ghc/-/issues/22581 > >>>> >>>> >> I >>>> >>>> realised I'm unclear how the proposed extensions to ExplicitNamespaces >>>> >>>> are supposed to work. The existing situation is apparently that for a >>>> >>>> (non-punned) data constructor, it is possible to use either a >>>> >>>> pattern or >>>> >>>> type qualifier in an import list (presumably because DataKinds means >>>> >>>> the >>>> >>>> constructor is in scope at both the term and type levels), and the >>>> >>>> imported constructor is then usable in both contexts. >>>> >>>> For example, the following is accepted at present: >>>> >>>> module M where >>>> >>>> data T = MkT >>>> >>>> {-# LANGUAGE ExplicitNamespaces #-} >>>> >>>> module N where >>>> >>>> import M (T(type MkT)) -- NB "type" import of a data constructor >>>> >>>> v = MkT -- usage at term level >>>> >>>> The present proposal says "With type specified in the import, only >>>> >>>> identifiers belonging to the type namespace will be brought into the >>>> >>>> scope." I'm not exactly sure how to interpret this, does it mean the >>>> >>>> following alternative will be accepted or rejected? >>>> >>>> module N where >>>> >>>> import M type (MkT) >>>> >>>> v = MkT >>>> >>>> I'm worried we will end up with a situation where ExplicitNamespaces >>>> >>>> does subtly different things depending on the position of the keyword. >>>> >>>> In general, I don't feel the extensions to ExplicitNamespaces included >>>> >>>> in the proposal are very clearly specified. Given the discussion about >>>> >>>> exactly which parts belong to ExplicitNamespaces/PatternSynonyms versus >>>> >>>> separate extensions, perhaps we should accept the parts relating to >>>> >>>> -Wpuns/-Wpun-bindings, but ask for the ExplicitNamespaces changes to be >>>> >>>> proposed separately? >>>> >>>> Cheers, >>>> >>>> Adam >>>> >>>> On 09/12/2022 11:11, Adam Gundry wrote: >>>> >>>> > I'm broadly in favour of accepting the proposal. I realise the >>>> >>>> history >>>> >>>> > is complex here, so I don't think we should ask anyone to rewrite >>>> >>>> things >>>> >>>> > further, though in general it would be nicer to have separate >>>> >>>> proposals >>>> >>>> > for -Wpuns/-Wpun-bindings (which is unambiguously fine) and for the >>>> >>>> > changes to imports (which as Joachim points out raise issues). >>>> >>>> > >>>> >>>> > I'm a bit concerned that the proposal does not motivate or specify >>>> >>>> > -Wpattern-namespace-qualified very well. >>>> >>>> > >>>> >>>> > >>>> >>>> > On 08/12/2022 08:33, Joachim Breitner wrote: >>>> >>>> >> ... >>>> >>>> >> >>>> >>>> >> This gives us (at least) these options: >>>> >>>> >> >>>> >>>> >> 1. Leave ExplicitNamespaces alone, add ExplicitNamespaces to >>>> >>>> GHC2023, >>>> >>>> >> introduce one or two new extensions for the newer changes. >>>> >>>> >> 2. Extend ExplicitNamespaces, and don’t add it already to GHC2023, >>>> >>>> >> disregarding issue #551. >>>> >>>> >> 3. Add ExplicitNamespaces to GHC2023, and still add it to GHC2023, >>>> >>>> >> arguing that GHC20xx allows more liberal (backward-compatibile) >>>> >>>> >> changes than, say, Haskell2010 would allow. >>>> >>>> >> >>>> >>>> >> Certainly 1 is the least bold move. I am not sure what the best way >>>> >>>> >> forwards is, and welcome other opinions. >>>> >>>> > >>>> >>>> > I would prefer a variant of 1: allow "data" as a keyword in >>>> >>>> import lists >>>> >>>> > under ExplicitNamespaces, but make the other changes under other >>>> >>>> > extensions. >>>> >>>> > >>>> >>>> > As I've said previously, I have a general preference for multiple >>>> >>>> small, >>>> >>>> > orthogonal extensions rather than changing existing extensions to >>>> >>>> add >>>> >>>> > unrelated features that happen to be in similar territory. I realise >>>> >>>> > this is controversial, of course. >>>> >>>> > >>>> >>>> > Cheers, >>>> >>>> > >>>> >>>> > Adam >>>> > >>>> > >>>> > -- >>>> > Adam Gundry, Haskell Consultant >>>> > Well-Typed LLP, https://www.well-typed.com/ >>>> > >>>> > Registered in England & Wales, OC335890 >>>> > 27 Old Gloucester Street, London WC1N 3AX, England >>>> > >>>> > _______________________________________________ >>>> > ghc-steering-committee mailing list >>>> > ghc-steering-committee at haskell.org >>>> > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee >>>> >>>> _______________________________________________ >>>> ghc-steering-committee mailing list >>>> ghc-steering-committee at haskell.org >>>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee >>> >>> _______________________________________________ >>> ghc-steering-committee mailing list >>> ghc-steering-committee at haskell.org >>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From adam at well-typed.com Thu Dec 15 20:06:04 2022 From: adam at well-typed.com (Adam Gundry) Date: Thu, 15 Dec 2022 20:06:04 +0000 Subject: [ghc-steering-committee] Proposal #270: Support pun-free code. Recommendation: accept In-Reply-To: References: <5D0E3610-C73F-4850-9435-8D22069382BD@chrisdornan.com> <0e9b3372-5034-f596-acd2-aecc3c7be701@well-typed.com> <089f0c63-ed84-186f-6f70-0372b95e4c3e@well-typed.com> <14cede64-5f45-b6d1-e17a-cd1bb9cd106a@well-typed.com> <9B22308E-170D-4B86-BFF8-1E63D3DF5387@chrisdornan.com> <84D37F3F-FC1D-4B57-BE99-B355419E8EA4@chrisdornan.com> <428DC3AB-9C06-4950-9151-7B22F5079A1A@chrisdornan.com> <010f018513409c8d-ac89ef3e-401c-4612-81b1-aee295530f2a-000000@us-east-2.amazonses.com> Message-ID: <89efaf40-124d-9503-6fba-d608726db75a@well-typed.com> On 15/12/2022 16:49, Chris Dornan wrote: > Does anybody object to us accepting #270 now? Speak now, etc. I object to accepting #270 as-is, I'm afraid. I'm content to accept the parts relating to -Wpuns/-Wpun-bindings, which seem to be relatively well-motivated and specified in the proposal (albeit primarily by the medium of examples). Indeed they form the bulk of the proposal content! However the parts related to extensions seem problematic and have given rise to substantial discussion: * We don't yet have a clear consensus on the approach to language extensions (as is being discussed elsewhere), which makes it difficult to reach agreement on whether the proposal should be modifying existing extensions or introducing new ones. * In particular, if we modify ExplicitNamespaces it will become more problematic to introduce it as part of GHC2023, which leaves https://github.com/ghc-proposals/ghc-proposals/issues/551 unresolved. * ExplicitNamespaces is under-specified at present, which is not the proposer's fault, but by modifying it we will make it yet more complex and inconsistent (e.g. allowing either "type" or "data" at the top level, but only "type" in the impspec unless PatternSynonyms is enabled). * I disagree with Simon's "The proposal is quite clear about the delta to ExplicitNameSpaces." For example, it doesn't specify or provide any examples of imports with an impspec; does "import M type (T(MkT))" silently import T but not MkT, or it it an error? * The change to PatternSynonyms and introducing of -Wpattern-namespace-qualifier is not clearly motivated in the text (though one can imagine some motivations), and we should consider whether breaking old code in this way is justified. I'm sure these issues can be resolved, but I think the best way to do so is to accept the -Wpuns/-Wpun-bindings parts of the proposal, while asking for the changes to extensions to be raised as a separate proposal with its own motivation, specification and examples. (This isn't about "formatting", so if splitting the proposal seems problematic it would also be fine for the whole proposal to be resubmitted; but that seems like it will be harder than a split.) I would point out the guidelines in our README: > If the technical debate is not rapidly resolved, the shepherd should > return the proposal for revision. Further technical discussion can > then take place, the author can incorporate that conclusions in the > proposal itself, and re-submit it. Returning a proposal for revision > is not a negative judgement; on the contrary it might connote "we > absolutely love this proposal but we want it to be clear on these > points". > > In fact, this should happen if any substantive technical debate takes > place. The goal of the committee review is to say yes/no to a proposal > as it stands. With apologies for causing controversy, Adam >> On 15 Dec 2022, at 08:14, Simon Peyton Jones >> > wrote: >> >> I recommend acceptance as-is. >> >> I see no difficulty with the namespace part of the proposal.  Yes, the >> /existing /namespace extension is ill specified. But this proposal >> does not make that situation worse (the delta is clearly specified), >> and it seems unfair of us to penalise this proposal because of the >> pre-existing situation. >> >> Of course, it would be better still to have a new, subsequent proposal >> that clarifies the ExplicitNameSpaceProposal.  Perhaps we could invite >> Artyom write it, as a favour to the community.  Or perhaps a member of >> the committee might like to. >> >> Simon >> >> On Thu, 15 Dec 2022 at 00:55, Chris Dornan > > wrote: >> >> For reasons I have made entirely clear I _strongly_ desire this >> split — are you offering to take over shepherding this proposal >> Richard? Because I am now totally stymied and unable to manage the >> process. >> >>> On 15 Dec 2022, at 00:47, Richard Eisenberg >> > wrote: >>> >>> I strongly oppose requesting that the proposal be split. I agree >>> that the two parts of the proposal can notionally be separated. >>> But sometimes I feel that, in the face of difficult decisions, >>> this committee has punted by requesting formatting changes of >>> proposals. My case in point is around #448 about scoped type >>> variables. That proposal arose out of a smattering of other >>> proposals... but the committee deemed that the other proposals >>> were too separate and needed to be considered as a whole. So, >>> with some effort, I put them all in one. Then members of the >>> committee said that the proposal was too big and to break it up! >>> I refused, and had to hold my ground despite several requests. In >>> the end, half was accepted, and at that point I took the other >>> half and re-proposed it. I actually don't mind that last part -- >>> I think partial acceptance is a reasonable action. But the >>> formatting and reformatting is quite a bit of work, and I'm not >>> convinced it really helped our debate. I'm worried we're >>> repeating this here. >>> >>> Richard >>> >>>> On Dec 13, 2022, at 10:50 AM, Chris Dornan >>>> > wrote: >>>> >>>> Although the two aspects of the proposal were motivated by the >>>> same problem they are doing completely different things. As long >>>> as it was easier to deal with them together the path of least >>>> resistance was to keep them bundled up, but it is becoming ever >>>> clearer that they are tied up in divergent organisational as >>>> well as technical concerns. The warnings are well understood and >>>> ready to go with a patch whereas, as this thread illustrates, >>>> nobody seems to properly understand what is going on with >>>> ExplicitNameSpaces; we are still confident that we can sort it >>>> all out and confident that we want to sort it all out but still >>>> there is work to be done. >>>> >>>> Added to this there is the fact that the problems with >>>> namespaces are entirely inherited from an existing extension >>>> that is poorly documented and, as we have just discovered, >>>> poorly understood. For all the reasons explained in the proposal >>>> we are likely to be leaning more heavily on >>>> ExplicitNameSpaces as we develop DH so we really need sort out >>>> what it does and get it written down. Here is the kicker — when >>>> we do sort out ExplicitNameSpaces and write it up properly we >>>> are going to want it attached to language extension dedicated to >>>> managing ExplicitNameSpaces, not an extension bundled up with >>>> some enabled warnings. >>>> >>>> I am happy to work with Artyom to get the new proposal set up etc. >>>> >>>> Chris >>>> >>>> >>>>> On 13 Dec 2022, at 09:01, Simon Peyton Jones >>>>> >>>> > wrote: >>>>> >>>>> I still don't get the "split in two" thing.  The proposal is >>>>> quite clear about the delta to ExplicitNameSpaces.  The fact >>>>> that the latter is not well specified isn't the current >>>>> author's fault; and the delta makes sense as part of this proposal. >>>>> >>>>> I think we should accept this one, and politely ask the author >>>>> if they would consider (as a favour) writing a delta to the >>>>> ExplicitNameSpaces proposal (I assume there is one?) to clarify it. >>>>> >>>>> Simon >>>>> >>>>> On Mon, 12 Dec 2022 at 22:05, Chris Dornan >>>>> > wrote: >>>>> >>>>> In this case, for sure, responsibility for fixing up >>>>> namespace documentation should not fall on the author of >>>>> this proposal. I am thinking more that they should be >>>>> strongly encouraged to submit the follow-up proposal and we >>>>> provide or identify whatever assistance necessary to get >>>>> the job done. It will definitely get us to a better place >>>>> in my view. >>>>> >>>>> It sounds like we are in strong agreement. >>>>> >>>>> Chris >>>>> >>>>> >>>>> >>>>> > On 12 Dec 2022, at 20:11, Adam Gundry >>>>> > wrote: >>>>> > >>>>> > On 12/12/2022 16:50, Chris Dornan wrote: >>>>> >> I really think we should split this proposal into two, >>>>> one to deal with warnings and the other to deal with >>>>> namespaces. The warnings look to me ready to go. >>>>> >> I am further thinking that we should really welcome the >>>>> followup namespace proposal as an opportunity to clarify >>>>> and properly document namespaces. >>>>> >> I am sorry, I was added to the proposal very late >>>>> thinking it was technically sound but I am realising it is >>>>> far from the case. >>>>> >> Finally, I am quite surprised at how little >>>>> documentation there seems to be on ExplicitNamespaces. >>>>> Should we be asking that revised documentation be propared >>>>> as part of the proposal process and that the documentation >>>>> be up to scratch? It seems the least we should be asking >>>>> and much more important than requiring an implementation >>>>> plan. This process is increasingly the only game in town >>>>> when it comes to driving forward and defining Haskell and >>>>> we need to make sure stuff is being written down properly. >>>>> > >>>>> > This is a bit of a tricky issue, I think. I agree that we >>>>> should strive for a proper specification of >>>>> ExplicitNamespaces. The current state seems to be sadly >>>>> lacking, especially if we want ExplicitNamespaces to be in >>>>> GHC2023. That said, there's a risk that proposal authors >>>>> will be discouraged if proposing changes entails writing >>>>> specifications for existing under-specified features! >>>>> > >>>>> > I wonder if anyone has attempted to extend "A Formal >>>>> Specification of the Haskell 98 Module System" to more >>>>> recent GHC extensions? >>>>> > >>>>> > Adam >>>>> > >>>>> > >>>>> >>> On 12 Dec 2022, at 12:21, Adam Gundry >>>>> >>>>> >> >>>>> wrote: >>>>> >>> >>>>> >>> On 12/12/2022 11:39, Simon Peyton Jones wrote: >>>>> >>>>        {-# LANGUAGE ExplicitNamespaces #-} >>>>> >>>>        module N where >>>>> >>>>          import M (T(type MkT)) -- NB "type" import of >>>>> a data constructor >>>>> >>>>          v = MkT                -- usage at term level >>>>> Crumbs.  I had not realised the proposal is to allow >>>>> *nested* uses of 'type' in import lists, as you show above. >>>>> >>> >>>>> >>> The nested use is already possible with >>>>> ExplicitNamespaces. Currently it allows >>>>> >>> >>>>> >>>    import M (T(type MkT)) >>>>> >>>    import M (type MkT) >>>>> >>>    import M (pattern MkT) >>>>> >>> >>>>> >>> whereas the proposal extends it to add the possibility >>>>> to write >>>>> >>> >>>>> >>>    import M type (MkT) >>>>> >>>    import M data (MkT) >>>>> >>>    import M (data MkT) >>>>> >>> >>>>> >>> >>>>> >>>>    In general, I don't feel the extensions to >>>>> ExplicitNamespaces included >>>>> >>>>    in the proposal are very clearly specified. >>>>> Actually isn't the proposal pretty clear on this, namely >>>>> the first bullet of proposed change spec >>>>> >>.  It only covers >>>>> >>>> import M *type * >>>>> >>>> import M *data *as MD >>>>> >>>> where I have emboldened the new bits.  Nothing about >>>>> the contents of import lists.   Why did you think your >>>>> example is covered by the proposal? >>>>> >>> >>>>> >>> I'm trying to understand what >>>>> >>> >>>>> >>>    import M type (MkT) >>>>> >>> >>>>> >>> means where MkT is a data constructor (or if it raises >>>>> some kind of error). This was by analogy to the existing >>>>> >>> >>>>> >>>    import M (T(type MkT)) >>>>> >>> >>>>> >>> which means something today, albeit not necessarily a >>>>> very sensible thing (per >>>>> https://gitlab.haskell.org/ghc/ghc/-/issues/22581 >>>>> >>>>> >>>> >). >>>>> >>> >>>>> >>> I don't see a clear specification of the proposed >>>>> (extended) semantics of ExplicitNamespaces in the proposal, >>>>> but perhaps I've missed something? >>>>> >>> >>>>> >>> Cheers, >>>>> >>> >>>>> >>> Adam >>>>> >>> >>>>> >>> >>>>> >>>> On Mon, 12 Dec 2022 at 09:15, Adam Gundry >>>>> >>>>> > >>>>> >>>>> >>> >>>>> wrote: >>>>> >>>>    Actually, reading >>>>> https://gitlab.haskell.org/ghc/ghc/-/issues/22581 >>>>> >>>>> >>>> > >>>>> >>>>    >>>> >>>>> >>>> >> I >>>>> >>>>    realised I'm unclear how the proposed extensions to >>>>> ExplicitNamespaces >>>>> >>>>    are supposed to work. The existing situation is >>>>> apparently that for a >>>>> >>>>    (non-punned) data constructor, it is possible to >>>>> use either a >>>>> >>>>    pattern or >>>>> >>>>    type qualifier in an import list (presumably >>>>> because DataKinds means >>>>> >>>>    the >>>>> >>>>    constructor is in scope at both the term and type >>>>> levels), and the >>>>> >>>>    imported constructor is then usable in both contexts. >>>>> >>>>    For example, the following is accepted at present: >>>>> >>>>         module M where >>>>> >>>>           data T = MkT >>>>> >>>>        {-# LANGUAGE ExplicitNamespaces #-} >>>>> >>>>        module N where >>>>> >>>>          import M (T(type MkT)) -- NB "type" import of >>>>> a data constructor >>>>> >>>>          v = MkT                -- usage at term level >>>>> >>>>    The present proposal says "With type specified in >>>>> the import, only >>>>> >>>>    identifiers belonging to the type namespace will be >>>>> brought into the >>>>> >>>>    scope." I'm not exactly sure how to interpret this, >>>>> does it mean the >>>>> >>>>    following alternative will be accepted or rejected? >>>>> >>>>        module N where >>>>> >>>>          import M type (MkT) >>>>> >>>>          v = MkT >>>>> >>>>    I'm worried we will end up with a situation where >>>>> ExplicitNamespaces >>>>> >>>>    does subtly different things depending on the >>>>> position of the keyword. >>>>> >>>>    In general, I don't feel the extensions to >>>>> ExplicitNamespaces included >>>>> >>>>    in the proposal are very clearly specified. Given >>>>> the discussion about >>>>> >>>>    exactly which parts belong to >>>>> ExplicitNamespaces/PatternSynonyms versus >>>>> >>>>    separate extensions, perhaps we should accept the >>>>> parts relating to >>>>> >>>>    -Wpuns/-Wpun-bindings, but ask for the >>>>> ExplicitNamespaces changes to be >>>>> >>>>    proposed separately? >>>>> >>>>    Cheers, >>>>> >>>>    Adam >>>>> >>>>    On 09/12/2022 11:11, Adam Gundry wrote: >>>>> >>>>     > I'm broadly in favour of accepting the proposal. >>>>> I realise the >>>>> >>>>    history >>>>> >>>>     > is complex here, so I don't think we should ask >>>>> anyone to rewrite >>>>> >>>>    things >>>>> >>>>     > further, though in general it would be nicer to >>>>> have separate >>>>> >>>>    proposals >>>>> >>>>     > for -Wpuns/-Wpun-bindings (which is >>>>> unambiguously fine) and for the >>>>> >>>>     > changes to imports (which as Joachim points out >>>>> raise issues). >>>>> >>>>     > >>>>> >>>>     > I'm a bit concerned that the proposal does not >>>>> motivate or specify >>>>> >>>>     > -Wpattern-namespace-qualified very well. >>>>> >>>>     > >>>>> >>>>     > >>>>> >>>>     > On 08/12/2022 08:33, Joachim Breitner wrote: >>>>> >>>>     >> ... >>>>> >>>>     >> >>>>> >>>>     >> This gives us (at least) these options: >>>>> >>>>     >> >>>>> >>>>     >> 1. Leave ExplicitNamespaces alone, add >>>>> ExplicitNamespaces to >>>>> >>>>    GHC2023, >>>>> >>>>     >>     introduce one or two new extensions for the >>>>> newer changes. >>>>> >>>>     >> 2. Extend ExplicitNamespaces, and don’t add it >>>>> already to GHC2023, >>>>> >>>>     >>     disregarding issue #551. >>>>> >>>>     >> 3. Add ExplicitNamespaces to GHC2023, and still >>>>> add it to GHC2023, >>>>> >>>>     >>     arguing that GHC20xx allows more liberal >>>>> (backward-compatibile) >>>>> >>>>     >>     changes than, say, Haskell2010 would allow. >>>>> >>>>     >> >>>>> >>>>     >> Certainly 1 is the least bold move. I am not >>>>> sure what the best way >>>>> >>>>     >> forwards is, and welcome other opinions. >>>>> >>>>     > >>>>> >>>>     > I would prefer a variant of 1: allow "data" as a >>>>> keyword in >>>>> >>>>    import lists >>>>> >>>>     > under ExplicitNamespaces, but make the other >>>>> changes under other >>>>> >>>>     > extensions. >>>>> >>>>     > >>>>> >>>>     > As I've said previously, I have a general >>>>> preference for multiple >>>>> >>>>    small, >>>>> >>>>     > orthogonal extensions rather than changing >>>>> existing extensions to >>>>> >>>>    add >>>>> >>>>     > unrelated features that happen to be in similar >>>>> territory. I realise >>>>> >>>>     > this is controversial, of course. >>>>> >>>>     > >>>>> >>>>     > Cheers, >>>>> >>>>     > >>>>> >>>>     > Adam -- Adam Gundry, Haskell Consultant Well-Typed LLP, https://www.well-typed.com/ Registered in England & Wales, OC335890 27 Old Gloucester Street, London WC1N 3AX, England From chris at chrisdornan.com Thu Dec 15 20:35:36 2022 From: chris at chrisdornan.com (Chris Dornan) Date: Thu, 15 Dec 2022 20:35:36 +0000 Subject: [ghc-steering-committee] Proposal #270: Support pun-free code. Recommendation: accept In-Reply-To: <89efaf40-124d-9503-6fba-d608726db75a@well-typed.com> References: <5D0E3610-C73F-4850-9435-8D22069382BD@chrisdornan.com> <0e9b3372-5034-f596-acd2-aecc3c7be701@well-typed.com> <089f0c63-ed84-186f-6f70-0372b95e4c3e@well-typed.com> <14cede64-5f45-b6d1-e17a-cd1bb9cd106a@well-typed.com> <9B22308E-170D-4B86-BFF8-1E63D3DF5387@chrisdornan.com> <84D37F3F-FC1D-4B57-BE99-B355419E8EA4@chrisdornan.com> <428DC3AB-9C06-4950-9151-7B22F5079A1A@chrisdornan.com> <010f018513409c8d-ac89ef3e-401c-4612-81b1-aee295530f2a-000000@us-east-2.amazonses.com> <89efaf40-124d-9503-6fba-d608726db75a@well-typed.com> Message-ID: Thanks Adam, You have nothing to apologise for — it is the rest of us that should be apologising to you! I can hardly disagree with anything you say as it, belatedly, lines with my own view. In my view this proposal has been highly productive in highlighting the issues around puns and proposing warnings, with a patch. But also productive for highlighting the state of the ExplicitNamespaces extension. The author has shown the patience of a saint and I would be citing him for a medal if it were possible. I will attempt to convey my gratitude and see if we can prevail upon him to help us with the follow-up. While it was very tempting to just accept the proposal and try and patch things up, this I feel sure this is actually the right course of action (TM). I am so glad you are on the committee! Chris > On 15 Dec 2022, at 20:06, Adam Gundry wrote: > > On 15/12/2022 16:49, Chris Dornan wrote: >> Does anybody object to us accepting #270 now? Speak now, etc. > > I object to accepting #270 as-is, I'm afraid. > > I'm content to accept the parts relating to -Wpuns/-Wpun-bindings, which seem to be relatively well-motivated and specified in the proposal (albeit primarily by the medium of examples). Indeed they form the bulk of the proposal content! > > However the parts related to extensions seem problematic and have given rise to substantial discussion: > > * We don't yet have a clear consensus on the approach to language extensions (as is being discussed elsewhere), which makes it difficult to reach agreement on whether the proposal should be modifying existing extensions or introducing new ones. > > * In particular, if we modify ExplicitNamespaces it will become more problematic to introduce it as part of GHC2023, which leaves https://github.com/ghc-proposals/ghc-proposals/issues/551 unresolved. > > * ExplicitNamespaces is under-specified at present, which is not the proposer's fault, but by modifying it we will make it yet more complex and inconsistent (e.g. allowing either "type" or "data" at the top level, but only "type" in the impspec unless PatternSynonyms is enabled). > > * I disagree with Simon's "The proposal is quite clear about the delta to ExplicitNameSpaces." For example, it doesn't specify or provide any examples of imports with an impspec; does "import M type (T(MkT))" silently import T but not MkT, or it it an error? > > * The change to PatternSynonyms and introducing of -Wpattern-namespace-qualifier is not clearly motivated in the text (though one can imagine some motivations), and we should consider whether breaking old code in this way is justified. > > I'm sure these issues can be resolved, but I think the best way to do so is to accept the -Wpuns/-Wpun-bindings parts of the proposal, while asking for the changes to extensions to be raised as a separate proposal with its own motivation, specification and examples. (This isn't about "formatting", so if splitting the proposal seems problematic it would also be fine for the whole proposal to be resubmitted; but that seems like it will be harder than a split.) > > I would point out the guidelines in our README: > > > If the technical debate is not rapidly resolved, the shepherd should > > return the proposal for revision. Further technical discussion can > > then take place, the author can incorporate that conclusions in the > > proposal itself, and re-submit it. Returning a proposal for revision > > is not a negative judgement; on the contrary it might connote "we > > absolutely love this proposal but we want it to be clear on these > > points". > > > > In fact, this should happen if any substantive technical debate takes > > place. The goal of the committee review is to say yes/no to a proposal > > as it stands. > > > With apologies for causing controversy, > > Adam > > >>> On 15 Dec 2022, at 08:14, Simon Peyton Jones > wrote: >>> >>> I recommend acceptance as-is. >>> >>> I see no difficulty with the namespace part of the proposal. Yes, the /existing /namespace extension is ill specified. But this proposal does not make that situation worse (the delta is clearly specified), and it seems unfair of us to penalise this proposal because of the pre-existing situation. >>> >>> Of course, it would be better still to have a new, subsequent proposal that clarifies the ExplicitNameSpaceProposal. Perhaps we could invite Artyom write it, as a favour to the community. Or perhaps a member of the committee might like to. >>> >>> Simon >>> >>> On Thu, 15 Dec 2022 at 00:55, Chris Dornan > wrote: >>> >>> For reasons I have made entirely clear I _strongly_ desire this >>> split — are you offering to take over shepherding this proposal >>> Richard? Because I am now totally stymied and unable to manage the >>> process. >>> >>>> On 15 Dec 2022, at 00:47, Richard Eisenberg >>> > wrote: >>>> >>>> I strongly oppose requesting that the proposal be split. I agree >>>> that the two parts of the proposal can notionally be separated. >>>> But sometimes I feel that, in the face of difficult decisions, >>>> this committee has punted by requesting formatting changes of >>>> proposals. My case in point is around #448 about scoped type >>>> variables. That proposal arose out of a smattering of other >>>> proposals... but the committee deemed that the other proposals >>>> were too separate and needed to be considered as a whole. So, >>>> with some effort, I put them all in one. Then members of the >>>> committee said that the proposal was too big and to break it up! >>>> I refused, and had to hold my ground despite several requests. In >>>> the end, half was accepted, and at that point I took the other >>>> half and re-proposed it. I actually don't mind that last part -- >>>> I think partial acceptance is a reasonable action. But the >>>> formatting and reformatting is quite a bit of work, and I'm not >>>> convinced it really helped our debate. I'm worried we're >>>> repeating this here. >>>> >>>> Richard >>>> >>>>> On Dec 13, 2022, at 10:50 AM, Chris Dornan >>>>> > wrote: >>>>> >>>>> Although the two aspects of the proposal were motivated by the >>>>> same problem they are doing completely different things. As long >>>>> as it was easier to deal with them together the path of least >>>>> resistance was to keep them bundled up, but it is becoming ever >>>>> clearer that they are tied up in divergent organisational as >>>>> well as technical concerns. The warnings are well understood and >>>>> ready to go with a patch whereas, as this thread illustrates, >>>>> nobody seems to properly understand what is going on with >>>>> ExplicitNameSpaces; we are still confident that we can sort it >>>>> all out and confident that we want to sort it all out but still >>>>> there is work to be done. >>>>> >>>>> Added to this there is the fact that the problems with >>>>> namespaces are entirely inherited from an existing extension >>>>> that is poorly documented and, as we have just discovered, >>>>> poorly understood. For all the reasons explained in the proposal >>>>> we are likely to be leaning more heavily on >>>>> ExplicitNameSpaces as we develop DH so we really need sort out >>>>> what it does and get it written down. Here is the kicker — when >>>>> we do sort out ExplicitNameSpaces and write it up properly we >>>>> are going to want it attached to language extension dedicated to >>>>> managing ExplicitNameSpaces, not an extension bundled up with >>>>> some enabled warnings. >>>>> >>>>> I am happy to work with Artyom to get the new proposal set up etc. >>>>> >>>>> Chris >>>>> >>>>> >>>>>> On 13 Dec 2022, at 09:01, Simon Peyton Jones >>>>>> >>>>> > wrote: >>>>>> >>>>>> I still don't get the "split in two" thing. The proposal is >>>>>> quite clear about the delta to ExplicitNameSpaces. The fact >>>>>> that the latter is not well specified isn't the current >>>>>> author's fault; and the delta makes sense as part of this proposal. >>>>>> >>>>>> I think we should accept this one, and politely ask the author >>>>>> if they would consider (as a favour) writing a delta to the >>>>>> ExplicitNameSpaces proposal (I assume there is one?) to clarify it. >>>>>> >>>>>> Simon >>>>>> >>>>>> On Mon, 12 Dec 2022 at 22:05, Chris Dornan >>>>>> > wrote: >>>>>> >>>>>> In this case, for sure, responsibility for fixing up >>>>>> namespace documentation should not fall on the author of >>>>>> this proposal. I am thinking more that they should be >>>>>> strongly encouraged to submit the follow-up proposal and we >>>>>> provide or identify whatever assistance necessary to get >>>>>> the job done. It will definitely get us to a better place >>>>>> in my view. >>>>>> >>>>>> It sounds like we are in strong agreement. >>>>>> >>>>>> Chris >>>>>> >>>>>> >>>>>> >>>>>> > On 12 Dec 2022, at 20:11, Adam Gundry >>>>>> > wrote: >>>>>> > >>>>>> > On 12/12/2022 16:50, Chris Dornan wrote: >>>>>> >> I really think we should split this proposal into two, >>>>>> one to deal with warnings and the other to deal with >>>>>> namespaces. The warnings look to me ready to go. >>>>>> >> I am further thinking that we should really welcome the >>>>>> followup namespace proposal as an opportunity to clarify >>>>>> and properly document namespaces. >>>>>> >> I am sorry, I was added to the proposal very late >>>>>> thinking it was technically sound but I am realising it is >>>>>> far from the case. >>>>>> >> Finally, I am quite surprised at how little >>>>>> documentation there seems to be on ExplicitNamespaces. >>>>>> Should we be asking that revised documentation be propared >>>>>> as part of the proposal process and that the documentation >>>>>> be up to scratch? It seems the least we should be asking >>>>>> and much more important than requiring an implementation >>>>>> plan. This process is increasingly the only game in town >>>>>> when it comes to driving forward and defining Haskell and >>>>>> we need to make sure stuff is being written down properly. >>>>>> > >>>>>> > This is a bit of a tricky issue, I think. I agree that we >>>>>> should strive for a proper specification of >>>>>> ExplicitNamespaces. The current state seems to be sadly >>>>>> lacking, especially if we want ExplicitNamespaces to be in >>>>>> GHC2023. That said, there's a risk that proposal authors >>>>>> will be discouraged if proposing changes entails writing >>>>>> specifications for existing under-specified features! >>>>>> > >>>>>> > I wonder if anyone has attempted to extend "A Formal >>>>>> Specification of the Haskell 98 Module System" to more >>>>>> recent GHC extensions? >>>>>> > >>>>>> > Adam >>>>>> > >>>>>> > >>>>>> >>> On 12 Dec 2022, at 12:21, Adam Gundry >>>>>> >>>>>> >> >>>>>> wrote: >>>>>> >>> >>>>>> >>> On 12/12/2022 11:39, Simon Peyton Jones wrote: >>>>>> >>>> {-# LANGUAGE ExplicitNamespaces #-} >>>>>> >>>> module N where >>>>>> >>>> import M (T(type MkT)) -- NB "type" import of >>>>>> a data constructor >>>>>> >>>> v = MkT -- usage at term level >>>>>> Crumbs. I had not realised the proposal is to allow >>>>>> *nested* uses of 'type' in import lists, as you show above. >>>>>> >>> >>>>>> >>> The nested use is already possible with >>>>>> ExplicitNamespaces. Currently it allows >>>>>> >>> >>>>>> >>> import M (T(type MkT)) >>>>>> >>> import M (type MkT) >>>>>> >>> import M (pattern MkT) >>>>>> >>> >>>>>> >>> whereas the proposal extends it to add the possibility >>>>>> to write >>>>>> >>> >>>>>> >>> import M type (MkT) >>>>>> >>> import M data (MkT) >>>>>> >>> import M (data MkT) >>>>>> >>> >>>>>> >>> >>>>>> >>>> In general, I don't feel the extensions to >>>>>> ExplicitNamespaces included >>>>>> >>>> in the proposal are very clearly specified. >>>>>> Actually isn't the proposal pretty clear on this, namely >>>>>> the first bullet of proposed change spec >>>>>> >>. It only covers >>>>>> >>>> import M *type * >>>>>> >>>> import M *data *as MD >>>>>> >>>> where I have emboldened the new bits. Nothing about >>>>>> the contents of import lists. Why did you think your >>>>>> example is covered by the proposal? >>>>>> >>> >>>>>> >>> I'm trying to understand what >>>>>> >>> >>>>>> >>> import M type (MkT) >>>>>> >>> >>>>>> >>> means where MkT is a data constructor (or if it raises >>>>>> some kind of error). This was by analogy to the existing >>>>>> >>> >>>>>> >>> import M (T(type MkT)) >>>>>> >>> >>>>>> >>> which means something today, albeit not necessarily a >>>>>> very sensible thing (per >>>>>> https://gitlab.haskell.org/ghc/ghc/-/issues/22581 >>>>>> >>>>>> >>>>> >). >>>>>> >>> >>>>>> >>> I don't see a clear specification of the proposed >>>>>> (extended) semantics of ExplicitNamespaces in the proposal, >>>>>> but perhaps I've missed something? >>>>>> >>> >>>>>> >>> Cheers, >>>>>> >>> >>>>>> >>> Adam >>>>>> >>> >>>>>> >>> >>>>>> >>>> On Mon, 12 Dec 2022 at 09:15, Adam Gundry >>>>>> >>>>>> > >>>>>> >>>>>> >>> >>>>>> wrote: >>>>>> >>>> Actually, reading >>>>>> https://gitlab.haskell.org/ghc/ghc/-/issues/22581 >>>>>> >>>>>> >>>>> > >>>>>> >>>> >>>>> >>>>>> >>>>> >> I >>>>>> >>>> realised I'm unclear how the proposed extensions to >>>>>> ExplicitNamespaces >>>>>> >>>> are supposed to work. The existing situation is >>>>>> apparently that for a >>>>>> >>>> (non-punned) data constructor, it is possible to >>>>>> use either a >>>>>> >>>> pattern or >>>>>> >>>> type qualifier in an import list (presumably >>>>>> because DataKinds means >>>>>> >>>> the >>>>>> >>>> constructor is in scope at both the term and type >>>>>> levels), and the >>>>>> >>>> imported constructor is then usable in both contexts. >>>>>> >>>> For example, the following is accepted at present: >>>>>> >>>> module M where >>>>>> >>>> data T = MkT >>>>>> >>>> {-# LANGUAGE ExplicitNamespaces #-} >>>>>> >>>> module N where >>>>>> >>>> import M (T(type MkT)) -- NB "type" import of >>>>>> a data constructor >>>>>> >>>> v = MkT -- usage at term level >>>>>> >>>> The present proposal says "With type specified in >>>>>> the import, only >>>>>> >>>> identifiers belonging to the type namespace will be >>>>>> brought into the >>>>>> >>>> scope." I'm not exactly sure how to interpret this, >>>>>> does it mean the >>>>>> >>>> following alternative will be accepted or rejected? >>>>>> >>>> module N where >>>>>> >>>> import M type (MkT) >>>>>> >>>> v = MkT >>>>>> >>>> I'm worried we will end up with a situation where >>>>>> ExplicitNamespaces >>>>>> >>>> does subtly different things depending on the >>>>>> position of the keyword. >>>>>> >>>> In general, I don't feel the extensions to >>>>>> ExplicitNamespaces included >>>>>> >>>> in the proposal are very clearly specified. Given >>>>>> the discussion about >>>>>> >>>> exactly which parts belong to >>>>>> ExplicitNamespaces/PatternSynonyms versus >>>>>> >>>> separate extensions, perhaps we should accept the >>>>>> parts relating to >>>>>> >>>> -Wpuns/-Wpun-bindings, but ask for the >>>>>> ExplicitNamespaces changes to be >>>>>> >>>> proposed separately? >>>>>> >>>> Cheers, >>>>>> >>>> Adam >>>>>> >>>> On 09/12/2022 11:11, Adam Gundry wrote: >>>>>> >>>> > I'm broadly in favour of accepting the proposal. >>>>>> I realise the >>>>>> >>>> history >>>>>> >>>> > is complex here, so I don't think we should ask >>>>>> anyone to rewrite >>>>>> >>>> things >>>>>> >>>> > further, though in general it would be nicer to >>>>>> have separate >>>>>> >>>> proposals >>>>>> >>>> > for -Wpuns/-Wpun-bindings (which is >>>>>> unambiguously fine) and for the >>>>>> >>>> > changes to imports (which as Joachim points out >>>>>> raise issues). >>>>>> >>>> > >>>>>> >>>> > I'm a bit concerned that the proposal does not >>>>>> motivate or specify >>>>>> >>>> > -Wpattern-namespace-qualified very well. >>>>>> >>>> > >>>>>> >>>> > >>>>>> >>>> > On 08/12/2022 08:33, Joachim Breitner wrote: >>>>>> >>>> >> ... >>>>>> >>>> >> >>>>>> >>>> >> This gives us (at least) these options: >>>>>> >>>> >> >>>>>> >>>> >> 1. Leave ExplicitNamespaces alone, add >>>>>> ExplicitNamespaces to >>>>>> >>>> GHC2023, >>>>>> >>>> >> introduce one or two new extensions for the >>>>>> newer changes. >>>>>> >>>> >> 2. Extend ExplicitNamespaces, and don’t add it >>>>>> already to GHC2023, >>>>>> >>>> >> disregarding issue #551. >>>>>> >>>> >> 3. Add ExplicitNamespaces to GHC2023, and still >>>>>> add it to GHC2023, >>>>>> >>>> >> arguing that GHC20xx allows more liberal >>>>>> (backward-compatibile) >>>>>> >>>> >> changes than, say, Haskell2010 would allow. >>>>>> >>>> >> >>>>>> >>>> >> Certainly 1 is the least bold move. I am not >>>>>> sure what the best way >>>>>> >>>> >> forwards is, and welcome other opinions. >>>>>> >>>> > >>>>>> >>>> > I would prefer a variant of 1: allow "data" as a >>>>>> keyword in >>>>>> >>>> import lists >>>>>> >>>> > under ExplicitNamespaces, but make the other >>>>>> changes under other >>>>>> >>>> > extensions. >>>>>> >>>> > >>>>>> >>>> > As I've said previously, I have a general >>>>>> preference for multiple >>>>>> >>>> small, >>>>>> >>>> > orthogonal extensions rather than changing >>>>>> existing extensions to >>>>>> >>>> add >>>>>> >>>> > unrelated features that happen to be in similar >>>>>> territory. I realise >>>>>> >>>> > this is controversial, of course. >>>>>> >>>> > >>>>>> >>>> > Cheers, >>>>>> >>>> > >>>>>> >>>> > Adam > > > -- > Adam Gundry, Haskell Consultant > Well-Typed LLP, https://www.well-typed.com/ > > Registered in England & Wales, OC335890 > 27 Old Gloucester Street, London WC1N 3AX, England > > _______________________________________________ > ghc-steering-committee mailing list > ghc-steering-committee at haskell.org > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee -------------- next part -------------- An HTML attachment was scrubbed... URL: From arnaud.spiwack at tweag.io Fri Dec 16 14:54:22 2022 From: arnaud.spiwack at tweag.io (Arnaud Spiwack) Date: Fri, 16 Dec 2022 15:54:22 +0100 Subject: [ghc-steering-committee] Modifiers (Was: #512: NoFieldSelectors as datatype annotation) In-Reply-To: References: <494656e83f8d1486621fab153ed8f85f13b82e1b.camel@joachim-breitner.de> <414422bd-7085-f244-626a-19711dfd0692@well-typed.com> <02620ae95fb4d0a07172c06ffa83281d293e4149.camel@joachim-breitner.de> <451cf30d-8fc6-a052-0c3d-707b5f7fbc92@well-typed.com> <9484dee9-2d77-98ae-5b4d-ebc51f19cb24@well-typed.com> <13a361fc9689b0da5352085f4eab397d800af022.camel@joachim-breitner.de> <010f01851335159c-3a5c2057-9560-4a8c-bb45-1bec9a193786-000000@us-east-2.amazonses.com> <484c0bbb4e295d68c07365eec521ddc643ac184f.camel@joachim-breitner.de> Message-ID: To be frank, my initial reaction to the modifiers proposal was not dissimilar to Joachim's. But I mellowed up to the type-based approach because of things like linear types (which need to be type-level values) and matchability (which also needs to for inference). As I understand it, adding arguments to the functional arrow (and, correspondingly, to binders) was one of the prime motivations for the design of modifiers. And as long as you annotate within expression, it seems to be a pretty reasonable design. Where maybe the proposal is overly enthusiastic (and I say “maybe” quite honestly: I don't really have an opinion) is to apply type-based modifiers to whole declarations (overlappable instance, or deactivating warnings), where the benefits of types are less clear, and we run into situation like Joachim's pointing out where we want to change the behaviour of the renamer. We may very well want to treat the definition granularity and the expression granularity very differently. In the prior art in this space, there are also Rust's attributes, which are at the definition granularity (they are essentially just strings). On Thu, 15 Dec 2022 at 13:04, Simon Peyton Jones < simon.peytonjones at gmail.com> wrote: > Hmm. > > - We have an accepted proposal for modifiers. > - As of today we have a willing implementer, Georgi: > https://gitlab.haskell.org/ghc/ghc/-/issues/22624 > > And yet some doubt is being expressed in this thread about whether the > accepted proposal is the one we really want. > > @rae Georgi says you are going to mentor him. Do you feel able to help us > converge on a design we are all content with; quite possibly just > reaffirming the current accepted proposal? > > Simon > > > > On Thu, 15 Dec 2022 at 09:43, Joachim Breitner > wrote: > >> Hi Richard, >> >> thanks, comparing Modifiers to the annotations and attributes in other >> languages indeed puts this into a perspective that makes more sense to >> me. It seems I have assumed a broader scope for modifiers (maybe >> because “modify” sounds much stronger than “annotate” or >> “attribut…ize”). So I conclude the goal is not to necessarily to remove >> _all_ kind of pragmas, but only maybe those that fit the pattern (e.g. >> don’t affect parsing and renaming). Is that right? >> >> So my straw man “could qualified imports be modifiers” is simply out of >> scope (heh). >> >> Especially the potential use case for plugins (which do benefit from an >> extensible, namespaced scheme that does not require changes to parsing) >> – essentially a variant of the ANN pragma – is convincing. >> >> Turning back to NoFieldSelectors, however, I notice that >> NoFieldSelectors _does_ affect renaming already, because it affects >> whether a symbol with the field’s name is in scope (which, in >> particular, has further effects with implicit binders etc…), doesn't >> it? So would modifiers, if we had them, even work here? >> >> >> Cheers, >> Joachim >> -- >> Joachim Breitner >> mail at joachim-breitner.de >> http://www.joachim-breitner.de/ >> >> _______________________________________________ >> 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 lists at richarde.dev Sun Dec 18 03:54:11 2022 From: lists at richarde.dev (Richard Eisenberg) Date: Sun, 18 Dec 2022 03:54:11 +0000 Subject: [ghc-steering-committee] Why not?, rather than, why? In-Reply-To: References: <10594AD6-665D-4674-8E96-78AB6C61973A@chrisdornan.com> <6D754A68-7BC5-48AF-A6A8-B307D9FD02EB@chrisdornan.com> <010f0184f74380f9-b587b4d5-59af-4f09-8efe-4ad1745243ce-000000@us-east-2.amazonses.com> Message-ID: <010f0185235e2a41-63ee350a-34b0-408f-8871-f3ecfc18eccd-000000@us-east-2.amazonses.com> > On Dec 14, 2022, at 6:05 AM, Simon Marlow wrote: > > It's clear that CPP needs to remain as a flag because it does bad things to the syntax like breaking multiline strings and doing strange things to `##`. But it's less clear to me that TemplateHaskell is in this category. Isn't it just an extension that enables new syntax? Yes there are *practical* reasons why we might not want it on by default, because it makes compilation slower and whatnot, but isn't that all it is? I somehow missed this, and more surprisingly just now found it. TemplateHaskell isn't just for new syntax primarily because it has important interactions around cross-compilation. If/when GHC has a comprehensive story around cross-compilation, TH will change the way the pipeline works. It was this concern that suggested it should be lumped with CPP. (TemplateHaskellQuotes are a different story -- that's just syntax.) Richard -------------- next part -------------- An HTML attachment was scrubbed... URL: From mail at joachim-breitner.de Wed Dec 21 12:19:56 2022 From: mail at joachim-breitner.de (Joachim Breitner) Date: Wed, 21 Dec 2022 13:19:56 +0100 Subject: [ghc-steering-committee] #541: WARNING pragma with category, Recommendation: accept In-Reply-To: <8e8c16f13f955cda49a895fbc8378541db3fdc82.camel@joachim-breitner.de> References: <96101967a640825f61e52c2aae6c29dd5186f3ff.camel@joachim-breitner.de> <010f01849a416c75-213361ee-7955-487e-a782-cda06d19b1dd-000000@us-east-2.amazonses.com> <68516f416714774cf430daf762a2f0b616b6230b.camel@joachim-breitner.de> <8e8c16f13f955cda49a895fbc8378541db3fdc82.camel@joachim-breitner.de> Message-ID: <82fc50e2f816dbac245284209dec69bd514bdd39.camel@joachim-breitner.de> Hi, Am Freitag, dem 09.12.2022 um 19:31 +0100 schrieb Joachim Breitner: > Am Dienstag, dem 29.11.2022 um 17:14 +0100 schrieb Joachim Breitner: > > Happy to hear more voices and accept with whatever the majority of > > voices said they’d prefer (without formal votes, doesn’t seem to be > > worth it), assuming nobody thinks either way is a showstopper. > > didn’t hear more on this issue. If silence continues for a few more > days, I’ll accept it (in the current variant ({-# WARNING [x-partial] > #-}), by popular vote). accepted and merged! Cheers, Joachim -- Joachim Breitner mail at joachim-breitner.de http://www.joachim-breitner.de/ From lists at richarde.dev Wed Dec 21 13:12:39 2022 From: lists at richarde.dev (Richard Eisenberg) Date: Wed, 21 Dec 2022 13:12:39 +0000 Subject: [ghc-steering-committee] Modifiers (Was: #512: NoFieldSelectors as datatype annotation) In-Reply-To: References: <494656e83f8d1486621fab153ed8f85f13b82e1b.camel@joachim-breitner.de> <414422bd-7085-f244-626a-19711dfd0692@well-typed.com> <02620ae95fb4d0a07172c06ffa83281d293e4149.camel@joachim-breitner.de> <451cf30d-8fc6-a052-0c3d-707b5f7fbc92@well-typed.com> <9484dee9-2d77-98ae-5b4d-ebc51f19cb24@well-typed.com> <13a361fc9689b0da5352085f4eab397d800af022.camel@joachim-breitner.de> <010f01851335159c-3a5c2057-9560-4a8c-bb45-1bec9a193786-000000@us-east-2.amazonses.com> <484c0bbb4e295d68c07365eec521ddc643ac184f.camel@joachim-breitner.de> Message-ID: <010f018534d0889e-1e444dc5-818f-45ee-86a9-ff3a07cbdb6b-000000@us-east-2.amazonses.com> Some collected thoughts on modifiers (which I have spent quite a bit of time mulling on over the past week): - Yes, the current design struggles with changes affecting early stages. - Modifiers affecting renaming are not entirely impossible though; they're just different. Normal, type-based modifiers allow the full expressiveness of the type system, including import/export, synonyms, and even computation via type families. However, even during renaming, we have identifiers with original names (that is, we can know the actual module where an identifier was initially declared, ignoring re-exports). So we could say that, in `%NoFieldSelectors data Rec = MkRec { field :: Int }`, NoFieldSelectors must be the actual modifier, not via any type synonym. That's unfortunate, but it's far from impossible. - The key part of the design, for me, is uniform syntax. We use % to introduce a modifier. And it appears before the thing modified. Other aspects are nice-to-have, and so I decided to piggy-back on our expressive types to allow for some abstraction. - One possibility is to have % introduce type-based modifiers, using some other symbol (possibly %%) to introduce string-y modifiers. Or we could say that e.g. %(of blah) is string-y -- note that it begins with a keyword. Regardless of these design aspects, I think the initial roll-out can proceed, and then we can embellish as we learn from experience. Richard > On Dec 16, 2022, at 9:54 AM, Arnaud Spiwack wrote: > > To be frank, my initial reaction to the modifiers proposal was not dissimilar to Joachim's. But I mellowed up to the type-based approach because of things like linear types (which need to be type-level values) and matchability (which also needs to for inference). As I understand it, adding arguments to the functional arrow (and, correspondingly, to binders) was one of the prime motivations for the design of modifiers. And as long as you annotate within expression, it seems to be a pretty reasonable design. Where maybe the proposal is overly enthusiastic (and I say “maybe” quite honestly: I don't really have an opinion) is to apply type-based modifiers to whole declarations (overlappable instance, or deactivating warnings), where the benefits of types are less clear, and we run into situation like Joachim's pointing out where we want to change the behaviour of the renamer. We may very well want to treat the definition granularity and the expression granularity very differently. > > In the prior art in this space, there are also Rust's attributes, which are at the definition granularity (they are essentially just strings). > > On Thu, 15 Dec 2022 at 13:04, Simon Peyton Jones > wrote: > Hmm. > We have an accepted proposal for modifiers. > As of today we have a willing implementer, Georgi: https://gitlab.haskell.org/ghc/ghc/-/issues/22624 > And yet some doubt is being expressed in this thread about whether the accepted proposal is the one we really want. > > @rae Georgi says you are going to mentor him. Do you feel able to help us converge on a design we are all content with; quite possibly just reaffirming the current accepted proposal? > > Simon > > > > On Thu, 15 Dec 2022 at 09:43, Joachim Breitner > wrote: > Hi Richard, > > thanks, comparing Modifiers to the annotations and attributes in other > languages indeed puts this into a perspective that makes more sense to > me. It seems I have assumed a broader scope for modifiers (maybe > because “modify” sounds much stronger than “annotate” or > “attribut…ize”). So I conclude the goal is not to necessarily to remove > _all_ kind of pragmas, but only maybe those that fit the pattern (e.g. > don’t affect parsing and renaming). Is that right? > > So my straw man “could qualified imports be modifiers” is simply out of > scope (heh). > > Especially the potential use case for plugins (which do benefit from an > extensible, namespaced scheme that does not require changes to parsing) > – essentially a variant of the ANN pragma – is convincing. > > Turning back to NoFieldSelectors, however, I notice that > NoFieldSelectors _does_ affect renaming already, because it affects > whether a symbol with the field’s name is in scope (which, in > particular, has further effects with implicit binders etc…), doesn't > it? So would modifiers, if we had them, even work here? > > > Cheers, > Joachim > -- > Joachim Breitner > mail at joachim-breitner.de > http://www.joachim-breitner.de/ > > _______________________________________________ > 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.peytonjones at gmail.com Wed Dec 21 15:44:33 2022 From: simon.peytonjones at gmail.com (Simon Peyton Jones) Date: Wed, 21 Dec 2022 15:44:33 +0000 Subject: [ghc-steering-committee] Proposal #532: Clean up and simplify the treatment of implicit bindings. Recommendation: partially accept (maybe) In-Reply-To: References: Message-ID: > > The new Explicit Binding Principle is now somewhat stronger, in that it > requires that there is a form with an explicit binder which “regardless of > the context, is unambiguously a binding site”. The Lexical Binding > Principle is changed, as well, to refer to this new change but it's not > substantial. > > I personally don't think this change to the principles is valuable, it > simply blurs the distinction between the Explicit Binding Principle and the > Lexical Binding Principle. > I don't get this. Why is the EBP stronger? Example? I don't see why the distinction is blurred. The changes to the principles seem fine to me -- modest but useful clarifications, no change in semantics. I don't think I fully understand the second part about flags etc. My head spins. I wish there was a compact summary of the actual changes proposed. I'll ask John for that. Simon On Wed, 14 Dec 2022 at 07:09, Arnaud Spiwack wrote: > Dear all, > > Proposal https://github.com/ghc-proposals/ghc-proposals/pull/532 > Rendered link for the proposal (although several other files are > modified): > https://github.com/Ericson2314/ghc-proposals/blob/type-variables/proposals/0532-type-variable-scoping.rst > > John Ericson proposes to amend Richard's recent Modern Scoped Type > Variables Proposal [ > https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0448-type-variable-scoping.rst > ] > > There are two essential parts to the change: > 1. The Explicit Binding Principle is modified > 2. Change the two extensions introduced by Proposal #285 [ > https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0285-no-implicit-binds.rst > ], -XImplicitForalls and -XPatternSignatureBinds (so that they can be > deactivated), and consolidated in Richard's proposal (where > -XPatternSignatureBinds is turned into a binding) into a single > -XImplicitBinds extension > > --------- > > The new Explicit Binding Principle is now somewhat stronger, in that it > requires that there is a form with an explicit binder which “regardless of > the context, is unambiguously a binding site”. The Lexical Binding > Principle is changed, as well, to refer to this new change but it's not > substantial. > > I personally don't think this change to the principles is valuable, it > simply blurs the distinction between the Explicit Binding Principle and the > Lexical Binding Principle. I find the current phrasing more useful. And I > don't think the semantics of the conjunction is actually changed. So I > recommend that we reject the changes to the Principles. > > ------------ > > John makes a good point: `-XPatternSignature` being a warning has a > limitation. This is pointed out in section “Unified Namespacing and > extension monotonicity” of the patch to the Modern Scoped Type Variables > Proposal. Namely that in > > t = Int > (x :: t) = 0 > > The current semantics is to have `t` be a binder (because `t` is not bound > in the type namespace). If we add a warning for pattern signatures binders, > `t` will still be a binder. But we are starting to introduce a new > semantics where failing to lookup `t` in the type namespace, we will fall > back to look it up in the term namespace instead. The current semantics of > considering `t` a binder in this case is at odds with the fallback > strategy. (crucially for this recommendation, the same issue occurs in > signatures where `forall`-s are implicitly inferred) > > (Context: At the time where #285 was proposed, I was in favour of a single > extension. Simon PJ strongly pushed for two extensions.) > > My inclination today is that we have a choice: we can either > - consider the problem above to be a serious issue, in which case we > probably want to eventually deprecate both implicit foralls and pattern > signature binds. If this is the case, then they should be gated behind an > extension (see also the discussion on the meaning of extensions that we're > currently having). I find it healthy to have a single extension for both > features because the problem that the extension is solving is the same, > hence, in this case, I recommend accepting the changes. > - be happy that the semantics is a little quirky, with the fallback > happening only when an explicit forall is specified (and never in pattern > signatures). In which case both should probably be warnings, it makes sense > for the warnings to be separate categories as these are two different > features. In this case I recommend rejection of the proposed changes. > > ------------ > > I realise I'm leaving a big choice hanging. It's a big decision, I think, > which we should weigh carefully (which is kind of funny because the > proposed change itself is rather small). > > Personally, I'd be happy with all implicit foralls and pattern signature > binds to be deprecated (so I'm actually taking a position I guess). But I'm > not sure that it's super realistic considering the quantity of Haskell that > has been written so far. I imagine that there are millions of implicit > foralls on Hackage. > > PS: I'll be on holiday for the next three weeks (starting on Friday > night), so you'll have a little while to debate this while I'm away. > _______________________________________________ > 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 lists at richarde.dev Thu Dec 22 13:45:48 2022 From: lists at richarde.dev (Richard Eisenberg) Date: Thu, 22 Dec 2022 13:45:48 +0000 Subject: [ghc-steering-committee] Modifiers (Was: #512: NoFieldSelectors as datatype annotation) In-Reply-To: <010f018534d0889e-1e444dc5-818f-45ee-86a9-ff3a07cbdb6b-000000@us-east-2.amazonses.com> References: <494656e83f8d1486621fab153ed8f85f13b82e1b.camel@joachim-breitner.de> <414422bd-7085-f244-626a-19711dfd0692@well-typed.com> <02620ae95fb4d0a07172c06ffa83281d293e4149.camel@joachim-breitner.de> <451cf30d-8fc6-a052-0c3d-707b5f7fbc92@well-typed.com> <9484dee9-2d77-98ae-5b4d-ebc51f19cb24@well-typed.com> <13a361fc9689b0da5352085f4eab397d800af022.camel@joachim-breitner.de> <010f01851335159c-3a5c2057-9560-4a8c-bb45-1bec9a193786-000000@us-east-2.amazonses.com> <484c0bbb4e295d68c07365eec521ddc643ac184f.camel@joachim-breitner.de> <010f018534d0889e-1e444dc5-818f-45ee-86a9-ff3a07cbdb6b-000000@us-east-2.amazonses.com> Message-ID: <010f01853a153d0c-b9f8662e-1c76-499d-aeab-3107fd72e462-000000@us-east-2.amazonses.com> Georgi (the volunteer implementer) and I just had a nice chat about modifiers. See notes at https://gitlab.haskell.org/ghc/ghc/-/issues/22624#note_469566 Richard > On Dec 21, 2022, at 8:12 AM, Richard Eisenberg wrote: > > Some collected thoughts on modifiers (which I have spent quite a bit of time mulling on over the past week): > > - Yes, the current design struggles with changes affecting early stages. > > - Modifiers affecting renaming are not entirely impossible though; they're just different. Normal, type-based modifiers allow the full expressiveness of the type system, including import/export, synonyms, and even computation via type families. However, even during renaming, we have identifiers with original names (that is, we can know the actual module where an identifier was initially declared, ignoring re-exports). So we could say that, in `%NoFieldSelectors data Rec = MkRec { field :: Int }`, NoFieldSelectors must be the actual modifier, not via any type synonym. That's unfortunate, but it's far from impossible. > > - The key part of the design, for me, is uniform syntax. We use % to introduce a modifier. And it appears before the thing modified. Other aspects are nice-to-have, and so I decided to piggy-back on our expressive types to allow for some abstraction. > > - One possibility is to have % introduce type-based modifiers, using some other symbol (possibly %%) to introduce string-y modifiers. Or we could say that e.g. %(of blah) is string-y -- note that it begins with a keyword. > > Regardless of these design aspects, I think the initial roll-out can proceed, and then we can embellish as we learn from experience. > > Richard > >> On Dec 16, 2022, at 9:54 AM, Arnaud Spiwack > wrote: >> >> To be frank, my initial reaction to the modifiers proposal was not dissimilar to Joachim's. But I mellowed up to the type-based approach because of things like linear types (which need to be type-level values) and matchability (which also needs to for inference). As I understand it, adding arguments to the functional arrow (and, correspondingly, to binders) was one of the prime motivations for the design of modifiers. And as long as you annotate within expression, it seems to be a pretty reasonable design. Where maybe the proposal is overly enthusiastic (and I say “maybe” quite honestly: I don't really have an opinion) is to apply type-based modifiers to whole declarations (overlappable instance, or deactivating warnings), where the benefits of types are less clear, and we run into situation like Joachim's pointing out where we want to change the behaviour of the renamer. We may very well want to treat the definition granularity and the expression granularity very differently. >> >> In the prior art in this space, there are also Rust's attributes, which are at the definition granularity (they are essentially just strings). >> >> On Thu, 15 Dec 2022 at 13:04, Simon Peyton Jones > wrote: >> Hmm. >> We have an accepted proposal for modifiers. >> As of today we have a willing implementer, Georgi: https://gitlab.haskell.org/ghc/ghc/-/issues/22624 >> And yet some doubt is being expressed in this thread about whether the accepted proposal is the one we really want. >> >> @rae Georgi says you are going to mentor him. Do you feel able to help us converge on a design we are all content with; quite possibly just reaffirming the current accepted proposal? >> >> Simon >> >> >> >> On Thu, 15 Dec 2022 at 09:43, Joachim Breitner > wrote: >> Hi Richard, >> >> thanks, comparing Modifiers to the annotations and attributes in other >> languages indeed puts this into a perspective that makes more sense to >> me. It seems I have assumed a broader scope for modifiers (maybe >> because “modify” sounds much stronger than “annotate” or >> “attribut…ize”). So I conclude the goal is not to necessarily to remove >> _all_ kind of pragmas, but only maybe those that fit the pattern (e.g. >> don’t affect parsing and renaming). Is that right? >> >> So my straw man “could qualified imports be modifiers” is simply out of >> scope (heh). >> >> Especially the potential use case for plugins (which do benefit from an >> extensible, namespaced scheme that does not require changes to parsing) >> – essentially a variant of the ANN pragma – is convincing. >> >> Turning back to NoFieldSelectors, however, I notice that >> NoFieldSelectors _does_ affect renaming already, because it affects >> whether a symbol with the field’s name is in scope (which, in >> particular, has further effects with implicit binders etc…), doesn't >> it? So would modifiers, if we had them, even work here? >> >> >> Cheers, >> Joachim >> -- >> Joachim Breitner >> mail at joachim-breitner.de >> http://www.joachim-breitner.de/ >> >> _______________________________________________ >> 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 > > _______________________________________________ > 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: