From marlowsd at gmail.com Fri Apr 1 07:26:58 2022 From: marlowsd at gmail.com (Simon Marlow) Date: Fri, 1 Apr 2022 08:26:58 +0100 Subject: [ghc-steering-committee] Modern Scoped Type Variables #448: recommendation (mostly) accept In-Reply-To: References: Message-ID: In the spirit of not accepting proposals that lead to language forks, it would be great to get some clarification on the concerns that Arnaud raises here: On Tue, 29 Mar 2022 at 16:02, Spiwack, Arnaud wrote: > With the caveat that this proposal introduces quite a few extensions. And > at this point, I'm still not quite sure what Richard recommends is the set > of extensions that I should use (and I'm slightly dismayed that I believe > that it will be a set of cardinal more than 1). I think this reflects a > vision of extensions as switches to customise the behaviour of GHC. This > vision, as I've stated before, is very alien to me: I see extensions as > staging areas for features to become an integral part of Haskell. So I > don't know what to think of all these extensions. I'm definitely not > against splitting -XScopedTypeVariables into smaller components, if it is > done so that they are reassembled in a different way in an alternative > extension that would now be the recommended default (or at least is to > become the next recommended default). > I think we should express an opinion about the intended direction. Are we advising that ExtendedForallScope is a dead end, because we want TypeAbstraction? Cheers Simon > > Finally, there are Sections 6 to 8. These are entirely new. Though they > are working towards the new principles (well, as far as I can tell, Section > 6 doesn't contribute to the principles, but it is a stepping stone for both > Sections 7 and 8). These sections are concerned with adding local > let-bindings of type variables, in particular inside types and patterns. > > By the way, Section 7 proposes two syntaxes for let binders in patterns, > and I *strongly* prefer the second syntax, which reads something like `f > (let b = Bool) (True :: Bool) = …`. > > Anyway, these are new, I feel that they are a bit out of place in a > proposal that is about tidying up the existing designs. That being said, > they are here, and they seem like fairly uncontroversial to me, (except, > probably the syntax `(let b = _)` to bind a variable to a type to be filled > by the compiler). I'm fine with accepting these, though they may require a > bit more scrutiny than the rest. > > Best, > Arnaud > > _______________________________________________ > ghc-steering-committee mailing list > ghc-steering-committee at haskell.org > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mail at joachim-breitner.de Fri Apr 1 09:14:50 2022 From: mail at joachim-breitner.de (Joachim Breitner) Date: Fri, 01 Apr 2022 11:14:50 +0200 Subject: [ghc-steering-committee] Please review #270: Support pun-free code, Shepherd: Chris Dornan Message-ID: <3324fdc21ae3c94bbdae79de5c0d9b97b6670a86.camel@joachim-breitner.de> Dear Committee, Support pun-free code has been resubmitted (again) by Artyom Kuznetsov https://github.com/ghc-proposals/ghc-proposals/pull/270 https://github.com/hithroc/ghc-proposals/blob/master/proposals/0000-support-pun-free-code.md This was previously shepherded by Iavor, and then shepherded by Vitaly. I hope it’s not poisonous. I suggest that Chris takes over. 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/ From simon.peytonjones at gmail.com Mon Apr 4 07:32:57 2022 From: simon.peytonjones at gmail.com (Simon Peyton Jones) Date: Mon, 4 Apr 2022 08:32:57 +0100 Subject: [ghc-steering-committee] Modern Scoped Type Variables #448: recommendation (mostly) accept In-Reply-To: References: Message-ID: Of course, I think we all understand that all these extensions are opt-in, and the behaviour of GHC would not change, for existing modules, would not change if this proposal was accepted. > I think we should express an opinion about the intended direction. Are we advising that ExtendedForallScope is a dead end, because we want TypeAbstraction? One way to think of it is this: if Haskell had type-abstraction from Day 1, would we ever have introduced ExtendedForAllScope? I'm sure we would not. Even at the time we introduced it, I remember we were concerned that it was a very strange (non-nested) scoping construct. We bind term variables in patterns on the LHS; it makes sense to do the same for type variables. So yes, in that sense the story is that we recommend TypeAbstraction for introducing a scoped type variable. Thus, instead of ``` id :: forall a. a -> a id x = (x :: a) ``` we would have ``` id :: forall a. a -> a id @b x = (x::b) -- I have used a different name only for illustrative purposes; could also be 'a'. ``` We have to repeat that type-variable pattern in each equation for the function. But we also have to repeat the term variables, and we just take that for granted. But as a "recommendation", it's a pretty weak one. You are still free to use either ExtendedForAllScope or TypeAbstraction or both at once in a particular module (subject to point 5 of 5.2). So it's a bit like let-vs-where, or H98 data decls vs GADTs. Do we even need a firm "recommendation"? Simon On Fri, 1 Apr 2022 at 08:27, Simon Marlow wrote: > In the spirit of not accepting proposals that lead to language forks, it > would be great to get some clarification on the concerns that Arnaud raises > here: > > On Tue, 29 Mar 2022 at 16:02, Spiwack, Arnaud > wrote: > >> With the caveat that this proposal introduces quite a few extensions. And >> at this point, I'm still not quite sure what Richard recommends is the set >> of extensions that I should use (and I'm slightly dismayed that I believe >> that it will be a set of cardinal more than 1). I think this reflects a >> vision of extensions as switches to customise the behaviour of GHC. This >> vision, as I've stated before, is very alien to me: I see extensions as >> staging areas for features to become an integral part of Haskell. So I >> don't know what to think of all these extensions. I'm definitely not >> against splitting -XScopedTypeVariables into smaller components, if it is >> done so that they are reassembled in a different way in an alternative >> extension that would now be the recommended default (or at least is to >> become the next recommended default). >> > > I think we should express an opinion about the intended direction. Are we > advising that ExtendedForallScope is a dead end, because we want > TypeAbstraction? > > Cheers > Simon > > > >> >> Finally, there are Sections 6 to 8. These are entirely new. Though they >> are working towards the new principles (well, as far as I can tell, Section >> 6 doesn't contribute to the principles, but it is a stepping stone for both >> Sections 7 and 8). These sections are concerned with adding local >> let-bindings of type variables, in particular inside types and patterns. >> >> By the way, Section 7 proposes two syntaxes for let binders in patterns, >> and I *strongly* prefer the second syntax, which reads something like `f >> (let b = Bool) (True :: Bool) = …`. >> >> Anyway, these are new, I feel that they are a bit out of place in a >> proposal that is about tidying up the existing designs. That being said, >> they are here, and they seem like fairly uncontroversial to me, (except, >> probably the syntax `(let b = _)` to bind a variable to a type to be filled >> by the compiler). I'm fine with accepting these, though they may require a >> bit more scrutiny than the rest. >> >> Best, >> Arnaud >> >> _______________________________________________ >> ghc-steering-committee mailing list >> ghc-steering-committee at haskell.org >> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee >> > _______________________________________________ > ghc-steering-committee mailing list > ghc-steering-committee at haskell.org > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee > -------------- next part -------------- An HTML attachment was scrubbed... URL: From arnaud.spiwack at tweag.io Mon Apr 4 07:50:46 2022 From: arnaud.spiwack at tweag.io (Spiwack, Arnaud) Date: Mon, 4 Apr 2022 09:50:46 +0200 Subject: [ghc-steering-committee] Modern Scoped Type Variables #448: recommendation (mostly) accept In-Reply-To: References: Message-ID: On Mon, Apr 4, 2022 at 9:33 AM Simon Peyton Jones < simon.peytonjones at gmail.com> wrote: > So it's a bit like let-vs-where, or H98 data decls vs GADTs. Do we even > need a firm "recommendation"? > I think that there are two aspects to consider here, which make me think that: yes, we probably want a stronger form of recommendation (even in the extensions-are-switches-to-tune-GHC's-behaviour worldview) 1. Let and where, as well as the two syntaxes for data types are perfectly compatible with one another. You can use both at the same time, and people do. While ExtendedForAllScope and TypeAbstractions are at odds with each other. Granted, the proposal gives a semantics to having both of them on. But still, they are not good friends. So you probably actually don't want to mix them. This point is highlighted by the fact that the proposal makes ExtendedForAllScope an extension with the explicit purpose of being able to deactivate this behaviour. Nobody ever asked to deactivate lets or the Haskell 98 syntax for data types. 2. As the proposal stands it's easier to use ExtendedForAllScope than to use TypeAbstraction. Because you will usually use it in conjunction with ScopedTypeVariables, and ScopedTypeVariables implies the former but not the latter. Therefore, ExtendedForAllScope requires turning a single extension while TypeAbstractions requires two. Therefore, from the point of view of the programmer, ExtendedForAllScope will feel like more of a default choice. If we think that TypeAbstractions ought to be the default choice, then we need to make it at least as easy as ExtendedForAllScope. /Arnaud -------------- next part -------------- An HTML attachment was scrubbed... URL: From lists at richarde.dev Mon Apr 4 17:16:44 2022 From: lists at richarde.dev (Richard Eisenberg) Date: Mon, 4 Apr 2022 17:16:44 +0000 Subject: [ghc-steering-committee] Modern Scoped Type Variables #448: recommendation (mostly) accept In-Reply-To: References: Message-ID: <010f017ff5943161-0e13b9be-4338-4c43-b7b1-0b37350596a9-000000@us-east-2.amazonses.com> 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. 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: From marlowsd at gmail.com Mon Apr 4 19:38:44 2022 From: marlowsd at gmail.com (Simon Marlow) Date: Mon, 4 Apr 2022 20:38:44 +0100 Subject: [ghc-steering-committee] Modern Scoped Type Variables #448: recommendation (mostly) accept In-Reply-To: <010f017ff5943161-0e13b9be-4338-4c43-b7b1-0b37350596a9-000000@us-east-2.amazonses.com> References: <010f017ff5943161-0e13b9be-4338-4c43-b7b1-0b37350596a9-000000@us-east-2.amazonses.com> Message-ID: 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lists at richarde.dev Mon Apr 4 20:15:26 2022 From: lists at richarde.dev (Richard Eisenberg) Date: Mon, 4 Apr 2022 20:15:26 +0000 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> Message-ID: <010f017ff637ce47-49c9f372-360c-4aed-87b3-2f6a240d0d74-000000@us-east-2.amazonses.com> 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From marlowsd at gmail.com Tue Apr 5 13:43:35 2022 From: marlowsd at gmail.com (Simon Marlow) Date: Tue, 5 Apr 2022 14:43:35 +0100 Subject: [ghc-steering-committee] Modern Scoped Type Variables #448: recommendation (mostly) accept In-Reply-To: <010f017ff637ce47-49c9f372-360c-4aed-87b3-2f6a240d0d74-000000@us-east-2.amazonses.com> 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: 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 > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mail at joachim-breitner.de Thu Apr 7 09:15:51 2022 From: mail at joachim-breitner.de (Joachim Breitner) Date: Thu, 07 Apr 2022 11:15:51 +0200 Subject: [ghc-steering-committee] #425: invisible binders in type declarations; rec: accept In-Reply-To: <94d6346982d52e7b208e54060d4766b1cd49e486.camel@joachim-breitner.de> References: <010f017c9a6cb57b-e38b9e0a-f446-4435-8cb8-1cbf39b4861d-000000@us-east-2.amazonses.com> <010f017fbd4137d2-8baa4a75-360f-4195-9343-0e0ce10c3450-000000@us-east-2.amazonses.com> <94d6346982d52e7b208e54060d4766b1cd49e486.camel@joachim-breitner.de> Message-ID: <6aff5bc97dba7b69b430d5a2f327b41cce0704d6.camel@joachim-breitner.de> Hi, I didn’t hear any dissent, so I’ll mark this as accepted and will merge it now. Cheers, Joachim Am Samstag, dem 26.03.2022 um 16:10 +0100 schrieb Joachim Breitner: > Hi, > > sounds good to me, thanks for the good summary. > > Cheers, > Joachim > > Am Donnerstag, dem 24.03.2022 um 18:47 +0000 schrieb Richard Eisenberg: > > Hi committee, > > > > I re-recommend acceptance for this proposal. > > > > The main payload of the proposal is to allow definitions like > > > > > data Proxy @k (a :: k) = Proxy > > > > instead of today's > > > > > data Proxy (a :: k) = Proxy > > > > which has no explicit binding site for k. > > > > This new syntax solves a number of smallish syntax conundra, as very > > well outlined in the proposal. > > > > Along with this primary change, there is some cleanup of (loosely) > > related syntax: > >  - a type synonym declaration is now required to mention all kind > > variables on its left-hand side (previously, you could introduce a > > kind variable only on the right in some circumstances) > >  - arity inference for type synonyms and families with trailing > > invisible quantifiers is simplified (you've never written such a > > thing, I'm sure -- and yet GHC currently has special handling for > > this bit of esoterica) > >  - a type family equation must now mention all kind variables on its > > left-hand side (just like the new rule for type synonyms) > >  - a type family equation must now determine instantiation of all > > kind variables via the left-hand side patterns (this vastly increases > > readability and avoids some confusing behavior) > > > > The cleanups can all break existing code. And so I posted on > > Discourse seeking community feedback. The feedback did not suggest > > this breakage would cause wide harm. And thus this re-recommendation > > of acceptance. > > > > Please let us know what you think. I will go on holiday after April > > 4, so I hope to accept this proposal then. > > > > Thanks! > > Richard > > > > > > > On Oct 25, 2021, at 3:24 AM, Spiwack, Arnaud > > > wrote: > > > > > > My weak objections are no match for Simon's strong keenness :-) . > > > > > > I should say that, egoistically, I'd also like 5,6,7 to happen. I > > > was only expressing concerns about the price. > > > > > > On Fri, Oct 22, 2021 at 1:00 PM Simon Peyton Jones > > > wrote: > > > > I’m in strong support.  This tidies up the design nicely. > > > >   > > > > I am particularly keen on 5,6,7; indeed I wrote a whole proposal > > > > about it, which Vlad has #included here > > > >   > > > > https://github.com/ghc-proposals/ghc-proposals/pull/386 > > > >   > > > > Simon > > > >   > > > > PS: I am leaving Microsoft at the end of November 2021, at which > > > > pointsimonpj at microsoft.com will cease to work.  > > > > Usesimon.peytonjones at gmail.com instead.  (For now, it just > > > > forwards to simonpj at microsoft.com.) > > > >   > > > > From: ghc-steering-committee > > > > On Behalf Of Spiwack, > > > > Arnaud > > > > Sent: 21 October 2021 08:03 > > > > To: Richard Eisenberg > > > > Cc: ghc-steering-committee > > > > Subject: Re: [ghc-steering-committee] #425: invisible binders in > > > > type declarations; rec: accept > > > >   > > > > I'm generally in favour. But I'm not convinced that the secondary > > > > changes (points 4–7) are worth it. They are certainly better > > > > place than we are today, but are they worth breaking existing > > > > code for? Point 5–7 can probably be replaced by warnings. I don't > > > > know about 4. > > > >   > > > > On Tue, Oct 19, 2021 at 11:20 PM Richard Eisenberg > > > > wrote: > > > > > Hi all, > > > > > > > > > > I am the shepherd for proposal #425, > > > > > https://github.com/ghc-proposals/ghc-proposals/pull/425, > > > > > proposing to add invisible binders in type declarations. > > > > > > > > > > The main payload of the proposal is to allow definitions like > > > > > > > > > > > data Proxy @k (a :: k) = Proxy > > > > > > > > > > instead of today's > > > > > > > > > > > data Proxy (a :: k) = Proxy > > > > > > > > > > which has no explicit binding site for k. > > > > > > > > > > This new syntax solves a number of smallish syntax conundra, as > > > > > very well outlined in the proposal. > > > > > > > > > > In addition, the proposal includes two small unrelated tweaks > > > > > to the syntax of type family instances; these are points (6) > > > > > and (7) in the proposal. Both changes will break some obscure > > > > > (but still realistic, knowing Haskell) programs, but both fixes > > > > > are backward compatible. > > > > > > > > > > --- > > > > > > > > > > I recommend acceptance. The proposal is motivated nicely (do > > > > > check out the examples) and solves a real problem. The new > > > > > syntax fits in with other similar features. The small cleanups > > > > > to existing syntax will lead to better error messages. > > > > > > > > > > The one drawback, as I see it, is that this proposal includes > > > > > point (5), which is a breaking change to the way type synonyms > > > > > work. Right now, we can say > > > > > > > > > > > type P = (Proxy :: k -> Type) > > > > > > > > > > and GHC will infer P :: forall k. k -> Type. Under this > > > > > proposal, you would have to write > > > > > > > > > > > type P @k = (Proxy :: k -> Type) > > > > > > > > > > bringing k into scope explicitly. The fix is not backward > > > > > compatible, and so I think this proposal should come with a > > > > > migration strategy, where we warn about the former version for > > > > > some releases before banning it. (Continuing to support it is > > > > > possible, but it's very awkward to have a variable mentioned > > > > > only in a synonym's right-hand side.) > > > > > > > > > > Sorry for the delay in producing this recommendation! > > > > > Richard > > > > > _______________________________________________ > > > > > 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 > -- Joachim Breitner mail at joachim-breitner.de http://www.joachim-breitner.de/ From mail at joachim-breitner.de Thu Apr 7 09:26:50 2022 From: mail at joachim-breitner.de (Joachim Breitner) Date: Thu, 07 Apr 2022 11:26:50 +0200 Subject: [ghc-steering-committee] GHC Steering Committee Status Message-ID: <027c9e18e23d79d7e69e920bce11db36f04158e0.camel@joachim-breitner.de> Dear Committee, it’s about time for my ~monthly~ quarterly status update So what has happened since the last one? * We decided 7 proposals since then. That’s pretty good! * Simon suggested a better way to keep tabs on what’s going on, and you’ll find the second half of this mail at https://github.com/ghc-proposals/ghc-proposals/wiki/Status As before, I still didn’t get around to mess with markdown tables etc… Maybe I just don’t feel the itch enough. * Membership changes! Alejandro has stepped down, Vitaly rotated out and Baldur and Chris joined. Bladur and Chris, you have been quite quiet here so far. Make  yourself heard! * we were asked to review these proposals: #454: Custom type warnings (shepherd: Tom) #448: Modern Scoped Type Variables (shepherd: Arnaud) #270: Support pun-free code (resubmission; shepherd: Vitaly, later Chris) #475: New tuple and list syntax (resubmission; shepherd: Vlad) #277: Unicode ellipsis (shepherd: Joachim) * we have a recommendation from the shepherd about: #460: migration plan for non-magical-~ (rec: accept) #451: sized literals (rec: accept) #454: Custom type warnings (rec: accept) #475: New tuple and list syntax (rec: accept) #277: Unicode ellipsis (rec: accept) #425: invisible binders in type decls (rec: accept) #448: Modern Scoped Type Variables (rec: mostly accept) * we have sent the following proposals back to revision none, it seems * we decided about the following proposals #319: NoFallibleDo (reject) #392: Clarify modifiers design principle (accept) #460: migration plan for non-magical-~ (accept) #475: New tuple and list syntax (accept) #277: Unicode ellipsis (accept) #452: Articulate principles for GHC evolution (accept) #425: invisible binders in type declarations (accept) We currently have to act on the following 4 proposals, down by 2 since last update: ## Waiting for committee decision #451: Sized Literals, Shepherd: Simon M. 2022-01-11: Recommendation to accept by Simon Simon asked the committee for the color of the shed! Please all weigh in! #454: Custom type warnings, Shepherd: Tom 2022-01-13: Recommendation to accept There was contention (by Vlad) if the possible performance impact is too bad, with a bit of active discussion on Github #448: Modern Scoped Type Variables, Shepherd: Arnaud 2022-03-29: Arnaud makes a non-comprehensive recommendation Ongoing discussion about which parts should be accepted and which not (yet). Thanks Arnaud, for guiding the discussion. ## Waiting for Shepherd action #270: Support pun-free code, Shepherd: Chris 2022-01-01: Assigned to Chris Cheers, Joachim -- Joachim Breitner mail at joachim-breitner.de http://www.joachim-breitner.de/ From arnaud.spiwack at tweag.io Fri Apr 15 14:00:32 2022 From: arnaud.spiwack at tweag.io (Spiwack, Arnaud) Date: Fri, 15 Apr 2022 16:00:32 +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, 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 >> >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.peytonjones at gmail.com Mon Apr 18 07:51:06 2022 From: simon.peytonjones at gmail.com (Simon Peyton Jones) Date: Mon, 18 Apr 2022 08:51:06 +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'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 Fri Apr 22 06:37:59 2022 From: arnaud.spiwack at tweag.io (Spiwack, Arnaud) Date: Fri, 22 Apr 2022 08:37:59 +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: 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 marlowsd at gmail.com Sat Apr 23 12:14:42 2022 From: marlowsd at gmail.com (Simon Marlow) Date: Sat, 23 Apr 2022 13:14:42 +0100 Subject: [ghc-steering-committee] Please review #451: Sized literals proposal; Shepherd: Simon M In-Reply-To: References: <010f017d39ad63fd-db81ebeb-38ee-4325-bbf7-e7e8941d2f79-000000@us-east-2.amazonses.com> Message-ID: Just to wind this up: there was a vote on the github thread about syntax, and we ended up with `123#Int8` and `123#Word64`. There were no dissenting comments, so we can declare the proposal accepted. Cheers Simon On Tue, 11 Jan 2022 at 10:28, Simon Marlow wrote: > Dear committee, > > Proposal #451 is about adding syntax for sized unboxed literals. That is, > constants of type `Int8#`, `Word64#` and so on. The proposed syntax is > `123#i8` and `123#u64` for `Int8#` and `Word64#` respectively. > > I think we should accept the proposal, but in my opinion this might not be > the best choice of syntax. It was chosen to be consistent with Rust, but > it's a bit of an outlier in Haskell/GHC. I would probably choose `123#Int8` > and `123#Word64`. > > Feel free to comment on the github thread > https://github.com/ghc-proposals/ghc-proposals/pull/451 > > Cheers > Simon > > On Fri, 19 Nov 2021 at 19:30, Richard Eisenberg > wrote: > >> Dear Committee, >> >> This is your interim secretary speaking: >> >> Sized literals proposal, proposing syntax for literals for the new sized >> primitive numeric types, has been proposed by Sylvain Henry. >> >> https://github.com/ghc-proposals/ghc-proposals/pull/451 >> >> https://github.com/hsyl20/ghc-proposals/blob/sized-literals/proposals/0000-sized-literals.rst >> >> I propose Simon M as the shepherd. >> >> Please guide us to a conclusion as outlined in >> https://github.com/ghc-proposals/ghc-proposals#committee-process >> >> Thanks, >> Richard > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mail at joachim-breitner.de Sat Apr 23 12:44:57 2022 From: mail at joachim-breitner.de (Joachim Breitner) Date: Sat, 23 Apr 2022 14:44:57 +0200 Subject: [ghc-steering-committee] Please review #451: Sized literals proposal; Shepherd: Simon M In-Reply-To: References: <010f017d39ad63fd-db81ebeb-38ee-4325-bbf7-e7e8941d2f79-000000@us-east-2.amazonses.com> Message-ID: Great, merged. Am Samstag, dem 23.04.2022 um 13:14 +0100 schrieb Simon Marlow: > Just to wind this up: there was a vote on the github thread about > syntax, and we ended up with `123#Int8` and `123#Word64`. There were > no dissenting comments, so we can declare the proposal accepted. > > Cheers > Simon > > On Tue, 11 Jan 2022 at 10:28, Simon Marlow > wrote: > > Dear committee, > > > > Proposal #451 is about adding syntax for sized unboxed literals. > > That is, constants of type `Int8#`, `Word64#` and so on. The > > proposed syntax is `123#i8` and `123#u64` for `Int8#` and `Word64#` > > respectively. > > > > I think we should accept the proposal, but in my opinion this might > > not be the best choice of syntax. It was chosen to be consistent > > with Rust, but it's a bit of an outlier in Haskell/GHC. I would > > probably choose `123#Int8` and `123#Word64`. > > > > Feel free to comment on the github thread > > https://github.com/ghc-proposals/ghc-proposals/pull/451 > > > > Cheers > > Simon > > > > On Fri, 19 Nov 2021 at 19:30, Richard Eisenberg > > wrote: > > > Dear Committee, > > > > > > This is your interim secretary speaking: > > > > > > Sized literals proposal, proposing syntax for literals for the > > > new > > > sized primitive numeric types, has been proposed by Sylvain > > > Henry. > > > > > > https://github.com/ghc-proposals/ghc-proposals/pull/451 > > > https://github.com/hsyl20/ghc-proposals/blob/sized-literals/proposals/0000-sized-literals.rst > > > > > > I propose Simon M as the shepherd. > > > > > > Please guide us to a conclusion as outlined in > > > https://github.com/ghc-proposals/ghc-proposals#committee-process > > > > > > Thanks, > > > Richard > _______________________________________________ > 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/