
<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">Thanks for reminding us of that definition in our review criteria -- it's helpful.<div class=""><br class=""></div><div class="">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:</div><div class=""> - PatternSignatures</div><div class=""> - PatternSignatureBinds</div><div class=""> - MethodTypeVariables (though John Ericson makes a comment on GitHub which suggests that this, too, may want revision -- I'm not fully convinced yet)</div><div class=""> - ImplicitForAll</div><div class=""> - TypeAbstractions</div><div class="">(and ExtendedLet, but that's not being debated at the moment)</div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">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.)</div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">Richard</div><div class=""><div><br class=""><blockquote type="cite" class=""><div class="">On Apr 4, 2022, at 3:38 PM, Simon Marlow <<a href="mailto:marlowsd@gmail.com" class="">marlowsd@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta charset="UTF-8" class=""><div dir="ltr" style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 14px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;" class=""><div dir="ltr" class="">On Mon, 4 Apr 2022 at 18:17, Richard Eisenberg <<a href="mailto:lists@richarde.dev" class="">lists@richarde.dev</a>> wrote:<br class=""></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-style: solid; border-left-color: rgb(204, 204, 204); padding-left: 1ex;"><div style="overflow-wrap: break-word;" class="">Thanks for kicking off this conversation, Arnaud!<div class=""><br class=""></div><div class="">To be clear in this thread: I'm fine delaying the discussion of section 6-8 until later.</div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">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:</div><div class=""> - 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!).</div><div class=""> - RebindableSyntax (though this is not one to mimic)</div><div class=""> - MagicHash. My interpretation is that this extension is meant to allow users to explicitly opt into low-level code.</div><div class=""> - Recently accepted <a href="https://github.com/ghc-proposals/ghc-proposals/pull/285" target="_blank" class="">#285</a>, which introduces two new -XNo... extensions (both also included in #448).</div><div class="">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.</div></div></blockquote><div class=""><br class=""></div><div class="">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":<span class="Apple-converted-space"> </span><a href="https://github.com/ghc-proposals/ghc-proposals#review-criteria" class="">https://github.com/ghc-proposals/ghc-proposals#review-criteria</a><span class="Apple-converted-space"> </span>. 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.<br class=""><div class=""><br class=""></div></div></div><div class="gmail_quote"><div class="">Does that apply in this case? Well, perhaps the extensions are not technically incompatible, but they're "at odds" as Arnaud puts it.<br class=""></div><div class=""><br class=""></div><div class="">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?<br class=""></div><div class=""><br class=""></div><div class="">I'm not expressing a preference one way or the other, just that we should decide where this is going.</div><div class=""><br class=""></div><div class="">Cheers</div><div class="">Simon<br class=""></div><div class=""><br class=""></div><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-style: solid; border-left-color: rgb(204, 204, 204); padding-left: 1ex;"><div style="overflow-wrap: break-word;" class=""><div class="">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 <a href="https://github.com/goldfirere/ghc-proposals/blob/type-variables/proposals/0448-type-variable-scoping.rst#58alternatives" target="_blank" class="">optional extra</a> 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).</div><div class=""><br class=""></div><div class="">Richard</div><div class=""><br class=""></div><div class="">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.</div></div>_______________________________________________<br class="">ghc-steering-committee mailing list<br class=""><a href="mailto:ghc-steering-committee@haskell.org" target="_blank" class="">ghc-steering-committee@haskell.org</a><br class=""><a href="https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee" rel="noreferrer" target="_blank" class="">https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee</a></blockquote></div></div></div></blockquote></div><br class=""></div></body></html>