<div dir="ltr"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="gmail_default" style="font-family:tahoma,sans-serif">
Thanks Richard for answering more comprehensively than I could have done
myself. Simon: do you feel that Richard's email answers your question?
</div></blockquote><div><br></div><div style="font-family:tahoma,sans-serif" class="gmail_default">It contributes to an answer. <br></div><div style="font-family:tahoma,sans-serif" class="gmail_default"><br></div><div style="font-family:tahoma,sans-serif" class="gmail_default"><b>The problem(s) we seek to solve</b></div><div style="font-family:tahoma,sans-serif" class="gmail_default"><br></div><div style="font-family:tahoma,sans-serif" class="gmail_default">Richard says</div><div style="font-family:tahoma,sans-serif" class="gmail_default"><br></div><div style="font-family:tahoma,sans-serif" class="gmail_default">We, as a committee, struggle to figure out a policy around extensions. This policy would help inform decisions such as:<div> * whether proposal X needs to come with an extension, can modify a previous one, or needs no extension at all</div><div> * how to evolve the set of extensions that are part of GHC20XX / the default set of extensions</div><div>Beyond these real-world challenges that the committee has faced, we might also want to consider</div><div> *
how better to communicate the role extensions play in the Haskell
language (anecdotes suggest the current story is off-putting to
newcomers)</div><div> * whether some extensions ought to be retired</div><div><br></div><div>I'm OK with those as goals, although I have not found myself stuck on them. E.g. most proposals do come with an extension because they are, well, an extension. And user opinions frankly differ about the value and tempo of GHC20XX.<br></div><div><br></div><div><b>The proposed solution(s)</b></div><div><br></div><div>Richard comes up with a couple of categorisations, which are indeed helpful. But he stops short of any concrete proposals.</div><div><br></div><div>
<div>1. Declare that extensions are <b>experimental language features</b>,
being evaluated for inclusion in the language proper. Gating some new
syntax behind an extension theoretically allows us to experiment,
improve, etc., until we are happy, and then we merge the feature into
the language, with no extension needed.</div><div>2. Declare that
extensions are <b>configuration flags</b>, meant to exist in perpetuity. In
this way, extensions are a more powerful form of warning flag: not only
can they dictate which programs are accepted, but sometimes they can be
used to change the semantics of an accepted program.</div><div>3. Organize the set of extensions around an idea of <b><i>language levels</i></b><span style="font-style:normal">, where we classify different extensions according to the expected level of expertise of users working in the extended language.</span></div><div><span style="font-style:normal"><br></span></div><div><span style="font-style:normal">These aren't either/or choices. It's clear that <br></span></div><div><ul><li><span style="font-style:normal">some really are configuration flags (Safe, RebindableSyntax; maybe punning)<br></span></li><li><span style="font-style:normal">some are definitely local, thin ice (UndecidableSuperclasses) -- the more we can turn these into local modifiers the better</span></li><li><span style="font-style:normal">some are really part of the language we'd like to see (PolyKinds, MultiParamTypeClasses)</span></li><li><span style="font-style:normal">some are experimental in the "Haskell as a laboratory" sense (Linear)</span></li></ul><div>I think that <i>classifying </i>them might be helpful; <i>choosing one </i>of these paths over the others seems infeasible to me.</div><div><br></div></div></div><div><b>What next?</b></div><div><br></div><div>I suppose the next step is for some motivated person to write a draft policy paper, so we can say "This is the GHC steering committee's policy on extensions". Maybe it too can be a GHC proposal (rather like the design principles one). It can certainly include the categorisations Richard suggests.<br></div><div><br></div><div>Simon<br></div><div><br></div><div><br></div>
</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, 13 Dec 2022 at 09:43, Arnaud Spiwack <<a href="mailto:arnaud.spiwack@tweag.io">arnaud.spiwack@tweag.io</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Thanks Richard for answering more comprehensively than I could have done myself. Simon: do you feel that Richard's email answers your question?<br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, 9 Dec 2022 at 19:57, Joachim Breitner <<a href="mailto:mail@joachim-breitner.de" target="_blank">mail@joachim-breitner.de</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi,<br>
<br>
this categorization is very helpful, I’ve been thinking about that as<br>
well recently. Especially it’s worth keeping in mind that some language<br>
extensions probably wouldn’t be language extensions these days, but<br>
some other kind of flag (CPP, Safe, Trustworthy), and as you say<br>
shouldn’t get in the way of finding a more coherent story for the<br>
others.<br>
<br>
I think we should keep separate the category<br>
<br>
F: Enables new language features with not just a local (usually)<br>
syntactic effect. (Litmus test: will a user of a module with that<br>
extension tell). Mostly all the type-level feature extension (GADTs,<br>
LinearTypes, TypeFamilies etc.)<br>
<br>
Some of these are also guarded by “new syntax” of sorts, but I think<br>
they are fundamentally different from your category A. These are, in a<br>
way, the most interesting ones!<br>
<br>
Cheers,<br>
Joachim<br>
<br>
Am Freitag, dem 09.12.2022 um 14:21 +0000 schrieb Richard Eisenberg:<br>
> Glancing through the list of extensions, I see a few broad<br>
> categories:<br>
> <br>
> A. Extensions that simply enable new syntax. If users still want fine<br>
> control over whether this syntax is allowed, each such extension<br>
> could be converted to a warning -- but then all these extensions<br>
> (except ones that are still experimental!) would be on by default.<br>
> Maybe the warnings would be -Werror by default -- not sure. Examples:<br>
> GADTSyntax, Arrows, InstanceSigs, StandaloneDeriving, and many more.<br>
> <br>
> B. Extensions that allow violation of some general principle that<br>
> holds elsewhere. These should be replaced by modifiers or pragmas and<br>
> be enabled locally. Examples: OverlappingInstances (this is already<br>
> done!), NoMonomorphismRestriction, DeepSubsumption(*),<br>
> UndecidableSuperClasses, NoMonoLocalBinds, etc.<br>
> <br>
> (*): Given the hue and cry about this one, perhaps there should be a<br>
> flag to control the behavior.<br>
> <br>
> C. Extensions that change the compilation pipeline. These need to<br>
> remain as configuration flags. Examples: CPP, TemplateHaskell.<br>
> <br>
> D. Extensions that create variants of the language by changing<br>
> semantics of existing constructs. I'm not quite sure what to do with<br>
> these, but they probably need to remain configuration flags. Even<br>
> better if they could be enabled locally within a file, though. We<br>
> should probably try to avoid doing this in the future, though the<br>
> pain may be worth it. Examples: RebindableSyntax, Strict,<br>
> OverloadedXXX, etc.<br>
> <br>
> Maybe some extensions fail to be categorized here, but this covers<br>
> the vast, vast majority.<br>
<br>
-- <br>
Joachim Breitner<br>
<a href="mailto:mail@joachim-breitner.de" target="_blank">mail@joachim-breitner.de</a><br>
<a href="http://www.joachim-breitner.de/" rel="noreferrer" target="_blank">http://www.joachim-breitner.de/</a><br>
<br>
_______________________________________________<br>
ghc-steering-committee mailing list<br>
<a href="mailto:ghc-steering-committee@haskell.org" target="_blank">ghc-steering-committee@haskell.org</a><br>
<a href="https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee" rel="noreferrer" target="_blank">https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee</a><br>
</blockquote></div>
_______________________________________________<br>
ghc-steering-committee mailing list<br>
<a href="mailto:ghc-steering-committee@haskell.org" target="_blank">ghc-steering-committee@haskell.org</a><br>
<a href="https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee" rel="noreferrer" target="_blank">https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee</a><br>
</blockquote></div>