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

[Simon Peyton Jones]

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

It contributes to an answer.

*The problem(s) we seek to solve*

Richard says

We, as a committee, struggle to figure out a policy around extensions. This
policy would help inform decisions such as:
 * whether proposal X needs to come with an extension, can modify a
previous one, or needs no extension at all
 * how to evolve the set of extensions that are part of GHC20XX / the
default set of extensions
Beyond these real-world challenges that the committee has faced, we might
also want to consider
 * how better to communicate the role extensions play in the Haskell
language (anecdotes suggest the current story is off-putting to newcomers)
 * whether some extensions ought to be retired

I'm OK with those as goals, although I have not found myself stuck on
them.  E.g. most proposals do come with an extension because they are,
well, an extension.   And user opinions frankly differ about the value and
tempo of GHC20XX.

*The proposed solution(s)*

Richard comes up with a couple of categorisations, which are indeed
helpful.  But he stops short of any concrete proposals.

1. Declare that extensions are *experimental language features*, being
evaluated for inclusion in the language proper. Gating some new syntax
behind an extension theoretically allows us to experiment, improve, etc.,
until we are happy, and then we merge the feature into the language, with
no extension needed.
2. Declare that extensions are *configuration flags*, meant to exist in
perpetuity. In this way, extensions are a more powerful form of warning
flag: not only can they dictate which programs are accepted, but sometimes
they can be used to change the semantics of an accepted program.
3. Organize the set of extensions around an idea of *language levels*,
where we classify different extensions according to the expected level of
expertise of users working in the extended language.

These aren't either/or choices.   It's clear that

   - some really are configuration flags (Safe, RebindableSyntax; maybe
   punning)
   - some are definitely local, thin ice (UndecidableSuperclasses) -- the
   more we can turn these into local modifiers the better
   - some are really part of the language we'd like to see (PolyKinds,
   MultiParamTypeClasses)
   - some are experimental in the "Haskell as a laboratory" sense (Linear)

I think that *classifying *them might be helpful; *choosing one *of these
paths over the others seems infeasible to me.

*What next?*

I suppose the next step is for some motivated person to write a draft
policy paper, so we can say "This is the GHC steering committee's policy on
extensions".  Maybe it too can be a GHC proposal (rather like the design
principles one).  It can certainly include the categorisations Richard
suggests.

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/20221213/15dec179/attachment-0001.html>