From arnaud.spiwack at tweag.io Wed Jun 1 09:53:00 2022 From: arnaud.spiwack at tweag.io (Spiwack, Arnaud) Date: Wed, 1 Jun 2022 11:53:00 +0200 Subject: [ghc-steering-committee] Modern Scoped Type Variables #448: recommendation (mostly) accept In-Reply-To: References: <010f017ff5943161-0e13b9be-4338-4c43-b7b1-0b37350596a9-000000@us-east-2.amazonses.com> <010f017ff637ce47-49c9f372-360c-4aed-87b3-2f6a240d0d74-000000@us-east-2.amazonses.com> Message-ID: Dear all, I feel blocked here. I don't know how to make progress. Part of the goal of this proposal is to elicit debate, and so far it has failed to. Simon PJ says that the principles “bind us completely in future”. But I'd argue that we still advertise them as desirable. Things we want to get better at in the future. So a proposal saying “it makes GHC better at the Contiguous Scoping Principle” is well-justified enough. Is it what we want? That's the question. On Fri, Apr 22, 2022 at 8:37 AM Spiwack, Arnaud wrote: > Any other opinion? Only a few of us have participated in this thread: Tom, > Joachim, Vlad, Eric, Chris, and Baldur, I'd love to hear from you. Do these > principles make sense to you, or should they be rephrased? Do you agree > with all of them? > > On Mon, Apr 18, 2022 at 9:51 AM Simon Peyton Jones < > simon.peytonjones at gmail.com> wrote: > >> I'm OK with them provided we do not get into later discussions like "this >> proposal violates the X principle, so we should reject it". The principles >> doc says only "Proposals following these principles are more likely to be >> accepted" which is fine. I just don't want them to bind us completely in >> future. >> >> I agree that having the principles gives a us a language and framework >> for debate, and so is useful. >> >> Simon >> >> On Fri, 15 Apr 2022 at 15:01, Spiwack, Arnaud >> wrote: >> >>> Dear all, >>> >>> There has been no discussion of the principles so far. May I ask you >>> what you think of the principles introduced by the proposal (I recommend >>> reading the diff of `principles.rst` in raw form, the visual diff doesn't >>> seem to work properly for me). >>> >>> Here is what I said about them in my initial email >>> >>> The proposal adds new principles to the `principles.rst` files which >>>> inform the changes proposed, of these, I have the following comments: >>>> - The Visibility Orthogonality Principle doesn't seem to have a very >>>> clear definition. It may be a sign that it's not something that is so >>>> important >>>> - The Explicit Binding Principle says that we need to be able to >>>> enforce that all type variables have a binding site. I think it's a bit >>>> strong: I would like Haskell to let me write a binding site for every type >>>> variable, but not necessarily to error out when that doesn't happen. That >>>> being said, I'm happy with warnings to help me along the way, but I don't >>>> think that this Explicit Binding Principle should be phrased in a way that >>>> requires adding extensions to control this behaviour. >>>> - The Contiguous Scoping Principle, which states that a binder binds >>>> in one contiguous region sounds dubious to me. I don't see a particular >>>> reason for this to be. >>>> >>> >>> I think that the Explicit Binding Principle has implicitly been >>> discussed in the thread about warnings above. There are other principles >>> that Richard proposes, which I all find I agree with. >>> >>> Best, >>> Arnaud >>> >>> On Tue, Apr 5, 2022 at 3:43 PM Simon Marlow wrote: >>> >>>> That all sounds reasonable to me. I suggest: >>>> >>>> * Let's mention in the proposal that ExtendedForAllScope exists for >>>> legacy reasons and that we intend to recommend TypeAbstractions as the >>>> canonical way to bind type variables in the future (is that the right >>>> wording? we're not ready to actually recommend it yet?). >>>> * When this is implemented, let's have wording to the same effect in >>>> the manual. Someone writing new code would want to know which way is likely >>>> to be the more future-proof alternative. >>>> >>>> > Complicating this story is that some users (including me, at times) >>>> wish for GHC to do less for us: we would prefer not to have implicit >>>> foralls or to permit pattern-signature bindings. However, I suppose this >>>> desire could be accommodated by warnings and -Werror instead of language >>>> extensions. >>>> >>>> Definitely - warnings and/or HLint for stylistic choices is the right >>>> way to do it. >>>> >>>> Cheers >>>> Simon >>>> >>>> On Mon, 4 Apr 2022 at 21:15, Richard Eisenberg >>>> wrote: >>>> >>>>> Thanks for reminding us of that definition in our review criteria -- >>>>> it's helpful. >>>>> >>>>> I would say that every extension in this proposal fits the standard, >>>>> except for ExtendedForAllScope. That is, I would be happy for the following >>>>> extensions (as described in this proposal) to be part of a standard: >>>>> - PatternSignatures >>>>> - PatternSignatureBinds >>>>> - MethodTypeVariables (though John Ericson makes a comment on GitHub >>>>> which suggests that this, too, may want revision -- I'm not fully convinced >>>>> yet) >>>>> - ImplicitForAll >>>>> - TypeAbstractions >>>>> (and ExtendedLet, but that's not being debated at the moment) >>>>> >>>>> Complicating this story is that some users (including me, at times) >>>>> wish for GHC to do less for us: we would prefer not to have implicit >>>>> foralls or to permit pattern-signature bindings. However, I suppose this >>>>> desire could be accommodated by warnings and -Werror instead of language >>>>> extensions. >>>>> >>>>> That logic might suggest revisiting #285 (which introduced >>>>> NoImplicitForAll and NoPatternSignatureBinds), instead wishing for these to >>>>> become warnings, rather than language extensions. (NB: #285 is accepted, >>>>> but not implemented.) >>>>> >>>>> Regarding GHCXXXX: Yes, I think we would end up removing >>>>> ExtendedForAllScope from it -- or at least I would advocate for doing so. >>>>> Indeed, when we considered ScopedTypeVariables as a candidate for GHCXXXX, >>>>> I was worried about getting stuck with it, and I believe it was important >>>>> to me that we had the option to remove, later. >>>>> >>>>> Richard >>>>> >>>>> On Apr 4, 2022, at 3:38 PM, Simon Marlow wrote: >>>>> >>>>> On Mon, 4 Apr 2022 at 18:17, Richard Eisenberg >>>>> wrote: >>>>> >>>>>> Thanks for kicking off this conversation, Arnaud! >>>>>> >>>>>> To be clear in this thread: I'm fine delaying the discussion of >>>>>> section 6-8 until later. >>>>>> >>>>>> Arnaud brings up my new principles in his initial email. Do please >>>>>> consider these principles as part of the deliberations, as they will become >>>>>> principles that we, as a committee, will have adopted. >>>>>> >>>>>> About extensions: We, as a community and as a committee, have not >>>>>> come to terms with the two possible interpretations of extensions. I would >>>>>> like to say that, ideally, extensions are candidates for eventual >>>>>> inclusion. However, that is neither the current practice nor our trendline. >>>>>> Examples: >>>>>> - any flags included in Haskell98 (including, for example, >>>>>> MonomorphismRestriction). These are definitely settings that one can choose >>>>>> per module. If they were candidates for inclusion, they wouldn't exist >>>>>> (because they're already included!). >>>>>> - RebindableSyntax (though this is not one to mimic) >>>>>> - MagicHash. My interpretation is that this extension is meant to >>>>>> allow users to explicitly opt into low-level code. >>>>>> - Recently accepted #285 >>>>>> , which >>>>>> introduces two new -XNo... extensions (both also included in #448). >>>>>> As a practical matter, then, extensions are means of customization. >>>>>> We might imagine a debate where we try to change this, and then come up >>>>>> with a way to get from where we are to that changed future. >>>>>> >>>>> >>>>> I think we actually did come to some agreement on the interpretation >>>>> of extensions, it's in our review criteria under "does not create a >>>>> language fork": >>>>> https://github.com/ghc-proposals/ghc-proposals#review-criteria . Yes >>>>> there are plenty of extensions that don't fit this criteria, but they tend >>>>> to be either special-purpose extensions for things like low-level >>>>> programming, building DSLs, or for backwards compatibility, rather than >>>>> extensions we would expect people to routinely enable. >>>>> >>>>> Does that apply in this case? Well, perhaps the extensions are not >>>>> technically incompatible, but they're "at odds" as Arnaud puts it. >>>>> >>>>> Another way to frame the original question might be: which of these >>>>> extensions do we expect to include in GHC2023 (or GHC2024 or whatever it >>>>> ends up being)? GHC2021 already has ScopedTypeVariables. We did decide (if >>>>> I recall correctly) that we might remove things from future GHCXXXX sets, >>>>> so are we going to remove ExtendedForAllScope and add TypeAbstractions from >>>>> some future GHCXXXX, or just add TypeAbstractions? >>>>> >>>>> I'm not expressing a preference one way or the other, just that we >>>>> should decide where this is going. >>>>> >>>>> Cheers >>>>> Simon >>>>> >>>>> Very specifically answering Simon M's concern: I see >>>>>> ExtendedForAllScope as a dead end, yes. It's included as a way of >>>>>> supporting the gobs and gobs and gobs of code that use today's >>>>>> ScopedTypeVariables, but at t=∞, we should get rid of it. Note that an optional >>>>>> extra >>>>>> introduces >>>>>> a @(..) syntax that makes TypeAbstractions significantly less repetitive, >>>>>> and thus about as easy to use as ExtendedForAllScope (which, recall, >>>>>> requires an explicit forall where there might otherwise be none). >>>>>> >>>>>> Richard >>>>>> >>>>>> PS: I'm on holiday starting tomorrow and so may not respond for about >>>>>> two weeks. Back in action on the 15th, but expect a few days of digging out. >>>>>> _______________________________________________ >>>>>> 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 Jun 1 09:54:12 2022 From: arnaud.spiwack at tweag.io (Spiwack, Arnaud) Date: Wed, 1 Jun 2022 11:54:12 +0200 Subject: [ghc-steering-committee] Please review: #454 Custom type warnings In-Reply-To: References: <010f017e5569032d-97a2902a-b938-4137-b9a7-70a1ead09852-000000@us-east-2.amazonses.com> <53E9ABAB-B660-477A-83AE-9D3BD6B0FAB7@gmail.com> <010f017e55a3195b-b551e32d-6ee6-4a12-86f8-92d3a8085ade-000000@us-east-2.amazonses.com> Message-ID: Dear all, I think that the objections raised so far were very minor. And the proposal is well justified. It's not a big enough proposal that we should weigh our options carefully for too long. I propose we accept promptly. On Wed, Mar 30, 2022 at 10:20 AM Spiwack, Arnaud wrote: > I realise that I hadn't opined here. > > I'm in favour. > > On Thu, Jan 13, 2022 at 11:51 PM Richard Eisenberg > wrote: > >> That's a really good point. Do you want to raise it on the PR? >> >> Richard >> >> > On Jan 13, 2022, at 4:56 PM, Vladislav Zavialov (int-index) < >> vlad.z.4096 at gmail.com> wrote: >> > >> > Can we guarantee erasure? Is `Warning flag msg => t` the same >> operationally as just `t`? >> > >> > The proposal does not say that. And it’s not what I would’ve expected >> from a constraint. Yet it’s something I expect from a warning. >> > >> > I am not comfortable with a design where adding a custom warning, the >> purpose of which is to improve developer experience, comes at a cost of >> potential performance regression. >> > >> > This isn’t a trade off that users of GHC should be facing. >> > >> > - Vlad >> > >> >> On 14 Jan 2022, at 00:47, Richard Eisenberg >> wrote: >> >> >> >> I vote to accept. >> >> >> >> Thanks, >> >> Richard >> >> >> >>> On Jan 13, 2022, at 11:19 AM, Tom Harding >> wrote: >> >>> >> >>> Hi all, >> >>> >> >>> As Joachim noted, #454 is extracted from Adam’s previous efforts with >> the Unsatisfiable constraint proposal (which has since been accepted). In >> short, it covers an interface for custom warnings, and I can already think >> of plenty of ways I’d use it. I’d therefore like to recommend acceptance, >> and discuss any issues or changes. >> >>> >> >>> Thanks, >> >>> Tom >> >>> _______________________________________________ >> >>> 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 lists at richarde.dev Wed Jun 1 16:25:02 2022 From: lists at richarde.dev (Richard Eisenberg) Date: Wed, 1 Jun 2022 16:25:02 +0000 Subject: [ghc-steering-committee] Please review: #454 Custom type warnings In-Reply-To: References: <010f017e5569032d-97a2902a-b938-4137-b9a7-70a1ead09852-000000@us-east-2.amazonses.com> <53E9ABAB-B660-477A-83AE-9D3BD6B0FAB7@gmail.com> <010f017e55a3195b-b551e32d-6ee6-4a12-86f8-92d3a8085ade-000000@us-east-2.amazonses.com> Message-ID: <010f01812015b5a7-42a22e2a-2844-4f04-87b9-783804db366f-000000@us-east-2.amazonses.com> I'm in favor of acceptance. > On Jun 1, 2022, at 5:54 AM, Spiwack, Arnaud wrote: > > Dear all, > > I think that the objections raised so far were very minor. And the proposal is well justified. It's not a big enough proposal that we should weigh our options carefully for too long. I propose we accept promptly. > > On Wed, Mar 30, 2022 at 10:20 AM Spiwack, Arnaud > wrote: > I realise that I hadn't opined here. > > I'm in favour. > > On Thu, Jan 13, 2022 at 11:51 PM Richard Eisenberg > wrote: > That's a really good point. Do you want to raise it on the PR? > > Richard > > > On Jan 13, 2022, at 4:56 PM, Vladislav Zavialov (int-index) > wrote: > > > > Can we guarantee erasure? Is `Warning flag msg => t` the same operationally as just `t`? > > > > The proposal does not say that. And it’s not what I would’ve expected from a constraint. Yet it’s something I expect from a warning. > > > > I am not comfortable with a design where adding a custom warning, the purpose of which is to improve developer experience, comes at a cost of potential performance regression. > > > > This isn’t a trade off that users of GHC should be facing. > > > > - Vlad > > > >> On 14 Jan 2022, at 00:47, Richard Eisenberg > wrote: > >> > >> I vote to accept. > >> > >> Thanks, > >> Richard > >> > >>> On Jan 13, 2022, at 11:19 AM, Tom Harding > wrote: > >>> > >>> Hi all, > >>> > >>> As Joachim noted, #454 is extracted from Adam’s previous efforts with the Unsatisfiable constraint proposal (which has since been accepted). In short, it covers an interface for custom warnings, and I can already think of plenty of ways I’d use it. I’d therefore like to recommend acceptance, and discuss any issues or changes. > >>> > >>> Thanks, > >>> Tom > >>> _______________________________________________ > >>> 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 Jun 3 11:18:10 2022 From: simon.peytonjones at gmail.com (Simon Peyton Jones) Date: Fri, 3 Jun 2022 12:18:10 +0100 Subject: [ghc-steering-committee] Please review: #454 Custom type warnings In-Reply-To: References: Message-ID: I've added some technical comments. I'm not terribly enthusiastic (one more thing to implement and maintain) but neither am I against. I can see the attraction. Simon On Thu, 13 Jan 2022 at 16:19, Tom Harding wrote: > Hi all, > > As Joachim noted, #454 > is extracted > from Adam’s previous efforts with the Unsatisfiable constraint > proposal (which > has since been accepted). In short, it covers an interface for custom > warnings, and I can already think of plenty of ways I’d use it. I’d > therefore like to recommend acceptance, and discuss any issues or changes. > > Thanks, > Tom > _______________________________________________ > 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 Jun 6 08:35:31 2022 From: simon.peytonjones at gmail.com (Simon Peyton Jones) Date: Mon, 6 Jun 2022 09:35:31 +0100 Subject: [ghc-steering-committee] Modern Scoped Type Variables #448: recommendation (mostly) accept In-Reply-To: References: <010f017ff5943161-0e13b9be-4338-4c43-b7b1-0b37350596a9-000000@us-east-2.amazonses.com> <010f017ff637ce47-49c9f372-360c-4aed-87b3-2f6a240d0d74-000000@us-east-2.amazonses.com> Message-ID: I feel blocked here. I don't know how to make progress. Part of the goal of this proposal is to elicit debate, and so far it has failed to I think that: 1. Section 6-8 (about let in types etc) are controversial, and explicitly not under debate. *Action*:* @rae *would you like to remove them to another proposal? 2. The rest of the main proposal seems to have broad support, modulo some concerns about flags and forks. *Action: Tom, Joachim, Vlad, Eric, Chris, and Baldur*: please express an opinion. Can you do so this week please? You don't need to wait for (1); just ignore section 6-8. 3. The proposal *also *makes a significant diff to the principles.rst document , mostly expanding and clarifying points that were previously just a sentence or two. (Here's the old version .) *Action: Tom, Joachim, Vlad, Eric, Chris, and Baldur*: please express an opinion. 4. *Action @rae*: there has been some discussion about flags and forks. Would you like to make whatever resolution you think is appropriate, in the light of this conversation, and let us know what is? Let's get this over the line. I don't think there is any serious disagreement, and we have an obligation to authors to give their work our timely attention. Simon On Wed, 1 Jun 2022 at 10:53, Spiwack, Arnaud wrote: > Dear all, > > I feel blocked here. I don't know how to make progress. Part of the goal > of this proposal is to elicit debate, and so far it has failed to. > > Simon PJ says that the principles “bind us completely in future”. But I'd > argue that we still advertise them as desirable. Things we want to get > better at in the future. So a proposal saying “it makes GHC better at the Contiguous > Scoping Principle” is well-justified enough. Is it what we want? That's the > question. > > On Fri, Apr 22, 2022 at 8:37 AM Spiwack, Arnaud > wrote: > >> Any other opinion? Only a few of us have participated in this thread: >> Tom, Joachim, Vlad, Eric, Chris, and Baldur, I'd love to hear from you. Do >> these principles make sense to you, or should they be rephrased? Do you >> agree with all of them? >> >> On Mon, Apr 18, 2022 at 9:51 AM Simon Peyton Jones < >> simon.peytonjones at gmail.com> wrote: >> >>> I'm OK with them provided we do not get into later discussions like >>> "this proposal violates the X principle, so we should reject it". The >>> principles doc says only "Proposals following these principles are more >>> likely to be accepted" which is fine. I just don't want them to bind us >>> completely in future. >>> >>> I agree that having the principles gives a us a language and framework >>> for debate, and so is useful. >>> >>> Simon >>> >>> On Fri, 15 Apr 2022 at 15:01, Spiwack, Arnaud >>> wrote: >>> >>>> Dear all, >>>> >>>> There has been no discussion of the principles so far. May I ask you >>>> what you think of the principles introduced by the proposal (I recommend >>>> reading the diff of `principles.rst` in raw form, the visual diff doesn't >>>> seem to work properly for me). >>>> >>>> Here is what I said about them in my initial email >>>> >>>> The proposal adds new principles to the `principles.rst` files which >>>>> inform the changes proposed, of these, I have the following comments: >>>>> - The Visibility Orthogonality Principle doesn't seem to have a very >>>>> clear definition. It may be a sign that it's not something that is so >>>>> important >>>>> - The Explicit Binding Principle says that we need to be able to >>>>> enforce that all type variables have a binding site. I think it's a bit >>>>> strong: I would like Haskell to let me write a binding site for every type >>>>> variable, but not necessarily to error out when that doesn't happen. That >>>>> being said, I'm happy with warnings to help me along the way, but I don't >>>>> think that this Explicit Binding Principle should be phrased in a way that >>>>> requires adding extensions to control this behaviour. >>>>> - The Contiguous Scoping Principle, which states that a binder binds >>>>> in one contiguous region sounds dubious to me. I don't see a particular >>>>> reason for this to be. >>>>> >>>> >>>> I think that the Explicit Binding Principle has implicitly been >>>> discussed in the thread about warnings above. There are other principles >>>> that Richard proposes, which I all find I agree with. >>>> >>>> Best, >>>> Arnaud >>>> >>>> On Tue, Apr 5, 2022 at 3:43 PM Simon Marlow wrote: >>>> >>>>> That all sounds reasonable to me. I suggest: >>>>> >>>>> * Let's mention in the proposal that ExtendedForAllScope exists for >>>>> legacy reasons and that we intend to recommend TypeAbstractions as the >>>>> canonical way to bind type variables in the future (is that the right >>>>> wording? we're not ready to actually recommend it yet?). >>>>> * When this is implemented, let's have wording to the same effect in >>>>> the manual. Someone writing new code would want to know which way is likely >>>>> to be the more future-proof alternative. >>>>> >>>>> > Complicating this story is that some users (including me, at times) >>>>> wish for GHC to do less for us: we would prefer not to have implicit >>>>> foralls or to permit pattern-signature bindings. However, I suppose this >>>>> desire could be accommodated by warnings and -Werror instead of language >>>>> extensions. >>>>> >>>>> Definitely - warnings and/or HLint for stylistic choices is the right >>>>> way to do it. >>>>> >>>>> Cheers >>>>> Simon >>>>> >>>>> On Mon, 4 Apr 2022 at 21:15, Richard Eisenberg >>>>> wrote: >>>>> >>>>>> Thanks for reminding us of that definition in our review criteria -- >>>>>> it's helpful. >>>>>> >>>>>> I would say that every extension in this proposal fits the standard, >>>>>> except for ExtendedForAllScope. That is, I would be happy for the following >>>>>> extensions (as described in this proposal) to be part of a standard: >>>>>> - PatternSignatures >>>>>> - PatternSignatureBinds >>>>>> - MethodTypeVariables (though John Ericson makes a comment on GitHub >>>>>> which suggests that this, too, may want revision -- I'm not fully convinced >>>>>> yet) >>>>>> - ImplicitForAll >>>>>> - TypeAbstractions >>>>>> (and ExtendedLet, but that's not being debated at the moment) >>>>>> >>>>>> Complicating this story is that some users (including me, at times) >>>>>> wish for GHC to do less for us: we would prefer not to have implicit >>>>>> foralls or to permit pattern-signature bindings. However, I suppose this >>>>>> desire could be accommodated by warnings and -Werror instead of language >>>>>> extensions. >>>>>> >>>>>> That logic might suggest revisiting #285 (which introduced >>>>>> NoImplicitForAll and NoPatternSignatureBinds), instead wishing for these to >>>>>> become warnings, rather than language extensions. (NB: #285 is accepted, >>>>>> but not implemented.) >>>>>> >>>>>> Regarding GHCXXXX: Yes, I think we would end up removing >>>>>> ExtendedForAllScope from it -- or at least I would advocate for doing so. >>>>>> Indeed, when we considered ScopedTypeVariables as a candidate for GHCXXXX, >>>>>> I was worried about getting stuck with it, and I believe it was important >>>>>> to me that we had the option to remove, later. >>>>>> >>>>>> Richard >>>>>> >>>>>> On Apr 4, 2022, at 3:38 PM, Simon Marlow wrote: >>>>>> >>>>>> On Mon, 4 Apr 2022 at 18:17, Richard Eisenberg >>>>>> wrote: >>>>>> >>>>>>> Thanks for kicking off this conversation, Arnaud! >>>>>>> >>>>>>> To be clear in this thread: I'm fine delaying the discussion of >>>>>>> section 6-8 until later. >>>>>>> >>>>>>> Arnaud brings up my new principles in his initial email. Do please >>>>>>> consider these principles as part of the deliberations, as they will become >>>>>>> principles that we, as a committee, will have adopted. >>>>>>> >>>>>>> About extensions: We, as a community and as a committee, have not >>>>>>> come to terms with the two possible interpretations of extensions. I would >>>>>>> like to say that, ideally, extensions are candidates for eventual >>>>>>> inclusion. However, that is neither the current practice nor our trendline. >>>>>>> Examples: >>>>>>> - any flags included in Haskell98 (including, for example, >>>>>>> MonomorphismRestriction). These are definitely settings that one can choose >>>>>>> per module. If they were candidates for inclusion, they wouldn't exist >>>>>>> (because they're already included!). >>>>>>> - RebindableSyntax (though this is not one to mimic) >>>>>>> - MagicHash. My interpretation is that this extension is meant to >>>>>>> allow users to explicitly opt into low-level code. >>>>>>> - Recently accepted #285 >>>>>>> , which >>>>>>> introduces two new -XNo... extensions (both also included in #448). >>>>>>> As a practical matter, then, extensions are means of customization. >>>>>>> We might imagine a debate where we try to change this, and then come up >>>>>>> with a way to get from where we are to that changed future. >>>>>>> >>>>>> >>>>>> I think we actually did come to some agreement on the interpretation >>>>>> of extensions, it's in our review criteria under "does not create a >>>>>> language fork": >>>>>> https://github.com/ghc-proposals/ghc-proposals#review-criteria . Yes >>>>>> there are plenty of extensions that don't fit this criteria, but they tend >>>>>> to be either special-purpose extensions for things like low-level >>>>>> programming, building DSLs, or for backwards compatibility, rather than >>>>>> extensions we would expect people to routinely enable. >>>>>> >>>>>> Does that apply in this case? Well, perhaps the extensions are not >>>>>> technically incompatible, but they're "at odds" as Arnaud puts it. >>>>>> >>>>>> Another way to frame the original question might be: which of these >>>>>> extensions do we expect to include in GHC2023 (or GHC2024 or whatever it >>>>>> ends up being)? GHC2021 already has ScopedTypeVariables. We did decide (if >>>>>> I recall correctly) that we might remove things from future GHCXXXX sets, >>>>>> so are we going to remove ExtendedForAllScope and add TypeAbstractions from >>>>>> some future GHCXXXX, or just add TypeAbstractions? >>>>>> >>>>>> I'm not expressing a preference one way or the other, just that we >>>>>> should decide where this is going. >>>>>> >>>>>> Cheers >>>>>> Simon >>>>>> >>>>>> Very specifically answering Simon M's concern: I see >>>>>>> ExtendedForAllScope as a dead end, yes. It's included as a way of >>>>>>> supporting the gobs and gobs and gobs of code that use today's >>>>>>> ScopedTypeVariables, but at t=∞, we should get rid of it. Note that an optional >>>>>>> extra >>>>>>> introduces >>>>>>> a @(..) syntax that makes TypeAbstractions significantly less repetitive, >>>>>>> and thus about as easy to use as ExtendedForAllScope (which, recall, >>>>>>> requires an explicit forall where there might otherwise be none). >>>>>>> >>>>>>> Richard >>>>>>> >>>>>>> PS: I'm on holiday starting tomorrow and so may not respond for >>>>>>> about two weeks. Back in action on the 15th, but expect a few days of >>>>>>> digging out. >>>>>>> _______________________________________________ >>>>>>> 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 Jun 7 08:53:34 2022 From: simon.peytonjones at gmail.com (Simon Peyton Jones) Date: Tue, 7 Jun 2022 09:53:34 +0100 Subject: [ghc-steering-committee] Please review #473: First-class existential types, Shepherd: Simon PJ In-Reply-To: <122925b449860d50063fea297d8c08f206d203bd.camel@joachim-breitner.de> References: <122925b449860d50063fea297d8c08f206d203bd.camel@joachim-breitner.de> Message-ID: Everyone As you'll see from the proposal thread , Richard is going to revise this proposal a bit. Simon On Mon, 16 May 2022 at 20:59, Joachim Breitner wrote: > Dear Committee, > > First-class existential types > has been submitted by Richard > > https://github.com/ghc-proposals/ghc-proposals/pull/374 > > > https://github.com/goldfirere/ghc-proposals/blob/existentials/proposals/0473-existentials.rst > > > Exciting stuff! This feels, at least to me, like a proposal with major > implications – not least because I believe it means that type equality > will now involve some form of term equivalence, and may thus affect > what kind of Core transformations are still type-preserving. Therefore > I would suggest Simon PJ to shepherd this proposal. > > Please guide us to a conclusion as outlined in > https://github.com/ghc-proposals/ghc-proposals#committee-process > > Thanks, > 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 Tue Jun 7 09:46:31 2022 From: mail at joachim-breitner.de (Joachim Breitner) Date: Tue, 07 Jun 2022 11:46:31 +0200 Subject: [ghc-steering-committee] Modern Scoped Type Variables #448: recommendation (mostly) accept In-Reply-To: References: <010f017ff5943161-0e13b9be-4338-4c43-b7b1-0b37350596a9-000000@us-east-2.amazonses.com> <010f017ff637ce47-49c9f372-360c-4aed-87b3-2f6a240d0d74-000000@us-east-2.amazonses.com> Message-ID: Hi, it looks like there is a problem with the mailinglist and my email provider, and I did not receive all emails. Luckily we have the archive at https://mail.haskell.org/pipermail/ghc-steering-committee/2022-June/date.html and I noticed that Simon was nudging me personally to comment on #448. > 2. The rest of the main proposal > to have broad support, modulo some concerns about flags and forks. *Action: > Tom, Joachim, Vlad, Eric, Chris, and Baldur*: please express an opinion. > Can you do so this week please? You don't need to wait for (1); just > ignore section 6-8. I’m in favor of these things. They appear to be thought through, and move Haskell in a direction I’m in favor of, while catering for existing code. I hope we don’t block our way too much for a future where > It may be useful to write a variable occurrence to instantiate a  > universal argument but I’ll accept that we’ll have to find syntax for that then, and that the way we approached it in #126 wasn’t great, because it didn’t uphold some of the principles we have identified since then. I would not mind making -XTypeAbstractions and -XExtendedForAllScope mutually exclusive, I think, but I guess the proposed heuristics which one applies works as well, and maybe it is easier for people to migrate if they can do it per-function, and not just per-module. So I’m ok with this. Also in favor of holding off @(..). > 3. The proposal *also *makes a significant diff to the principles.rst > document > , > mostly expanding and clarifying points that were previously just a sentence > or two. (Here's the old version > .) > *Action: Tom, Joachim, Vlad, Eric, Chris, and Baldur*: please express an > opinion. Looks good to me. About the Contiguous Scoping Principle, the examples involving patterns (do-notation for example) feel different (and less bad) than the -XScopedTypeVariables example. Can’t really put my finger on why. But since we state that the Contiguous Scoping Principle is not a goal, merely something to be aware of, that’s fine Cheers, Joachim -- Joachim Breitner mail at joachim-breitner.de http://www.joachim-breitner.de/ From eric at seidel.io Wed Jun 8 01:50:37 2022 From: eric at seidel.io (Eric Seidel) Date: Tue, 07 Jun 2022 21:50:37 -0400 Subject: [ghc-steering-committee] Modern Scoped Type Variables #448: recommendation (mostly) accept In-Reply-To: References: <010f017ff5943161-0e13b9be-4338-4c43-b7b1-0b37350596a9-000000@us-east-2.amazonses.com> <010f017ff637ce47-49c9f372-360c-4aed-87b3-2f6a240d0d74-000000@us-east-2.amazonses.com> Message-ID: <6b085ab3-281b-4625-9596-83f988275b0c@www.fastmail.com> I have left a few comments and questions about the changes to the Principles on GitHub. I think I agree with the changes in spirit, my comments are mostly around clarifying and tightening the Principles. I also strongly agree with SPJ's stance that the Principles are guidelines, not laws. They should provide a framework for us to discuss and compare proposed changes, but they are not foolproof and they do not absolve us of our responsibility to exercise our judgment when deciding which proposals to accept. I will take a closer look at the main proposal this week, but Sections 1-5 look fine to me. On Mon, Jun 6, 2022, at 04:35, Simon Peyton Jones wrote: > I feel blocked here. I don't know how to make progress. Part of the > goal of this proposal is to elicit debate, and so far it has failed to > > I think that: > 1. Section 6-8 (about let in types etc) are controversial, and > explicitly not under debate. *Action*:* @rae *would you like to remove > them to another proposal? > > 2. The rest of the main proposal > seems > to have broad support, modulo some concerns about flags and forks. > *Action: Tom, Joachim, Vlad, Eric, Chris, and Baldur*: please express > an opinion. Can you do so this week please? You don't need to wait for > (1); just ignore section 6-8. > > 3. The proposal *also *makes a significant diff to the principles.rst > document > , > mostly expanding and clarifying points that were previously just a > sentence or two. (Here's the old version > .) > *Action: Tom, Joachim, Vlad, Eric, Chris, and Baldur*: please express > an opinion. > > 4. *Action @rae*: there has been some discussion about flags and > forks. Would you like to make whatever resolution you think is > appropriate, in the light of this conversation, and let us know what is? > Let's get this over the line. I don't think there is any serious > disagreement, and we have an obligation to authors to give their work > our timely attention. > > Simon > > On Wed, 1 Jun 2022 at 10:53, Spiwack, Arnaud wrote: >> Dear all, >> >> I feel blocked here. I don't know how to make progress. Part of the goal of this proposal is to elicit debate, and so far it has failed to. >> >> Simon PJ says that the principles “bind us completely in future”. But I'd argue that we still advertise them as desirable. Things we want to get better at in the future. So a proposal saying “it makes GHC better at the Contiguous Scoping Principle” is well-justified enough. Is it what we want? That's the question. >> >> On Fri, Apr 22, 2022 at 8:37 AM Spiwack, Arnaud wrote: >>> Any other opinion? Only a few of us have participated in this thread: Tom, Joachim, Vlad, Eric, Chris, and Baldur, I'd love to hear from you. Do these principles make sense to you, or should they be rephrased? Do you agree with all of them? >>> >>> On Mon, Apr 18, 2022 at 9:51 AM Simon Peyton Jones wrote: >>>> I'm OK with them provided we do not get into later discussions like "this proposal violates the X principle, so we should reject it". The principles doc says only "Proposals following these principles are more likely to be accepted" which is fine. I just don't want them to bind us completely in future. >>>> >>>> I agree that having the principles gives a us a language and framework for debate, and so is useful. >>>> >>>> Simon >>>> >>>> On Fri, 15 Apr 2022 at 15:01, Spiwack, Arnaud wrote: >>>>> Dear all, >>>>> >>>>> There has been no discussion of the principles so far. May I ask you what you think of the principles introduced by the proposal (I recommend reading the diff of `principles.rst` in raw form, the visual diff doesn't seem to work properly for me). >>>>> >>>>> Here is what I said about them in my initial email >>>>> >>>>>> The proposal adds new principles to the `principles.rst` files which inform the changes proposed, of these, I have the following comments: >>>>>> - The Visibility Orthogonality Principle doesn't seem to have a very clear definition. It may be a sign that it's not something that is so important >>>>>> - The Explicit Binding Principle says that we need to be able to enforce that all type variables have a binding site. I think it's a bit strong: I would like Haskell to let me write a binding site for every type variable, but not necessarily to error out when that doesn't happen. That being said, I'm happy with warnings to help me along the way, but I don't think that this Explicit Binding Principle should be phrased in a way that requires adding extensions to control this behaviour. >>>>>> - The Contiguous Scoping Principle, which states that a binder binds in one contiguous region sounds dubious to me. I don't see a particular reason for this to be. >>>>> >>>>> I think that the Explicit Binding Principle has implicitly been discussed in the thread about warnings above. There are other principles that Richard proposes, which I all find I agree with. >>>>> >>>>> Best, >>>>> Arnaud >>>>> >>>>> On Tue, Apr 5, 2022 at 3:43 PM Simon Marlow wrote: >>>>>> That all sounds reasonable to me. I suggest: >>>>>> >>>>>> * Let's mention in the proposal that ExtendedForAllScope exists for legacy reasons and that we intend to recommend TypeAbstractions as the canonical way to bind type variables in the future (is that the right wording? we're not ready to actually recommend it yet?). >>>>>> * When this is implemented, let's have wording to the same effect in the manual. Someone writing new code would want to know which way is likely to be the more future-proof alternative. >>>>>> >>>>>> > Complicating this story is that some users (including me, at times) wish for GHC to do less for us: we would prefer not to have implicit foralls or to permit pattern-signature bindings. However, I suppose this desire could be accommodated by warnings and -Werror instead of language extensions. >>>>>> >>>>>> Definitely - warnings and/or HLint for stylistic choices is the right way to do it. >>>>>> >>>>>> Cheers >>>>>> Simon >>>>>> >>>>>> On Mon, 4 Apr 2022 at 21:15, Richard Eisenberg wrote: >>>>>>> Thanks for reminding us of that definition in our review criteria -- it's helpful. >>>>>>> >>>>>>> I would say that every extension in this proposal fits the standard, except for ExtendedForAllScope. That is, I would be happy for the following extensions (as described in this proposal) to be part of a standard: >>>>>>> - PatternSignatures >>>>>>> - PatternSignatureBinds >>>>>>> - MethodTypeVariables (though John Ericson makes a comment on GitHub which suggests that this, too, may want revision -- I'm not fully convinced yet) >>>>>>> - ImplicitForAll >>>>>>> - TypeAbstractions >>>>>>> (and ExtendedLet, but that's not being debated at the moment) >>>>>>> >>>>>>> Complicating this story is that some users (including me, at times) wish for GHC to do less for us: we would prefer not to have implicit foralls or to permit pattern-signature bindings. However, I suppose this desire could be accommodated by warnings and -Werror instead of language extensions. >>>>>>> >>>>>>> That logic might suggest revisiting #285 (which introduced NoImplicitForAll and NoPatternSignatureBinds), instead wishing for these to become warnings, rather than language extensions. (NB: #285 is accepted, but not implemented.) >>>>>>> >>>>>>> Regarding GHCXXXX: Yes, I think we would end up removing ExtendedForAllScope from it -- or at least I would advocate for doing so. Indeed, when we considered ScopedTypeVariables as a candidate for GHCXXXX, I was worried about getting stuck with it, and I believe it was important to me that we had the option to remove, later. >>>>>>> >>>>>>> Richard >>>>>>> >>>>>>>> On Apr 4, 2022, at 3:38 PM, Simon Marlow wrote: >>>>>>>> >>>>>>>> On Mon, 4 Apr 2022 at 18:17, Richard Eisenberg wrote: >>>>>>>>> Thanks for kicking off this conversation, Arnaud! >>>>>>>>> >>>>>>>>> To be clear in this thread: I'm fine delaying the discussion of section 6-8 until later. >>>>>>>>> >>>>>>>>> Arnaud brings up my new principles in his initial email. Do please consider these principles as part of the deliberations, as they will become principles that we, as a committee, will have adopted. >>>>>>>>> >>>>>>>>> About extensions: We, as a community and as a committee, have not come to terms with the two possible interpretations of extensions. I would like to say that, ideally, extensions are candidates for eventual inclusion. However, that is neither the current practice nor our trendline. Examples: >>>>>>>>> - any flags included in Haskell98 (including, for example, MonomorphismRestriction). These are definitely settings that one can choose per module. If they were candidates for inclusion, they wouldn't exist (because they're already included!). >>>>>>>>> - RebindableSyntax (though this is not one to mimic) >>>>>>>>> - MagicHash. My interpretation is that this extension is meant to allow users to explicitly opt into low-level code. >>>>>>>>> - Recently accepted #285 , which introduces two new -XNo... extensions (both also included in #448). >>>>>>>>> As a practical matter, then, extensions are means of customization. We might imagine a debate where we try to change this, and then come up with a way to get from where we are to that changed future. >>>>>>>> >>>>>>>> I think we actually did come to some agreement on the interpretation of extensions, it's in our review criteria under "does not create a language fork": https://github.com/ghc-proposals/ghc-proposals#review-criteria . Yes there are plenty of extensions that don't fit this criteria, but they tend to be either special-purpose extensions for things like low-level programming, building DSLs, or for backwards compatibility, rather than extensions we would expect people to routinely enable. >>>>>>>> >>>>>>>> Does that apply in this case? Well, perhaps the extensions are not technically incompatible, but they're "at odds" as Arnaud puts it. >>>>>>>> >>>>>>>> Another way to frame the original question might be: which of these extensions do we expect to include in GHC2023 (or GHC2024 or whatever it ends up being)? GHC2021 already has ScopedTypeVariables. We did decide (if I recall correctly) that we might remove things from future GHCXXXX sets, so are we going to remove ExtendedForAllScope and add TypeAbstractions from some future GHCXXXX, or just add TypeAbstractions? >>>>>>>> >>>>>>>> I'm not expressing a preference one way or the other, just that we should decide where this is going. >>>>>>>> >>>>>>>> Cheers >>>>>>>> Simon >>>>>>>> >>>>>>>>> Very specifically answering Simon M's concern: I see ExtendedForAllScope as a dead end, yes. It's included as a way of supporting the gobs and gobs and gobs of code that use today's ScopedTypeVariables, but at t=∞, we should get rid of it. Note that an optional extra introduces a @(..) syntax that makes TypeAbstractions significantly less repetitive, and thus about as easy to use as ExtendedForAllScope (which, recall, requires an explicit forall where there might otherwise be none). >>>>>>>>> >>>>>>>>> Richard >>>>>>>>> >>>>>>>>> PS: I'm on holiday starting tomorrow and so may not respond for about two weeks. Back in action on the 15th, but expect a few days of digging out. >>>>>>>>> _______________________________________________ >>>>>>>>> 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 From eric at seidel.io Sun Jun 12 16:19:17 2022 From: eric at seidel.io (Eric Seidel) Date: Sun, 12 Jun 2022 12:19:17 -0400 Subject: [ghc-steering-committee] Please review #496: Nothing {}, Shepherd: Eric In-Reply-To: <7783a6d393b9ba02830d820e8635f5f06cc94741.camel@joachim-breitner.de> References: <7783a6d393b9ba02830d820e8635f5f06cc94741.camel@joachim-breitner.de> Message-ID: Dear Committee, This proposal notes an inconsistency around record wildcard syntax where the wildcard selector/binder cannot be used with nullary record constructors. In other words ``` data Foo = Foo {} x = Foo {..} ``` is rejected with the error Illegal `..' notation for constructor ‘Bar’ The constructor has no labelled fields John notes that this is unnecessary friction that also causes grief for code generators. The proposal is to allow the use of record wildcard syntax with nullary constructors. Notably the proposal suggests allowing wildcard syntax with both nullary *records* and nullary positional data constructors, ie both of the following would be allowed. ``` data Foo = Foo {} data Foo = Foo x = Foo {..} ``` I noted on GitHub that this leaves a small asymmetry[1], but I still recommend accepting the proposal as is. As usual, please discuss the proposal's merits in this thread, and the technical details on GitHub. [1]: https://github.com/ghc-proposals/ghc-proposals/pull/496#issuecomment-1153221981 Eric On Mon, May 30, 2022, at 09:28, Joachim Breitner wrote: > Dear Committee, > > Empty records with {} > have been proposed by John Ericsson > > > https://github.com/ghc-proposals/ghc-proposals/pull/496 > https://github.com/Ericson2314/ghc-proposals/blob/empty-record-wildcards/proposals/0000-empty-record-wildcards.rst > > This seems to be about straightening a corner case, so to say. I > suggest Eric as the shepherd. > > Please guide us to a conclusion as outlined in > https://github.com/ghc-proposals/ghc-proposals#committee-process > > Thanks, > 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 mail at joachim-breitner.de Sun Jun 12 22:22:34 2022 From: mail at joachim-breitner.de (Joachim Breitner) Date: Mon, 13 Jun 2022 00:22:34 +0200 Subject: [ghc-steering-committee] Please review #496: Nothing {}, Shepherd: Eric In-Reply-To: References: <7783a6d393b9ba02830d820e8635f5f06cc94741.camel@joachim-breitner.de> Message-ID: <1a29a1cbfaa3cba9c1db6ae42ae4b5378f649955.camel@joachim-breitner.de> Hi, Am Sonntag, dem 12.06.2022 um 12:19 -0400 schrieb Eric Seidel: > but I still recommend accepting the proposal as is. I support that. It doesn’t seem to hurt allowing it in hand-written code, and if people generating code have an easier time this way, then yes, let’s do this. Cheers, Joachim -- Joachim Breitner mail at joachim-breitner.de http://www.joachim-breitner.de/ From arnaud.spiwack at tweag.io Mon Jun 13 07:56:37 2022 From: arnaud.spiwack at tweag.io (Spiwack, Arnaud) Date: Mon, 13 Jun 2022 09:56:37 +0200 Subject: [ghc-steering-committee] Please review #496: Nothing {}, Shepherd: Eric In-Reply-To: <1a29a1cbfaa3cba9c1db6ae42ae4b5378f649955.camel@joachim-breitner.de> References: <7783a6d393b9ba02830d820e8635f5f06cc94741.camel@joachim-breitner.de> <1a29a1cbfaa3cba9c1db6ae42ae4b5378f649955.camel@joachim-breitner.de> Message-ID: I agree. This sounds all very reasonable. On Mon, Jun 13, 2022 at 12:22 AM Joachim Breitner wrote: > Hi, > > Am Sonntag, dem 12.06.2022 um 12:19 -0400 schrieb Eric Seidel: > > but I still recommend accepting the proposal as is. > > I support that. It doesn’t seem to hurt allowing it in hand-written > code, and if people generating code have an easier time this way, then > yes, let’s do this. > > 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 Jun 13 13:18:03 2022 From: mail at joachim-breitner.de (Joachim Breitner) Date: Mon, 13 Jun 2022 15:18:03 +0200 Subject: [ghc-steering-committee] GHC Steering Committee Status Message-ID: <3e9d3666aaa795abe28b5a8383b36108465a4ac7.camel@joachim-breitner.de> Dear Committee, it’s about time for my ~monthly~ ~quarterly~ bimonthly status update So what has happened since the last one? * I proposed that we proposals upon submission ought to have some indication that there is someone willing and able to implement it, please join the discussion on https://github.com/ghc-proposals/ghc-proposals/pull/517 * we were asked to review these proposals: #500: Add implicit import proposal, Shepherd: Baldur #473: First-class existential types, Shepherd: Simon PJ #496: Nothing {}, Shepherd: Eric * we have a recommendation from the shepherd about: #496: Nothing {}, rec: accept * we have sent the following proposals back to revision none, it seems * we decided about the following proposals #451: Sized literals proposal (accept) We currently have to act on the following 6 proposals, up 2 since last update: ## Waiting for committee decision #454: Custom type warnings, Shepherd: Tom 2022-01-13: Recommendation to accept 2022-06-01: Arnaud says objections are minor. Tom, do you think we have consensus here? #448: Modern Scoped Type Variables, Shepherd: Arnaud 2022-03-29: Arnaud makes a non-comprehensive recommendation 2022-06-07: Ongoing discussion #496: Nothing {}, Shepherd: Eric 2022-06-12: Eric suggests acceptance ## Waiting for Shepherd action #270: Support pun-free code, Shepherd: Chris 2022-01-01: Assigned to Chris Chris, kindly please leap into action! #500: Add implicit import proposal, Shepherd: Baldur 2022-05-05: Assignd to Baldur #473: First-class existential types, Shepherd: Simon PJ 2022-05-16: Assigned to Simon Cheers, Joachim -- Joachim Breitner mail at joachim-breitner.de http://www.joachim-breitner.de/ From simon.peytonjones at gmail.com Mon Jun 13 19:11:14 2022 From: simon.peytonjones at gmail.com (Simon Peyton Jones) Date: Mon, 13 Jun 2022 20:11:14 +0100 Subject: [ghc-steering-committee] GHC Steering Committee Status In-Reply-To: <3e9d3666aaa795abe28b5a8383b36108465a4ac7.camel@joachim-breitner.de> References: <3e9d3666aaa795abe28b5a8383b36108465a4ac7.camel@joachim-breitner.de> Message-ID: Thanks Joachim. Maybe you didn't see, but #473 is back with Richard for revision, so no longer on the Committee's to-do list Simon On Mon, 13 Jun 2022 at 14:18, Joachim Breitner wrote: > Dear Committee, > > it’s about time for my ~monthly~ ~quarterly~ bimonthly status update > > So what has happened since the last one? > > * I proposed that we proposals upon submission ought to have some > indication > that there is someone willing and able to implement it, please join > the discussion on > https://github.com/ghc-proposals/ghc-proposals/pull/517 > > * we were asked to review these proposals: > > #500: Add implicit import proposal, Shepherd: Baldur > #473: First-class existential types, Shepherd: Simon PJ > #496: Nothing {}, Shepherd: Eric > > * we have a recommendation from the shepherd about: > > #496: Nothing {}, rec: accept > > * we have sent the following proposals back to revision > > none, it seems > > * we decided about the following proposals > > #451: Sized literals proposal (accept) > > We currently have to act on the following 6 proposals, up 2 since last > update: > > ## Waiting for committee decision > > #454: Custom type warnings, Shepherd: Tom > 2022-01-13: Recommendation to accept > 2022-06-01: Arnaud says objections are minor. > Tom, do you think we have consensus here? > > #448: Modern Scoped Type Variables, Shepherd: Arnaud > 2022-03-29: Arnaud makes a non-comprehensive recommendation > 2022-06-07: Ongoing discussion > > #496: Nothing {}, Shepherd: Eric > 2022-06-12: Eric suggests acceptance > > ## Waiting for Shepherd action > > #270: Support pun-free code, Shepherd: Chris > 2022-01-01: Assigned to Chris > Chris, kindly please leap into action! > > #500: Add implicit import proposal, Shepherd: Baldur > 2022-05-05: Assignd to Baldur > > #473: First-class existential types, Shepherd: Simon PJ > 2022-05-16: Assigned to Simon > > > > > 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 Jun 13 19:15:54 2022 From: mail at joachim-breitner.de (Joachim Breitner) Date: Mon, 13 Jun 2022 19:15:54 +0000 (UTC) Subject: [ghc-steering-committee] GHC Steering Committee Status In-Reply-To: References: <3e9d3666aaa795abe28b5a8383b36108465a4ac7.camel@joachim-breitner.de> Message-ID: <12b58f74-8f03-44da-ac79-f3ad07d2b70a@joachim-breitner.de> Ah thanks, indeed! I updated the label on GitHub accordingly - thats my main source for the status updates. 13.06.2022 21:11:25 Simon Peyton Jones : > Thanks Joachim. > > Maybe you didn't see, but #473 is back with Richard for revision, so no longer on the Committee's to-do list > > Simon > > On Mon, 13 Jun 2022 at 14:18, Joachim Breitner wrote: >> Dear Committee, >> >> it’s about time for my ~monthly~ ~quarterly~ bimonthly status update >> >> So what has happened since the last one? >> >>  * I proposed that we proposals upon submission ought to have some indication >>    that there is someone willing and able to implement it, please join >>    the discussion on https://github.com/ghc-proposals/ghc-proposals/pull/517 >> >>  * we were asked to review these proposals: >> >>    #500: Add implicit import proposal, Shepherd: Baldur >>    #473: First-class existential types, Shepherd: Simon PJ >>    #496: Nothing {}, Shepherd: Eric >> >>  * we have a recommendation from the shepherd about: >> >>    #496: Nothing {}, rec: accept >> >>  * we have sent the following proposals back to revision >> >>    none, it seems >> >>  * we decided about the following proposals >> >>    #451: Sized literals proposal (accept) >> >> We currently have to act on the following 6 proposals, up 2 since last update: >> >> ## Waiting for committee decision >> >> #454: Custom type warnings, Shepherd: Tom >>       2022-01-13: Recommendation to accept >>       2022-06-01: Arnaud says objections are minor. >>       Tom, do you think we have consensus here? >> >> #448: Modern Scoped Type Variables, Shepherd: Arnaud >>       2022-03-29: Arnaud makes a non-comprehensive recommendation >>       2022-06-07: Ongoing discussion >> >> #496: Nothing {}, Shepherd: Eric >>       2022-06-12: Eric suggests acceptance >> >> ## Waiting for Shepherd action >> >> #270: Support pun-free code, Shepherd: Chris >>       2022-01-01: Assigned to Chris >>       Chris, kindly please leap into action! >> >> #500: Add implicit import proposal, Shepherd: Baldur >>       2022-05-05: Assignd to Baldur >> >> #473: First-class existential types, Shepherd: Simon PJ >>       2022-05-16: Assigned to Simon >> >> >> >> >> 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 Tue Jun 14 13:59:47 2022 From: mail at joachim-breitner.de (Joachim Breitner) Date: Tue, 14 Jun 2022 15:59:47 +0200 Subject: [ghc-steering-committee] Please review: #511 Deep Subsumption, Shepherd: Arnaud In-Reply-To: References: <010f017e5569032d-97a2902a-b938-4137-b9a7-70a1ead09852-000000@us-east-2.amazonses.com> <53E9ABAB-B660-477A-83AE-9D3BD6B0FAB7@gmail.com> <010f017e55a3195b-b551e32d-6ee6-4a12-86f8-92d3a8085ade-000000@us-east-2.amazonses.com> Message-ID: Dear Committee, Deep Subsumption has been submitted by Matthew Pickering, Simon Peyton Jones and Jaro Reinders https://github.com/ghc-proposals/ghc-proposals/pull/511 https://github.com/mpickering/ghc-proposals/blob/deep-subsumption/proposals/0000-deep-subsumption.rst Given that this refines #281, shepherded by Arnaud, I suggest that he shepherds this one too. Please guide us to a conclusion as outlined in https://github.com/ghc-proposals/ghc-proposals#committee-process Thanks, Joachim From arnaud.spiwack at tweag.io Mon Jun 20 13:56:07 2022 From: arnaud.spiwack at tweag.io (Spiwack, Arnaud) Date: Mon, 20 Jun 2022 15:56:07 +0200 Subject: [ghc-steering-committee] #511 Deep Subsumption, recommendation: accept Message-ID: Dear all, The Deep Subsumption proposal [ https://github.com/ghc-proposals/ghc-proposals/pull/511 ] proposes a new extension, -XDeepSubsumption, which, when activated, partially reverts the changes from the Simplified Subsumption proposal. The Simplified Subsumption breaks more programs than anticipated. Many don't see any benefit from Simplified Subsumption, just the breakage, and don't like the eta-expansion that it forces. -XDeepSubsumption, when activated, restores deep skolemisation and co/contra-variance of the function arrow (but not deep instantiation, which doesn't affect the observed breakage). The patch already exists for it, and is about 400loc. There are two interesting highlights for me. - It is proposed that -XDeepSubsumption is activated by default in Haskell98 and Haskell2010, but not GHC2021. -XDeepSubsumption is orthogonal to Haskell2010, as far as I can tell, but it gives a cut-off point from which the recommended behaviour (-XNoDeepSubsumption) is the default. - Even with -XDeepSubsumption, the Quick Look algorithm assumes that the function arrow is invariant. The consequences of that are difficult to anticipate, but there is no known example of a bad behaviour due to that interaction yet. The authors also have one unresolved question that I'm bringing to the committee's attention: should `-XDeepSubsumption` be backported to GHC 9.2? --- Despite the fact that this extension is decidedly fork-like, and that it's a real possibility to see the community split around this (after all, the motivation for -XDeepSubsumption is a few libraries which were designed to leverage GHC's deep subsumption, and may very well stay that way in the foreseeable future). I recommend acceptance. Providing a path to backward compatibility seems to me like the right thing to do. I also recommend backporting to GHC 9.2. It should essentially be backward compatible, and providing an update path that doesn't go directly from 9.0 to 9.4 feels better to me. -------------- next part -------------- An HTML attachment was scrubbed... URL: From marlowsd at gmail.com Tue Jun 21 09:47:39 2022 From: marlowsd at gmail.com (Simon Marlow) Date: Tue, 21 Jun 2022 10:47:39 +0100 Subject: [ghc-steering-committee] #511 Deep Subsumption, recommendation: accept In-Reply-To: References: Message-ID: I'm never a fan of fork-like things, but as long as we're clear that -XDeepSubsumption is not recommended and will not be on by default in a future GHC20XX then I suppose it's OK. If it's backported to 9.2, then code wanting to use it would need to have a `ghc >= 9.2.4` constraint in the `.cabal` file, which is a bit unusual. We don't normally add new language features in a patchlevel release. But this isn't a strong argument for not doing it I guess - you would need that constraint if you relied on some bug that was fixed in 9.2.4 too. Cheers Simon On Mon, 20 Jun 2022 at 14:56, Spiwack, Arnaud wrote: > Dear all, > > The Deep Subsumption proposal [ > https://github.com/ghc-proposals/ghc-proposals/pull/511 ] proposes a new > extension, -XDeepSubsumption, which, when activated, partially reverts the > changes from the Simplified Subsumption proposal. > > The Simplified Subsumption breaks more programs than anticipated. Many > don't see any benefit from Simplified Subsumption, just the breakage, and > don't like the eta-expansion that it forces. > > -XDeepSubsumption, when activated, restores deep skolemisation and > co/contra-variance of the function arrow (but not deep instantiation, which > doesn't affect the observed breakage). The patch already exists for it, and > is about 400loc. > > There are two interesting highlights for me. > - It is proposed that -XDeepSubsumption is activated by default in > Haskell98 and Haskell2010, but not GHC2021. -XDeepSubsumption is orthogonal > to Haskell2010, as far as I can tell, but it gives a cut-off point from > which the recommended behaviour (-XNoDeepSubsumption) is the default. > - Even with -XDeepSubsumption, the Quick Look algorithm assumes that the > function arrow is invariant. The consequences of that are difficult to > anticipate, but there is no known example of a bad behaviour due to that > interaction yet. > > The authors also have one unresolved question that I'm bringing to the > committee's attention: should `-XDeepSubsumption` be backported to GHC 9.2? > > --- > > Despite the fact that this extension is decidedly fork-like, and that it's > a real possibility to see the community split around this (after all, the > motivation for -XDeepSubsumption is a few libraries which were designed to > leverage GHC's deep subsumption, and may very well stay that way in the > foreseeable future). I recommend acceptance. Providing a path to backward > compatibility seems to me like the right thing to do. > > I also recommend backporting to GHC 9.2. It should essentially be backward > compatible, and providing an update path that doesn't go directly from 9.0 > to 9.4 feels better to me. > _______________________________________________ > 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 Tue Jun 21 10:32:44 2022 From: mail at joachim-breitner.de (Joachim Breitner) Date: Tue, 21 Jun 2022 12:32:44 +0200 Subject: [ghc-steering-committee] #511 Deep Subsumption, recommendation: accept In-Reply-To: References: Message-ID: Hi, Am Dienstag, dem 21.06.2022 um 10:47 +0100 schrieb Simon Marlow: > If it's backported to 9.2, then code wanting to use it would need to > have a `ghc >= 9.2.4` constraint in the `.cabal` file, which is a bit > unusual. We don't normally add new language features in a patchlevel > release. But this isn't a strong argument for not doing it I guess - > you would need that constraint if you relied on some bug that was > fixed in 9.2.4 too. Slight digression, but does Cabal even allow specifying bounds on the compiler implementation? If you put this into the build-depends it might have that effect, but it will also depend on ghc-the-library, not what people usually do. If I need to depend on a specific version of GHC, I tend to peek at https://gitlab.haskell.org/ghc/ghc/-/wikis/commentary/libraries/version-history and hope that base was bumped together with it, and depend on that version of base. Is there a better way? Cheers, Joachim -- Joachim Breitner mail at joachim-breitner.de http://www.joachim-breitner.de/ From marlowsd at gmail.com Tue Jun 21 10:45:51 2022 From: marlowsd at gmail.com (Simon Marlow) Date: Tue, 21 Jun 2022 11:45:51 +0100 Subject: [ghc-steering-committee] #511 Deep Subsumption, recommendation: accept In-Reply-To: References: Message-ID: On Tue, 21 Jun 2022 at 11:33, Joachim Breitner wrote: > Hi, > > Am Dienstag, dem 21.06.2022 um 10:47 +0100 schrieb Simon Marlow: > > If it's backported to 9.2, then code wanting to use it would need to > > have a `ghc >= 9.2.4` constraint in the `.cabal` file, which is a bit > > unusual. We don't normally add new language features in a patchlevel > > release. But this isn't a strong argument for not doing it I guess - > > you would need that constraint if you relied on some bug that was > > fixed in 9.2.4 too. > > Slight digression, but does Cabal even allow specifying bounds on the > compiler implementation? If you put this into the build-depends it > might have that effect, but it will also depend on ghc-the-library, not > what people usually do. > Yes, you can do this (stolen from one of my .cabal files): if impl(ghc >= 8.8) buildable: True else buildable: False Cheers Simon > If I need to depend on a specific version of GHC, I tend to peek at > > https://gitlab.haskell.org/ghc/ghc/-/wikis/commentary/libraries/version-history > and hope that base was bumped together with it, and depend on that > version of base. Is there a better way? > > 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 marlowsd at gmail.com Thu Jun 23 10:00:12 2022 From: marlowsd at gmail.com (Simon Marlow) Date: Thu, 23 Jun 2022 11:00:12 +0100 Subject: [ghc-steering-committee] Please review #496: Nothing {}, Shepherd: Eric In-Reply-To: References: <7783a6d393b9ba02830d820e8635f5f06cc94741.camel@joachim-breitner.de> Message-ID: LGTM On Sun, 12 Jun 2022 at 17:19, Eric Seidel wrote: > Dear Committee, > > This proposal notes an inconsistency around record wildcard syntax where > the wildcard selector/binder cannot be used with nullary record > constructors. In other words > > ``` > data Foo = Foo {} > > x = Foo {..} > ``` > > is rejected with the error > > Illegal `..' notation for constructor ‘Bar’ > The constructor has no labelled fields > > John notes that this is unnecessary friction that also causes grief for > code generators. > > The proposal is to allow the use of record wildcard syntax with nullary > constructors. Notably the proposal suggests allowing wildcard syntax with > both nullary *records* and nullary positional data constructors, ie both of > the following would be allowed. > > ``` > data Foo = Foo {} > data Foo = Foo > > x = Foo {..} > ``` > > I noted on GitHub that this leaves a small asymmetry[1], but I still > recommend accepting the proposal as is. > > As usual, please discuss the proposal's merits in this thread, and the > technical details on GitHub. > > [1]: > https://github.com/ghc-proposals/ghc-proposals/pull/496#issuecomment-1153221981 > > Eric > > On Mon, May 30, 2022, at 09:28, Joachim Breitner wrote: > > Dear Committee, > > > > Empty records with {} > > have been proposed by John Ericsson > > > > > > https://github.com/ghc-proposals/ghc-proposals/pull/496 > > > https://github.com/Ericson2314/ghc-proposals/blob/empty-record-wildcards/proposals/0000-empty-record-wildcards.rst > > > > This seems to be about straightening a corner case, so to say. I > > suggest Eric as the shepherd. > > > > Please guide us to a conclusion as outlined in > > https://github.com/ghc-proposals/ghc-proposals#committee-process > > > > Thanks, > > 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 Fri Jun 24 10:29:33 2022 From: simon.peytonjones at gmail.com (Simon Peyton Jones) Date: Fri, 24 Jun 2022 11:29:33 +0100 Subject: [ghc-steering-committee] Please review #496: Nothing {}, Shepherd: Eric In-Reply-To: References: <7783a6d393b9ba02830d820e8635f5f06cc94741.camel@joachim-breitner.de> Message-ID: As I say on the proposal thread, I'm in favour. I do want John to fix the bug in the text though. Simon On Sun, 12 Jun 2022 at 17:19, Eric Seidel wrote: > Dear Committee, > > This proposal notes an inconsistency around record wildcard syntax where > the wildcard selector/binder cannot be used with nullary record > constructors. In other words > > ``` > data Foo = Foo {} > > x = Foo {..} > ``` > > is rejected with the error > > Illegal `..' notation for constructor ‘Bar’ > The constructor has no labelled fields > > John notes that this is unnecessary friction that also causes grief for > code generators. > > The proposal is to allow the use of record wildcard syntax with nullary > constructors. Notably the proposal suggests allowing wildcard syntax with > both nullary *records* and nullary positional data constructors, ie both of > the following would be allowed. > > ``` > data Foo = Foo {} > data Foo = Foo > > x = Foo {..} > ``` > > I noted on GitHub that this leaves a small asymmetry[1], but I still > recommend accepting the proposal as is. > > As usual, please discuss the proposal's merits in this thread, and the > technical details on GitHub. > > [1]: > https://github.com/ghc-proposals/ghc-proposals/pull/496#issuecomment-1153221981 > > Eric > > On Mon, May 30, 2022, at 09:28, Joachim Breitner wrote: > > Dear Committee, > > > > Empty records with {} > > have been proposed by John Ericsson > > > > > > https://github.com/ghc-proposals/ghc-proposals/pull/496 > > > https://github.com/Ericson2314/ghc-proposals/blob/empty-record-wildcards/proposals/0000-empty-record-wildcards.rst > > > > This seems to be about straightening a corner case, so to say. I > > suggest Eric as the shepherd. > > > > Please guide us to a conclusion as outlined in > > https://github.com/ghc-proposals/ghc-proposals#committee-process > > > > Thanks, > > 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 Sat Jun 25 09:21:30 2022 From: mail at joachim-breitner.de (Joachim Breitner) Date: Sat, 25 Jun 2022 11:21:30 +0200 Subject: [ghc-steering-committee] Please review: #330 Decorate exceptions with backtrace information, Shepherd: Vladislav In-Reply-To: References: <010f017e5569032d-97a2902a-b938-4137-b9a7-70a1ead09852-000000@us-east-2.amazonses.com> <53E9ABAB-B660-477A-83AE-9D3BD6B0FAB7@gmail.com> <010f017e55a3195b-b551e32d-6ee6-4a12-86f8-92d3a8085ade-000000@us-east-2.amazonses.com> Message-ID: <200f20c79b04aa2d6d978edebb24131fc5e53df4.camel@joachim-breitner.de> Dear Committee, Decorate exceptions with backtrace information has been submitted by Ben Gamari; David Eichmann; Sven Tennie https://github.com/ghc-proposals/ghc-proposals/pull/330 https://github.com/bgamari/ghc-proposals/blob/stacktraces/proposals/0000-exception-backtraces.rst I’d like to ask Vlad to shepherd this. Please guide us to a conclusion as outlined in https://github.com/ghc-proposals/ghc-proposals#committee-process Thanks, 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 eric at seidel.io Sun Jun 26 13:23:21 2022 From: eric at seidel.io (Eric Seidel) Date: Sun, 26 Jun 2022 09:23:21 -0400 Subject: [ghc-steering-committee] #511 Deep Subsumption, recommendation: accept In-Reply-To: References: Message-ID: I think this is a particularly hard fork to stomach, because -XDeepSubsumption must be enabled in *client modules* in order to gain the usability benefits. That makes it quite infectious, and puts the burden of reasoning about complications from auto-eta-expansion on users rather than library authors. I've asked the authors on GitHub to consider an alternative where *library authors* flag modules/functions/parameters as being candidates for auto-eta-expansion instead. It seems like that may provide the same usability benefits to clients, but importantly puts the pebble in the right shoe wrt language complexity. On Tue, Jun 21, 2022, at 05:47, Simon Marlow wrote: > I'm never a fan of fork-like things, but as long as we're clear that > -XDeepSubsumption is not recommended and will not be on by default in a > future GHC20XX then I suppose it's OK. > > If it's backported to 9.2, then code wanting to use it would need to > have a `ghc >= 9.2.4` constraint in the `.cabal` file, which is a bit > unusual. We don't normally add new language features in a patchlevel > release. But this isn't a strong argument for not doing it I guess - > you would need that constraint if you relied on some bug that was fixed > in 9.2.4 too. > > Cheers > Simon > > On Mon, 20 Jun 2022 at 14:56, Spiwack, Arnaud wrote: >> Dear all, >> >> The Deep Subsumption proposal [ https://github.com/ghc-proposals/ghc-proposals/pull/511 ] proposes a new extension, -XDeepSubsumption, which, when activated, partially reverts the changes from the Simplified Subsumption proposal. >> >> The Simplified Subsumption breaks more programs than anticipated. Many don't see any benefit from Simplified Subsumption, just the breakage, and don't like the eta-expansion that it forces. >> >> -XDeepSubsumption, when activated, restores deep skolemisation and co/contra-variance of the function arrow (but not deep instantiation, which doesn't affect the observed breakage). The patch already exists for it, and is about 400loc. >> >> There are two interesting highlights for me. >> - It is proposed that -XDeepSubsumption is activated by default in Haskell98 and Haskell2010, but not GHC2021. -XDeepSubsumption is orthogonal to Haskell2010, as far as I can tell, but it gives a cut-off point from which the recommended behaviour (-XNoDeepSubsumption) is the default. >> - Even with -XDeepSubsumption, the Quick Look algorithm assumes that the function arrow is invariant. The consequences of that are difficult to anticipate, but there is no known example of a bad behaviour due to that interaction yet. >> >> The authors also have one unresolved question that I'm bringing to the committee's attention: should `-XDeepSubsumption` be backported to GHC 9.2? >> >> --- >> >> Despite the fact that this extension is decidedly fork-like, and that it's a real possibility to see the community split around this (after all, the motivation for -XDeepSubsumption is a few libraries which were designed to leverage GHC's deep subsumption, and may very well stay that way in the foreseeable future). I recommend acceptance. Providing a path to backward compatibility seems to me like the right thing to do. >> >> I also recommend backporting to GHC 9.2. It should essentially be backward compatible, and providing an update path that doesn't go directly from 9.0 to 9.4 feels better to me. >> _______________________________________________ >> 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 From lists at richarde.dev Wed Jun 29 14:42:02 2022 From: lists at richarde.dev (Richard Eisenberg) Date: Wed, 29 Jun 2022 14:42:02 +0000 Subject: [ghc-steering-committee] Please review #496: Nothing {}, Shepherd: Eric In-Reply-To: References: <7783a6d393b9ba02830d820e8635f5f06cc94741.camel@joachim-breitner.de> Message-ID: <010f0181afe9765b-c23e31fa-79e9-410a-8424-49f78ff66a5e-000000@us-east-2.amazonses.com> I've been away, but I just wanted to chime in that I'm in support. Richard > On Jun 24, 2022, at 6:29 AM, Simon Peyton Jones wrote: > > As I say on the proposal thread, I'm in favour. > > I do want John to fix the bug in the text though. > > Simon > > On Sun, 12 Jun 2022 at 17:19, Eric Seidel > wrote: > Dear Committee, > > This proposal notes an inconsistency around record wildcard syntax where the wildcard selector/binder cannot be used with nullary record constructors. In other words > > ``` > data Foo = Foo {} > > x = Foo {..} > ``` > > is rejected with the error > > Illegal `..' notation for constructor ‘Bar’ > The constructor has no labelled fields > > John notes that this is unnecessary friction that also causes grief for code generators. > > The proposal is to allow the use of record wildcard syntax with nullary constructors. Notably the proposal suggests allowing wildcard syntax with both nullary *records* and nullary positional data constructors, ie both of the following would be allowed. > > ``` > data Foo = Foo {} > data Foo = Foo > > x = Foo {..} > ``` > > I noted on GitHub that this leaves a small asymmetry[1], but I still recommend accepting the proposal as is. > > As usual, please discuss the proposal's merits in this thread, and the technical details on GitHub. > > [1]: https://github.com/ghc-proposals/ghc-proposals/pull/496#issuecomment-1153221981 > > Eric > > On Mon, May 30, 2022, at 09:28, Joachim Breitner wrote: > > Dear Committee, > > > > Empty records with {} > > have been proposed by John Ericsson > > > > > > https://github.com/ghc-proposals/ghc-proposals/pull/496 > > https://github.com/Ericson2314/ghc-proposals/blob/empty-record-wildcards/proposals/0000-empty-record-wildcards.rst > > > > This seems to be about straightening a corner case, so to say. I > > suggest Eric as the shepherd. > > > > Please guide us to a conclusion as outlined in > > https://github.com/ghc-proposals/ghc-proposals#committee-process > > > > Thanks, > > 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 Jun 30 13:50:53 2022 From: arnaud.spiwack at tweag.io (Spiwack, Arnaud) Date: Thu, 30 Jun 2022 15:50:53 +0200 Subject: [ghc-steering-committee] #511 Deep Subsumption, recommendation: accept In-Reply-To: References: Message-ID: Eric, After the exchange on Github: are you still hesitant? On Sun, Jun 26, 2022 at 3:24 PM Eric Seidel wrote: > I think this is a particularly hard fork to stomach, because > -XDeepSubsumption must be enabled in *client modules* in order to gain the > usability benefits. That makes it quite infectious, and puts the burden of > reasoning about complications from auto-eta-expansion on users rather than > library authors. > > I've asked the authors on GitHub to consider an alternative where *library > authors* flag modules/functions/parameters as being candidates for > auto-eta-expansion instead. It seems like that may provide the same > usability benefits to clients, but importantly puts the pebble in the right > shoe wrt language complexity. > > On Tue, Jun 21, 2022, at 05:47, Simon Marlow wrote: > > I'm never a fan of fork-like things, but as long as we're clear that > > -XDeepSubsumption is not recommended and will not be on by default in a > > future GHC20XX then I suppose it's OK. > > > > If it's backported to 9.2, then code wanting to use it would need to > > have a `ghc >= 9.2.4` constraint in the `.cabal` file, which is a bit > > unusual. We don't normally add new language features in a patchlevel > > release. But this isn't a strong argument for not doing it I guess - > > you would need that constraint if you relied on some bug that was fixed > > in 9.2.4 too. > > > > Cheers > > Simon > > > > On Mon, 20 Jun 2022 at 14:56, Spiwack, Arnaud > wrote: > >> Dear all, > >> > >> The Deep Subsumption proposal [ > https://github.com/ghc-proposals/ghc-proposals/pull/511 ] proposes a new > extension, -XDeepSubsumption, which, when activated, partially reverts the > changes from the Simplified Subsumption proposal. > >> > >> The Simplified Subsumption breaks more programs than anticipated. Many > don't see any benefit from Simplified Subsumption, just the breakage, and > don't like the eta-expansion that it forces. > >> > >> -XDeepSubsumption, when activated, restores deep skolemisation and > co/contra-variance of the function arrow (but not deep instantiation, which > doesn't affect the observed breakage). The patch already exists for it, and > is about 400loc. > >> > >> There are two interesting highlights for me. > >> - It is proposed that -XDeepSubsumption is activated by default in > Haskell98 and Haskell2010, but not GHC2021. -XDeepSubsumption is orthogonal > to Haskell2010, as far as I can tell, but it gives a cut-off point from > which the recommended behaviour (-XNoDeepSubsumption) is the default. > >> - Even with -XDeepSubsumption, the Quick Look algorithm assumes that > the function arrow is invariant. The consequences of that are difficult to > anticipate, but there is no known example of a bad behaviour due to that > interaction yet. > >> > >> The authors also have one unresolved question that I'm bringing to the > committee's attention: should `-XDeepSubsumption` be backported to GHC 9.2? > >> > >> --- > >> > >> Despite the fact that this extension is decidedly fork-like, and that > it's a real possibility to see the community split around this (after all, > the motivation for -XDeepSubsumption is a few libraries which were designed > to leverage GHC's deep subsumption, and may very well stay that way in the > foreseeable future). I recommend acceptance. Providing a path to backward > compatibility seems to me like the right thing to do. > >> > >> I also recommend backporting to GHC 9.2. It should essentially be > backward compatible, and providing an update path that doesn't go directly > from 9.0 to 9.4 feels better to me. > >> _______________________________________________ > >> 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 eric at seidel.io Thu Jun 30 14:17:39 2022 From: eric at seidel.io (Eric Seidel) Date: Thu, 30 Jun 2022 10:17:39 -0400 Subject: [ghc-steering-committee] #511 Deep Subsumption, recommendation: accept In-Reply-To: References: Message-ID: <470efec0-8d9c-4f33-a5ee-875639f38a08@www.fastmail.com> I'm on board with acceptance. I do think a backport to older GHC 9.x's would make sense if it's not too much work On Thu, Jun 30, 2022, at 09:50, Spiwack, Arnaud wrote: > Eric, > > After the exchange on Github: are you still hesitant? > > On Sun, Jun 26, 2022 at 3:24 PM Eric Seidel wrote: >> I think this is a particularly hard fork to stomach, because -XDeepSubsumption must be enabled in *client modules* in order to gain the usability benefits. That makes it quite infectious, and puts the burden of reasoning about complications from auto-eta-expansion on users rather than library authors. >> >> I've asked the authors on GitHub to consider an alternative where *library authors* flag modules/functions/parameters as being candidates for auto-eta-expansion instead. It seems like that may provide the same usability benefits to clients, but importantly puts the pebble in the right shoe wrt language complexity. >> >> On Tue, Jun 21, 2022, at 05:47, Simon Marlow wrote: >> > I'm never a fan of fork-like things, but as long as we're clear that >> > -XDeepSubsumption is not recommended and will not be on by default in a >> > future GHC20XX then I suppose it's OK. >> > >> > If it's backported to 9.2, then code wanting to use it would need to >> > have a `ghc >= 9.2.4` constraint in the `.cabal` file, which is a bit >> > unusual. We don't normally add new language features in a patchlevel >> > release. But this isn't a strong argument for not doing it I guess - >> > you would need that constraint if you relied on some bug that was fixed >> > in 9.2.4 too. >> > >> > Cheers >> > Simon >> > >> > On Mon, 20 Jun 2022 at 14:56, Spiwack, Arnaud wrote: >> >> Dear all, >> >> >> >> The Deep Subsumption proposal [ https://github.com/ghc-proposals/ghc-proposals/pull/511 ] proposes a new extension, -XDeepSubsumption, which, when activated, partially reverts the changes from the Simplified Subsumption proposal. >> >> >> >> The Simplified Subsumption breaks more programs than anticipated. Many don't see any benefit from Simplified Subsumption, just the breakage, and don't like the eta-expansion that it forces. >> >> >> >> -XDeepSubsumption, when activated, restores deep skolemisation and co/contra-variance of the function arrow (but not deep instantiation, which doesn't affect the observed breakage). The patch already exists for it, and is about 400loc. >> >> >> >> There are two interesting highlights for me. >> >> - It is proposed that -XDeepSubsumption is activated by default in Haskell98 and Haskell2010, but not GHC2021. -XDeepSubsumption is orthogonal to Haskell2010, as far as I can tell, but it gives a cut-off point from which the recommended behaviour (-XNoDeepSubsumption) is the default. >> >> - Even with -XDeepSubsumption, the Quick Look algorithm assumes that the function arrow is invariant. The consequences of that are difficult to anticipate, but there is no known example of a bad behaviour due to that interaction yet. >> >> >> >> The authors also have one unresolved question that I'm bringing to the committee's attention: should `-XDeepSubsumption` be backported to GHC 9.2? >> >> >> >> --- >> >> >> >> Despite the fact that this extension is decidedly fork-like, and that it's a real possibility to see the community split around this (after all, the motivation for -XDeepSubsumption is a few libraries which were designed to leverage GHC's deep subsumption, and may very well stay that way in the foreseeable future). I recommend acceptance. Providing a path to backward compatibility seems to me like the right thing to do. >> >> >> >> I also recommend backporting to GHC 9.2. It should essentially be backward compatible, and providing an update path that doesn't go directly from 9.0 to 9.4 feels better to me. >> >> _______________________________________________ >> >> 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 From simon.peytonjones at gmail.com Thu Jun 30 15:20:06 2022 From: simon.peytonjones at gmail.com (Simon Peyton Jones) Date: Thu, 30 Jun 2022 16:20:06 +0100 Subject: [ghc-steering-committee] #511 Deep Subsumption, recommendation: accept In-Reply-To: <470efec0-8d9c-4f33-a5ee-875639f38a08@www.fastmail.com> References: <470efec0-8d9c-4f33-a5ee-875639f38a08@www.fastmail.com> Message-ID: Thanks Eric. Arnaud, thanks for pushing on this. If the committee is ready, I'd love to get this decided, so we can land it in GHC, including back-ports to older GHCs, whose release is imminent. Simon On Thu, 30 Jun 2022 at 15:18, Eric Seidel wrote: > I'm on board with acceptance. I do think a backport to older GHC 9.x's > would make sense if it's not too much work > > On Thu, Jun 30, 2022, at 09:50, Spiwack, Arnaud wrote: > > Eric, > > > > After the exchange on Github: are you still hesitant? > > > > On Sun, Jun 26, 2022 at 3:24 PM Eric Seidel wrote: > >> I think this is a particularly hard fork to stomach, because > -XDeepSubsumption must be enabled in *client modules* in order to gain the > usability benefits. That makes it quite infectious, and puts the burden of > reasoning about complications from auto-eta-expansion on users rather than > library authors. > >> > >> I've asked the authors on GitHub to consider an alternative where > *library authors* flag modules/functions/parameters as being candidates for > auto-eta-expansion instead. It seems like that may provide the same > usability benefits to clients, but importantly puts the pebble in the right > shoe wrt language complexity. > >> > >> On Tue, Jun 21, 2022, at 05:47, Simon Marlow wrote: > >> > I'm never a fan of fork-like things, but as long as we're clear that > >> > -XDeepSubsumption is not recommended and will not be on by default in > a > >> > future GHC20XX then I suppose it's OK. > >> > > >> > If it's backported to 9.2, then code wanting to use it would need to > >> > have a `ghc >= 9.2.4` constraint in the `.cabal` file, which is a bit > >> > unusual. We don't normally add new language features in a patchlevel > >> > release. But this isn't a strong argument for not doing it I guess - > >> > you would need that constraint if you relied on some bug that was > fixed > >> > in 9.2.4 too. > >> > > >> > Cheers > >> > Simon > >> > > >> > On Mon, 20 Jun 2022 at 14:56, Spiwack, Arnaud < > arnaud.spiwack at tweag.io> wrote: > >> >> Dear all, > >> >> > >> >> The Deep Subsumption proposal [ > https://github.com/ghc-proposals/ghc-proposals/pull/511 ] proposes a new > extension, -XDeepSubsumption, which, when activated, partially reverts the > changes from the Simplified Subsumption proposal. > >> >> > >> >> The Simplified Subsumption breaks more programs than anticipated. > Many don't see any benefit from Simplified Subsumption, just the breakage, > and don't like the eta-expansion that it forces. > >> >> > >> >> -XDeepSubsumption, when activated, restores deep skolemisation and > co/contra-variance of the function arrow (but not deep instantiation, which > doesn't affect the observed breakage). The patch already exists for it, and > is about 400loc. > >> >> > >> >> There are two interesting highlights for me. > >> >> - It is proposed that -XDeepSubsumption is activated by default in > Haskell98 and Haskell2010, but not GHC2021. -XDeepSubsumption is orthogonal > to Haskell2010, as far as I can tell, but it gives a cut-off point from > which the recommended behaviour (-XNoDeepSubsumption) is the default. > >> >> - Even with -XDeepSubsumption, the Quick Look algorithm assumes that > the function arrow is invariant. The consequences of that are difficult to > anticipate, but there is no known example of a bad behaviour due to that > interaction yet. > >> >> > >> >> The authors also have one unresolved question that I'm bringing to > the committee's attention: should `-XDeepSubsumption` be backported to GHC > 9.2? > >> >> > >> >> --- > >> >> > >> >> Despite the fact that this extension is decidedly fork-like, and > that it's a real possibility to see the community split around this (after > all, the motivation for -XDeepSubsumption is a few libraries which were > designed to leverage GHC's deep subsumption, and may very well stay that > way in the foreseeable future). I recommend acceptance. Providing a path to > backward compatibility seems to me like the right thing to do. > >> >> > >> >> I also recommend backporting to GHC 9.2. It should essentially be > backward compatible, and providing an update path that doesn't go directly > from 9.0 to 9.4 feels better to me. > >> >> _______________________________________________ > >> >> 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: