<div dir="ltr"><div>Yes, thankyou Richard! I agree with virtually everything.</div><div><div><br></div><div>> B. Extensions that allow violation of some general principle that 
holds elsewhere. These should be replaced by modifiers or pragmas and be
 enabled locally. Examples: OverlappingInstances (this is already 
done!), NoMonomorphismRestriction, DeepSubsumption(*), 
UndecidableSuperClasses, NoMonoLocalBinds, etc.</div><div><br></div><div>I think it's worth making a further distinction according to whether the relaxation is thought to be unsound or not-well-founded for some reason (NoMonoLocalBinds, DeepSubsumption) and those that are well understood and not problematic at all (NoMonomorphismRestriction). The latter should just be treated like the syntax extensions: either experimental or enabled by default.</div><div><br></div><div><div>> C. Extensions that change the compilation pipeline. These need to remain as configuration flags. Examples: CPP, TemplateHaskell.</div><div><br></div><div>It's clear that CPP needs to remain as a flag because it does bad things to the syntax like breaking multiline strings and doing strange things to `##`. But it's less clear to me that TemplateHaskell is in this category. Isn't it just an extension that enables new syntax? Yes there are *practical* reasons why we might not want it on by default, because it makes compilation slower and whatnot, but isn't that all it is?<br></div></div></div><div><br></div><div>> D. Extensions that create variants of the language by changing 
semantics of existing constructs. I'm not quite sure what to do with 
these, but they probably need to remain configuration flags. Even better
 if they could be enabled locally within a file, though. We should 
probably try to avoid doing this in the future, though the pain may be 
worth it. Examples: RebindableSyntax, Strict, OverloadedXXX, etc.</div><div><br></div><div>Again I think we could refine this. Clearly RebindableSyntax and Strict are not features that we would ever want to be on by default, but OverloadedStrings definitely is, and for me belongs in the category of language extensions that are either in GHC20xx now or will be later.</div><div><br></div><div>Cheers</div><div>Simon<br></div><div><br></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>