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

[Arnaud Spiwack]

Thanks Richard for answering more comprehensively than I could have done
myself. Simon: do you feel that Richard's email answers your question?

On Fri, 9 Dec 2022 at 19:57, Joachim Breitner <mail at joachim-breitner.de>
wrote:

> 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/
>
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20221213/480ebf1f/attachment.html>