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

Yes, thankyou Richard! I agree with virtually everything.

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.

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.

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

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? 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. 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. Cheers Simon On Tue, 13 Dec 2022 at 09:43, Arnaud Spiwack wrote:

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 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@joachim-breitner.de http://www.joachim-breitner.de/

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee