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

[Simon Marlow]

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.

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?

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

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 <arnaud.spiwack at tweag.io>
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 <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
>>
> _______________________________________________
> 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/20221214/addbbc30/attachment.html>