<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">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>