[ghc-steering-committee] Why not?, rather than, why?

[Joachim Breitner]

Hi,

this categorization is very helpful, I’ve been thinking about that as
well recently. Especially it’s worth keeping in mind that some language
extensions probably wouldn’t be language extensions these days, but
some other kind of flag (CPP, Safe, Trustworthy), and as you say
shouldn’t get in the way of finding a more coherent story for the
others.

I think we should keep separate the category

F: Enables new language features with not just a local (usually)
syntactic effect. (Litmus test: will a user of a module with that
extension tell). Mostly all the type-level feature extension (GADTs,
LinearTypes, TypeFamilies etc.)

Some of these are also guarded by “new syntax” of sorts, but I think
they are fundamentally different from your category A. These are, in a
way, the most interesting ones!

Cheers,
Joachim

Am Freitag, dem 09.12.2022 um 14:21 +0000 schrieb Richard Eisenberg:
> Glancing through the list of extensions, I see a few broad
> categories:
> 
> A. Extensions that simply enable new syntax. If users still want fine
> control over whether this syntax is allowed, each such extension
> could be converted to a warning -- but then all these extensions
> (except ones that are still experimental!) would be on by default.
> Maybe the warnings would be -Werror by default -- not sure. Examples:
> GADTSyntax, Arrows, InstanceSigs, StandaloneDeriving, and many more.
> 
> 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.
> 
> (*): Given the hue and cry about this one, perhaps there should be a
> flag to control the behavior.
> 
> C. Extensions that change the compilation pipeline. These need to
> remain as configuration flags. Examples: CPP, TemplateHaskell.
> 
> 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.
> 
> Maybe some extensions fail to be categorized here, but this covers
> the vast, vast majority.

-- 
Joachim Breitner
  mail at joachim-breitner.de
  http://www.joachim-breitner.de/