From mail at joachim-breitner.de  Sat Apr  1 12:39:56 2023
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Sat, 01 Apr 2023 14:39:56 +0200
Subject: [ghc-steering-committee] =?utf-8?q?Language_Extension_Policy_?=
 =?utf-8?b?4oCTIFJvdW5kIDEn?=
In-Reply-To: <CAGwnsnmHG5mTn9w6-ab-5ZynA1d=k_3vge7t2Dfo1b3LuripMA@mail.gmail.com>
References: <CAGwnsnmHG5mTn9w6-ab-5ZynA1d=k_3vge7t2Dfo1b3LuripMA@mail.gmail.com>
Message-ID: <a54ddb998ade000c98b0e220d60c3f552436e232.camel@joachim-breitner.de>

Hi,

thanks for your work of clearing the mist.

Am Donnerstag, dem 30.03.2023 um 11:03 +0200 schrieb Arnaud Spiwack:
> 1. Have we missed some use-cases, if so describe? (I'm sure we have,
>    so I'd be surprised if nothing turns up here)

Another reason, mostly for completeness, is

   X. Programmers use extensions to _refer_ to a particular feature
   when talking/writing/searching about it. They give names to concepts
   that might not have an obvious canonical name otherwise.

Imagine LambdaCase did not have that name; it would be slightly harder
to talk about it.

---

Since your point 1 has an explicit list of reasons why an extension is
no on by default (“experimental or unstable”, with the word “early”
signaling that this status is expected to change)

I wonder if we need more points for “Developer wants access to features
not on-by-default for some other reasons”. In fact, you list some more
reasons (4/5 – deprecated, 7 – not backward compatible, 8 – perf
impact), but the list seems incomplete.

For example RecordWildCards doesn’t seem to be experimental, unstable,
deprecated or perf impacting to me. Nor does UnicodeSyntax.

So it’s not clear to me if you meant to put them under 1 (and
“experimental and unstable” needs to be extended) or under extra
bullets.

>From a user-point of view, it seems you could possible merge 1, 4, 5,
6, 7 and 8 as “Developer wants access to features not on by default”.
The developer probably doesn’t really care _why_ the extension is not
on by default, they just want to use it when they want to use it :). 

And then the question of why an extension is not on by default
(present, past, future…) would be separate from that.

Cheers,
Joachim





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


From marlowsd at gmail.com  Tue Apr  4 16:25:45 2023
From: marlowsd at gmail.com (Simon Marlow)
Date: Tue, 4 Apr 2023 16:25:45 +0000
Subject: [ghc-steering-committee] =?utf-8?q?Language_Extension_Policy_?=
	=?utf-8?b?4oCTIFJvdW5kIDEn?=
In-Reply-To: <CAGwnsnmHG5mTn9w6-ab-5ZynA1d=k_3vge7t2Dfo1b3LuripMA@mail.gmail.com>
References: <CAGwnsnmHG5mTn9w6-ab-5ZynA1d=k_3vge7t2Dfo1b3LuripMA@mail.gmail.com>
Message-ID: <CANsrgP+K1hCMLNfU_-gqYD+mabGSOhaycACJTmBJzWZb7xvEUA@mail.gmail.com>

I don't disagree with any of that. Not entirely sure where we're going...
but sure :)

Anyway, I suspect that number 7 includes more things than it might seem, if
we're really strict about backwards compatibility. Several extensions steal
some syntax, whether it's just keywords or other symbols, that will cause
code that uses the new keyword to be rejected. Just picking a few at
random: RecursiveDo, Arrows, PatternSynonyms.

Indeed while poking around I noticed some bugs

Prelude> :set -XNoRoleAnnotations
Prelude> let x :: role

<interactive>:35:10: error: parse error on input ‘role’

Cheers
Simon

On Thu, 30 Mar 2023 at 10:04, Arnaud Spiwack <arnaud.spiwack at tweag.io>
wrote:

> Dear all,
>
> Sorry for the long silence. I was named and shamed by Joachim the
> other day, which is fair enough. I've basically disappeared from my
> email for a while. I am aware that not having solved this is holding
> us back, I'll be more consistent in the future.
>
> As I said in my last email, I'd like to start the conversation again
> from the point of view of use-cases, as proposed by Adam, and see if
> it helps us go forward. What I want to do, today, is to describe what
> Haskell programmers have been using extension for. This is meant to be
> purely a description, without judgement on whether the proposed
> use-cases are good ideas. When the use-cases are listed, we'll turn to
> which we want to support and how.
>
> Without further ado, here is a list of use-cases, based on Adam's list
> (my rephrasing), with additions by me. Haskell programmers use
> extensions to:
>
> 1. Gain early access to experimental or unstable features
>    (e.g. because they're working on a research prototype, or because
>    the feature is valuable enough to them to forgo some stability)
> 2. Restrict the use of more complex features (e.g. for easier
>    onboarding of new developers or as educators to teach a
>    well-delimited subset of the language)
> 3. As library authors, to signal which features the library actually
>    uses, hence which version of GHC the library is compatible with.
> 4. Retain access to deprecated features to smooth out migration over
>    the deprecation period.
> 5. Retain access to deprecated features indefinitely.
> 6. Change the default behaviour of (part of) the language
>    (e.g. StrictData, I think some of the dependent Haskell work falls
>    in this category, but I can't pinpoint an example)
> 7. Extend the language in a way that is not backward compatible
>    (e.g. OverloadedList, probably some dependent Haskell things too)
> 8. Enable features whose mere presence has a performance impact
>    (e.g. Template Haskell, and that's probably it)
> 9. CPP (this one is very unique isn't it?)
>
>
> (Note: Adam proposed some use-cases which are not included here: using
> extension to ensure stability (which is the contrapositive of 1), and
> as a GHC dev, make features available to early adopters (which is the
> dual of 1). I didn't include them because I consider that they are
> contained in 1, but if you disagree, please argue otherwise)
>
> Questions:
> 1. Have we missed some use-cases, if so describe? (I'm sure we have,
>    so I'd be surprised if nothing turns up here)
> 2. Do you think some of the use-cases above should be split into
>    several use-cases?
> 3. Conversely, are there distinctions that don't make sense to you and
>    you would argue should be merged?
>
> Before answering, take note that while some of the proposed use-cases
> can be seen as a list of extensions that behave a certain way, some
> extensions may be used in several use-cases (4 and 5, by definition
> concern the same set of extensions), some use-cases (like 3) are
> independent of the behaviour of extensions. This is not a
> classification of extension, but of how they are consumed.
>
> I'll tally the result on Tuesday 10th April.
>
> Best,
> Arnaud
> _______________________________________________
> 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/20230404/99653f91/attachment.html>

From mail at joachim-breitner.de  Thu Apr  6 17:38:35 2023
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Thu, 06 Apr 2023 19:38:35 +0200
Subject: [ghc-steering-committee]  Please review#575: Deprecated instances,
 Shepherd: Moritz
Message-ID: <80c507d8881529024bb910763a64870c2ddd466a.camel@joachim-breitner.de>

Dear Committee,

Vlad proposes adding support for Deprecating Instances.

https://github.com/ghc-proposals/ghc-proposals/pull/575
https://github.com/int-index/ghc-proposals/blob/int-index/deprecated-instances/proposals/0000-deprecated-instances.rst

I’m assigning this to Moritz as the shepherd.

Please guide us to a conclusion as outlined in 
https://github.com/ghc-proposals/ghc-proposals#committee-process


Cheers,
Joachim






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


From moritz.angermann at gmail.com  Fri Apr  7 01:47:31 2023
From: moritz.angermann at gmail.com (Moritz Angermann)
Date: Fri, 7 Apr 2023 09:47:31 +0800
Subject: [ghc-steering-committee] Please review#575: Deprecated
 instances, Shepherd: Moritz
In-Reply-To: <80c507d8881529024bb910763a64870c2ddd466a.camel@joachim-breitner.de>
References: <80c507d8881529024bb910763a64870c2ddd466a.camel@joachim-breitner.de>
Message-ID: <CAKfdd-zbAikXOpBdE5nRWirEEWq1yUEPDi7GAZs7UkcQXGBbWg@mail.gmail.com>

Hi,

I’m on vacation until the 17th. Will get back this when I get back.

Cheers
  Moritz

On Fri, 7 Apr 2023 at 1:38 AM, Joachim Breitner <mail at joachim-breitner.de>
wrote:

> Dear Committee,
>
> Vlad proposes adding support for Deprecating Instances.
>
> https://github.com/ghc-proposals/ghc-proposals/pull/575
>
> https://github.com/int-index/ghc-proposals/blob/int-index/deprecated-instances/proposals/0000-deprecated-instances.rst
>
> I’m assigning this to Moritz as the shepherd.
>
> Please guide us to a conclusion as outlined in
> https://github.com/ghc-proposals/ghc-proposals#committee-process
>
>
> Cheers,
> Joachim
>
>
>
>
>
>
> --
> 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/20230407/fae6cc82/attachment.html>

From arnaud.spiwack at tweag.io  Fri Apr  7 11:50:00 2023
From: arnaud.spiwack at tweag.io (Arnaud Spiwack)
Date: Fri, 7 Apr 2023 13:50:00 +0200
Subject: [ghc-steering-committee] =?utf-8?q?Language_Extension_Policy_?=
	=?utf-8?b?4oCTIFJvdW5kIDEn?=
In-Reply-To: <CANsrgP+K1hCMLNfU_-gqYD+mabGSOhaycACJTmBJzWZb7xvEUA@mail.gmail.com>
References: <CAGwnsnmHG5mTn9w6-ab-5ZynA1d=k_3vge7t2Dfo1b3LuripMA@mail.gmail.com>
 <CANsrgP+K1hCMLNfU_-gqYD+mabGSOhaycACJTmBJzWZb7xvEUA@mail.gmail.com>
Message-ID: <CAGwnsnmNW1OxsMb4TVXYLA4sSGZaT8OS2MBNwHdTxW94Xcwr5A@mail.gmail.com>

👋

I see that this hasn't sparked a lot of discussion, I hope it means we're
finally finding some common ground that we agree is meaningful.

I said that I'd tally the result on “Tuesday 10th” in my initial email.
Turns out, the 10th is a Monday. As it's a bank holiday for me, the tally
will be Tuesday 11th, and you'll hear more from me a couple of days later.


On Tue, 4 Apr 2023 at 18:25, Simon Marlow <marlowsd at gmail.com> wrote:

> I don't disagree with any of that. Not entirely sure where we're going...
> but sure :)
>
> Anyway, I suspect that number 7 includes more things than it might seem,
> if we're really strict about backwards compatibility. Several extensions
> steal some syntax, whether it's just keywords or other symbols, that will
> cause code that uses the new keyword to be rejected. Just picking a few at
> random: RecursiveDo, Arrows, PatternSynonyms.
>
> Indeed while poking around I noticed some bugs
>
> Prelude> :set -XNoRoleAnnotations
> Prelude> let x :: role
>
> <interactive>:35:10: error: parse error on input ‘role’
>
> Cheers
> Simon
>
> On Thu, 30 Mar 2023 at 10:04, Arnaud Spiwack <arnaud.spiwack at tweag.io>
> wrote:
>
>> Dear all,
>>
>> Sorry for the long silence. I was named and shamed by Joachim the
>> other day, which is fair enough. I've basically disappeared from my
>> email for a while. I am aware that not having solved this is holding
>> us back, I'll be more consistent in the future.
>>
>> As I said in my last email, I'd like to start the conversation again
>> from the point of view of use-cases, as proposed by Adam, and see if
>> it helps us go forward. What I want to do, today, is to describe what
>> Haskell programmers have been using extension for. This is meant to be
>> purely a description, without judgement on whether the proposed
>> use-cases are good ideas. When the use-cases are listed, we'll turn to
>> which we want to support and how.
>>
>> Without further ado, here is a list of use-cases, based on Adam's list
>> (my rephrasing), with additions by me. Haskell programmers use
>> extensions to:
>>
>> 1. Gain early access to experimental or unstable features
>>    (e.g. because they're working on a research prototype, or because
>>    the feature is valuable enough to them to forgo some stability)
>> 2. Restrict the use of more complex features (e.g. for easier
>>    onboarding of new developers or as educators to teach a
>>    well-delimited subset of the language)
>> 3. As library authors, to signal which features the library actually
>>    uses, hence which version of GHC the library is compatible with.
>> 4. Retain access to deprecated features to smooth out migration over
>>    the deprecation period.
>> 5. Retain access to deprecated features indefinitely.
>> 6. Change the default behaviour of (part of) the language
>>    (e.g. StrictData, I think some of the dependent Haskell work falls
>>    in this category, but I can't pinpoint an example)
>> 7. Extend the language in a way that is not backward compatible
>>    (e.g. OverloadedList, probably some dependent Haskell things too)
>> 8. Enable features whose mere presence has a performance impact
>>    (e.g. Template Haskell, and that's probably it)
>> 9. CPP (this one is very unique isn't it?)
>>
>>
>> (Note: Adam proposed some use-cases which are not included here: using
>> extension to ensure stability (which is the contrapositive of 1), and
>> as a GHC dev, make features available to early adopters (which is the
>> dual of 1). I didn't include them because I consider that they are
>> contained in 1, but if you disagree, please argue otherwise)
>>
>> Questions:
>> 1. Have we missed some use-cases, if so describe? (I'm sure we have,
>>    so I'd be surprised if nothing turns up here)
>> 2. Do you think some of the use-cases above should be split into
>>    several use-cases?
>> 3. Conversely, are there distinctions that don't make sense to you and
>>    you would argue should be merged?
>>
>> Before answering, take note that while some of the proposed use-cases
>> can be seen as a list of extensions that behave a certain way, some
>> extensions may be used in several use-cases (4 and 5, by definition
>> concern the same set of extensions), some use-cases (like 3) are
>> independent of the behaviour of extensions. This is not a
>> classification of extension, but of how they are consumed.
>>
>> I'll tally the result on Tuesday 10th April.
>>
>> Best,
>> Arnaud
>> _______________________________________________
>> 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/20230407/b2f32138/attachment.html>

From chris at chrisdornan.com  Fri Apr  7 15:32:49 2023
From: chris at chrisdornan.com (Chris Dornan)
Date: Fri, 7 Apr 2023 16:32:49 +0100
Subject: [ghc-steering-committee] =?utf-8?q?Language_Extension_Policy_?=
 =?utf-8?b?4oCTIFJvdW5kIDEn?=
In-Reply-To: <CAGwnsnmHG5mTn9w6-ab-5ZynA1d=k_3vge7t2Dfo1b3LuripMA@mail.gmail.com>
References: <CAGwnsnmHG5mTn9w6-ab-5ZynA1d=k_3vge7t2Dfo1b3LuripMA@mail.gmail.com>
Message-ID: <B08F8090-D35E-4F2E-8D58-5913B4375828@chrisdornan.com>

As Joachim says, "Programmers use extensions to _refer_ to a particular feature  when talking/writing/searching about it."

I think this is generally important. The language reports provide the foundations for understanding the language and it is important to have a handle to describe the various departures from it -- at least until a new report around which near universal acceptance can be established. 

I would extend "2. Restrict the use of more complex features" to say "2. Restrict the use of _novel_ and more complex features".  I think many just want to say exactly how they are departing from Haskell 2010, whether those deltas are complex or otherwise.

Chris 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20230407/08685b22/attachment.html>

From mail at joachim-breitner.de  Tue Apr 11 19:19:43 2023
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Tue, 11 Apr 2023 21:19:43 +0200
Subject: [ghc-steering-committee] Please review #585: Amend Or Patterns,
	Shepherd: Richard
Message-ID: <94a5e04997d530e290eb821abbe7d4f838c5c3f4.camel@joachim-breitner.de>

Dear Committee,

David Knothe proposes to amend the Or Patterns proposal:

https://github.com/ghc-proposals/ghc-proposals/pull/585

Since Richard shepherded the original proposal, I’d like to ask him to
shepherd this one too.

Please guide us to a conclusion as outlined in 
https://github.com/ghc-proposals/ghc-proposals#committee-process

Thanks,
Joachim








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


From lists at richarde.dev  Wed Apr 12 21:49:02 2023
From: lists at richarde.dev (Richard Eisenberg)
Date: Wed, 12 Apr 2023 21:49:02 +0000
Subject: [ghc-steering-committee] Please review #585: Amend Or Patterns,
 Shepherd: Richard
In-Reply-To: <94a5e04997d530e290eb821abbe7d4f838c5c3f4.camel@joachim-breitner.de>
References: <94a5e04997d530e290eb821abbe7d4f838c5c3f4.camel@joachim-breitner.de>
Message-ID: <010f0187777189f4-dab280e5-731c-4885-9a60-10bee2794109-000000@us-east-2.amazonses.com>

I've posted on GitHub. Not quite ready to make a recommendation here, as I'm seeking further feedback.

Richard

> On Apr 11, 2023, at 3:19 PM, Joachim Breitner <mail at joachim-breitner.de> wrote:
> 
> Dear Committee,
> 
> David Knothe proposes to amend the Or Patterns proposal:
> 
> https://github.com/ghc-proposals/ghc-proposals/pull/585
> 
> Since Richard shepherded the original proposal, I’d like to ask him to
> shepherd this one too.
> 
> Please guide us to a conclusion as outlined in 
> https://github.com/ghc-proposals/ghc-proposals#committee-process
> 
> Thanks,
> Joachim
> 
> 
> 
> 
> 
> 
> 
> 
> -- 
> 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


From arnaud.spiwack at tweag.io  Mon Apr 17 07:02:16 2023
From: arnaud.spiwack at tweag.io (Arnaud Spiwack)
Date: Mon, 17 Apr 2023 09:02:16 +0200
Subject: [ghc-steering-committee] =?utf-8?q?Language_Extension_Policy_?=
	=?utf-8?b?4oCTIFJvdW5kIDEn?=
In-Reply-To: <B08F8090-D35E-4F2E-8D58-5913B4375828@chrisdornan.com>
References: <CAGwnsnmHG5mTn9w6-ab-5ZynA1d=k_3vge7t2Dfo1b3LuripMA@mail.gmail.com>
 <B08F8090-D35E-4F2E-8D58-5913B4375828@chrisdornan.com>
Message-ID: <CAGwnsnn3h6jN48bkLbA6vt9bYcxW-vPisNfDOMhfOzhXU2ygBg@mail.gmail.com>

(sorry, it's been a busy week, next email thread comes out today, or
tomorrow at the latest)

Joachim:

> From a user-point of view, it seems you could possible merge 1, 4, 5,
> 6, 7 and 8 as “Developer wants access to features not on by default”.
> The developer probably doesn’t really care _why_ the extension is not
> on by default, they just want to use it when they want to use it :).
>

At the end of the day, an extension is either a feature that is off by
default and can be turned on, or on by default and can be turned off. I
don't think we've said much when we've reduced the users' behaviour to that
level. So I wanted this list to be specifically about the why. And I think
the users do care. GHC Proposals say “I want a new extension to support X”,
I wanted to be as exhaustive as possible to then be able to try and then
delineate the X-s that we intend language extensions to support.

On Fri, 7 Apr 2023 at 17:33, Chris Dornan <chris at chrisdornan.com> wrote:

> As Joachim says, "Programmers use extensions to _refer_ to a particular
> feature  when talking/writing/searching about it."
>
> I think this is generally important. The language reports provide the
> foundations for understanding the language and it is important to have a
> handle to describe the various departures from it -- at least until a new
> report around which near universal acceptance can be established.
>
> I would extend "2. Restrict the use of more complex features" to say "2.
> Restrict the use of _novel_ and more complex features".  I think many just
> want to say exactly how they are departing from Haskell 2010, whether those
> deltas are complex or otherwise.
>
> Chris
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20230417/88bc2837/attachment.html>

From arnaud.spiwack at tweag.io  Tue Apr 18 09:51:10 2023
From: arnaud.spiwack at tweag.io (Arnaud Spiwack)
Date: Tue, 18 Apr 2023 11:51:10 +0200
Subject: [ghc-steering-committee] =?utf-8?q?Language_Extension_Policy_?=
	=?utf-8?b?4oCTIFJvdW5kIDEn?=
In-Reply-To: <CAGwnsnn3h6jN48bkLbA6vt9bYcxW-vPisNfDOMhfOzhXU2ygBg@mail.gmail.com>
References: <CAGwnsnmHG5mTn9w6-ab-5ZynA1d=k_3vge7t2Dfo1b3LuripMA@mail.gmail.com>
 <B08F8090-D35E-4F2E-8D58-5913B4375828@chrisdornan.com>
 <CAGwnsnn3h6jN48bkLbA6vt9bYcxW-vPisNfDOMhfOzhXU2ygBg@mail.gmail.com>
Message-ID: <CAGwnsnmNiWZNgyX=pnKqLFn9HY-DLaY56YX89-uU7RU-622hjg@mail.gmail.com>

While I'm typing my next round of questions, and based on the feedback in
this thread, here is the list of use-cases that I could gather.

1. Gain early access to experimental or unstable features
   (e.g. because they're working on a research prototype, or because
   the feature is valuable enough to them to forgo some stability)
2. Restrict the use of more complex features (e.g. for easier
   onboarding of new developers or as educators to teach a
   well-delimited subset of the language)
3. Restrict the use of novel features since the last established
   standard/report.
4. Restrict the use to features that they don't like (e.g. controversial
   features like RecordWildcard or ImplicitParameters)
5. Name/refer to a particular feature when talking/writing/searching
   about it.
6. Restrict the use of features which require support from outside
   the Haskell ecosystem that can't be taken for granted (I think this
   concerns only UnicodeSyntax)
7. As library authors, to signal which features the library actually
   uses, hence which version of GHC the library is compatible with.
8. Retain access to deprecated features to smooth out migration over
   the deprecation period.
9. Retain access to deprecated features indefinitely.
10. Change the default behaviour of (part of) the language
    (e.g. StrictData, I think some of the dependent Haskell work falls
    in this category, but I can't pinpoint an example)
11. Extend the language in a way that is not backward compatible
    (e.g. OverloadedList, probably some dependent Haskell things too)
12. Enable features whose mere presence has a performance impact
    (e.g. Template Haskell, and that's probably it)
13. CPP (this one is very unique isn't it?)

On Mon, 17 Apr 2023 at 09:02, Arnaud Spiwack <arnaud.spiwack at tweag.io>
wrote:

> (sorry, it's been a busy week, next email thread comes out today, or
> tomorrow at the latest)
>
> Joachim:
>
>> From a user-point of view, it seems you could possible merge 1, 4, 5,
>> 6, 7 and 8 as “Developer wants access to features not on by default”.
>> The developer probably doesn’t really care _why_ the extension is not
>> on by default, they just want to use it when they want to use it :).
>>
>
> At the end of the day, an extension is either a feature that is off by
> default and can be turned on, or on by default and can be turned off. I
> don't think we've said much when we've reduced the users' behaviour to that
> level. So I wanted this list to be specifically about the why. And I think
> the users do care. GHC Proposals say “I want a new extension to support X”,
> I wanted to be as exhaustive as possible to then be able to try and then
> delineate the X-s that we intend language extensions to support.
>
> On Fri, 7 Apr 2023 at 17:33, Chris Dornan <chris at chrisdornan.com> wrote:
>
>> As Joachim says, "Programmers use extensions to _refer_ to a particular
>> feature  when talking/writing/searching about it."
>>
>> I think this is generally important. The language reports provide the
>> foundations for understanding the language and it is important to have a
>> handle to describe the various departures from it -- at least until a new
>> report around which near universal acceptance can be established.
>>
>> I would extend "2. Restrict the use of more complex features" to say "2.
>> Restrict the use of _novel_ and more complex features".  I think many just
>> want to say exactly how they are departing from Haskell 2010, whether those
>> deltas are complex or otherwise.
>>
>> Chris
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20230418/3b84881d/attachment.html>

From arnaud.spiwack at tweag.io  Wed Apr 19 12:20:35 2023
From: arnaud.spiwack at tweag.io (Arnaud Spiwack)
Date: Wed, 19 Apr 2023 14:20:35 +0200
Subject: [ghc-steering-committee] =?utf-8?q?Language_Extension_Policy_?=
	=?utf-8?b?4oCTIFJvdW5kIDI=?=
Message-ID: <CAGwnsnkY39xPChb5a=ESM0-WtXRDz=9dk+RDqGUCJE0=6vpH4g@mail.gmail.com>

Dear all,

In Round 1', we have gathered no less than 13 use-cases (see below)
found in the community for Haskellers to motivate the need for
extensions. Some of these use-cases are specific to a pretty definite
list of extensions, some are not. Some extensions fall squarely in one
use-case, some don't. Use-cases are not a classification of
extensions, they're a classification of justifications for extensions
to exist. Surely we've missed some, but it's alright to not be fully
exhaustive.

In this next round, I want us to give our opinion, on each of these
use-cases, on whether we believe that this use-case is best served by
extension. My goal, in this round, is not necessarily to build
consensus for a policy, but to discover where there is consensus, and
where there is controversy, so that we can discuss the relevant
use-cases in more detail.

In this round, I'm asking you, for each X∈{1,…,13}, to answer the
following questions:

X.1: do you believe that this a use-case that GHC should support? (yes/no)
X.2: regardless of your answer in X.1, if GHC supports this use-case,
  do you believe that this use-case is best served by extensions. (yes/no)
X.2.Y: Do you believe that GHC20xx helps support this use-case (yes/no)
X.2.N: if you've answered “no” to X.2: what mechanism would you rather
  see supporting this use-case (free form)

I'll be on holiday next week, and will tally the results on the first
week on May.

The 13 use-cases are

1. Gain early access to experimental or unstable features
   (e.g. because they're working on a research prototype, or because
   the feature is valuable enough to them to forgo some stability)
2. Restrict the use of more complex features (e.g. for easier
   onboarding of new developers or as educators to teach a
   well-delimited subset of the language)
3. Restrict the use of novel features since the last established
   standard/report.
4. Restrict the use to features that they don't like (e.g. controversial
   features like RecordWildcard or ImplicitParameters)
5. Name/refer to a particular feature when talking/writing/searching
   about it.
6. Restrict the use of features which require support from outside
   the Haskell ecosystem that can't be taken for granted (I think this
   concerns only UnicodeSyntax)
7. As library authors, to signal which features the library actually
   uses, hence which version of GHC the library is compatible with.
8. Retain access to deprecated features to smooth out migration over
   the deprecation period.
9. Retain access to deprecated features indefinitely.
10. Change the default behaviour of (part of) the language
    (e.g. StrictData, I think some of the dependent Haskell work falls
    in this category, but I can't pinpoint an example)
11. Extend the language in a way that is not backward compatible
    (e.g. OverloadedList, probably some dependent Haskell things too)
12. Enable features whose mere presence has a performance impact
    (e.g. Template Haskell, and that's probably it)
13. CPP (this one is very unique isn't it?)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20230419/6a4174c3/attachment.html>

From mail at joachim-breitner.de  Thu Apr 20 09:41:56 2023
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Thu, 20 Apr 2023 11:41:56 +0200
Subject: [ghc-steering-committee] =?utf-8?q?Language_Extension_Policy_?=
 =?utf-8?b?4oCTIFJvdW5kIDI=?=
In-Reply-To: <CAGwnsnkY39xPChb5a=ESM0-WtXRDz=9dk+RDqGUCJE0=6vpH4g@mail.gmail.com>
References: <CAGwnsnkY39xPChb5a=ESM0-WtXRDz=9dk+RDqGUCJE0=6vpH4g@mail.gmail.com>
Message-ID: <aec3f84ed4eb6a7761679fbc7e80937ded7bc0e4.camel@joachim-breitner.de>

Hi,

Am Mittwoch, dem 19.04.2023 um 14:20 +0200 schrieb Arnaud Spiwack:
> The 13 use-cases are
> 
> 1. Gain early access to experimental or unstable features
>    (e.g. because they're working on a research prototype, or because
>    the feature is valuable enough to them to forgo some stability)

1: Yes, worthwhile usecase.
2: Yes, Extensions serve this well.
2Y: By definition GHC20xx doesn’t help, because it doesn’t touch
experimental or unstable features.

> 2. Restrict the use of more complex features (e.g. for easier
>    onboarding of new developers or as educators to teach a
>    well-delimited subset of the language)

1: No, I don’t think that’s a task that the compiler is necessary best
suited for. At least not at the current “accidential” complexity – if
there was a push for real language levels as a first-class, well
designed feature, things would be different.

2: No. They kinda work, but maybe warning flags are more suitable.

2N: Waring flags or, maybe better, external tools (hlint).

> 3. Restrict the use of novel features since the last established
>    standard/report.

1: Yes, worthwhile to support. Although I’d phrase it dually: It’s
worthwhile for GHC to support, in addition to “current GHC Haskell”,
the standardized dialects.

2: Yes, kinda.
2Y: Yes, at least in the general sense that GHC20xx, like Haskell2021,
selects a language dialect alltogether, instead of having to turn off
and on individual flags.

> 4. Restrict the use to features that they don't like (e.g.
> controversial
>    features like RecordWildcard or ImplicitParameters)

Same answers as for 2.

> 5. Name/refer to a particular feature when talking/writing/searching
>    about it.

1: Yes, very useful to have names for things!

2: I’m unsure. The extension names work quite well. But if this would
be come an actively supported use-case (rather than an accidential
one), should we come up with names for existing things as well?
(-XWhereBindings). It doens’t seem to be a good idea to couple “well-
identified feature with a clear name” and “compiler flag”

> 6. Restrict the use of features which require support from outside
>    the Haskell ecosystem that can't be taken for granted (I think
> this
>    concerns only UnicodeSyntax)

Again similar to 2. I don’t see anything wrong with GHC just accepting
unicode syntax when it encounters them, just like it accepts non-ASCII
variable names.

(This is independent of whether GHC should print syntax in Unicode
style unless asked to do it, but that’s not a language design
question.)

> 7. As library authors, to signal which features the library actually
>    uses, hence which version of GHC the library is compatible with.


1: Yes, useful.

2: Possibly, but that would require a more defined story about
backwards compatibility within an extension. Can we change extensions?
Or only those that are somehow labeled to be more stable?

2Y: It could help if “being in GHC20xx” is used as a proxy for “kinda
stable”, which is a prerequisite for this signallingto work reliably.

2N: That said, I don’t see much benefit of using this indirect compat
signalling over just stating in the library which GHC versions it is
known to work with, just like we do with library dependencies.

> 8. Retain access to deprecated features to smooth out migration over
>    the deprecation period.

1: Yes, useful. Similar to question 3

2: Yes
2Y: Yes, by using an older GHC20xx one pins an older feature set,
possibly including deprecated versions. This decouples “upgrading GHC”
and “adopting the code base to the new dialect”, which should make life
easier for developers.

> 9. Retain access to deprecated features indefinitely.

1: Unsure. Depends on how commonly used it is, and how expensive it is
to carry around.

> 10. Change the default behaviour of (part of) the language
>     (e.g. StrictData, I think some of the dependent Haskell work
> falls
>     in this category, but I can't pinpoint an example)

1: I’m leaning to say no. Haskell + StrictData is a different language,
and one that we can’t envision to be the default (I’d say). That use
case should ideally be addressed in a different way that is a language
extension, not a language change.

2: No
2N: Annotations maybe, or a new keyword?

> 11. Extend the language in a way that is not backward compatible
>     (e.g. OverloadedList, probably some dependent Haskell things too)

1: Strong yes. Barring ourselves from making changes that may affect
some existing programs is no longer avoiding success at all costs.

2: Yes
2Y: Yes, definitely: It means that the programmer is in control when to
apply a change like OverloadedStrings which may require some code
changes.

> 12. Enable features whose mere presence has a performance impact
>     (e.g. Template Haskell, and that's probably it)

1: Yes.

2: No, a dedicated pragma would probably be cleaner, but willing to
entertain that single odd case.

It would also be more consistent to always _parse_ the TH syntax (to
avoid breakage when it is enabled, and to make reading code less
ambiguous), and simply fail if the pragma is not set given.


> 13. CPP (this one is very unique isn't it?)

1: Yes
2: Again, dedicated pragma might be cleaner. Also helps programs
parsing Haskell programs if the information is _always_ local in the
file.




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


From eric at seidel.io  Sat Apr 22 17:09:28 2023
From: eric at seidel.io (Eric Seidel)
Date: Sat, 22 Apr 2023 13:09:28 -0400
Subject: [ghc-steering-committee] =?utf-8?q?Language_Extension_Policy_?=
 =?utf-8?b?4oCTIFJvdW5kIDI=?=
In-Reply-To: <CAGwnsnkY39xPChb5a=ESM0-WtXRDz=9dk+RDqGUCJE0=6vpH4g@mail.gmail.com>
References: <CAGwnsnkY39xPChb5a=ESM0-WtXRDz=9dk+RDqGUCJE0=6vpH4g@mail.gmail.com>
Message-ID: <57b6448b-5131-4552-bdfe-b0dd8bf05abe@app.fastmail.com>

On Wed, Apr 19, 2023, at 08:20, Arnaud Spiwack wrote:
> 1. Gain early access to experimental or unstable features
>    (e.g. because they're working on a research prototype, or because
>    the feature is valuable enough to them to forgo some stability)

I think this is a valid use case for extensions. I don't see a connection with GHC20xx and I think that's good -- GHC20xx is supposed to be about stable features.


> 2. Restrict the use of more complex features (e.g. for easier
>    onboarding of new developers or as educators to teach a
>    well-delimited subset of the language)
> 3. Restrict the use of novel features since the last established
>    standard/report.
> 4. Restrict the use to features that they don't like (e.g. controversial
>    features like RecordWildcard or ImplicitParameters)
> 6. Restrict the use of features which require support from outside
>    the Haskell ecosystem that can't be taken for granted (I think this
>    concerns only UnicodeSyntax)

(I don't see a useful distinction between these categories, answering all together.)

Yes, GHC (or at least the broader ecosystem) should support these use-cases. I think they might be better served by linters or warnings, but the features are complex enough that it may make sense to bundle the lints with GHC rather than defer to external tools.


> 5. Name/refer to a particular feature when talking/writing/searching
>    about it.

No, this is not a valid use case. The Haskell Standard and the GHC User Guide can name features without introducing a formal extension for them. Algebraic Data Types and Lambdas are two examples of core named language features that do not have associated extensions.


> 7. As library authors, to signal which features the library actually
>    uses, hence which version of GHC the library is compatible with.

No, this is not a valid use case. We already have metadata in Cabal files to indicate GHC compatibility.


> 8. Retain access to deprecated features to smooth out migration over
>    the deprecation period.
> 9. Retain access to deprecated features indefinitely.

(Again, same use-case.)

No, these are not valid use-cases. We have existing deprecation mechanisms that should be preferred here. (And there's no such thing as an indefinite deprecation period. That would mean you're still supporting the feature.)


> 10. Change the default behaviour of (part of) the language
>     (e.g. StrictData, I think some of the dependent Haskell work falls
>     in this category, but I can't pinpoint an example)
> 11. Extend the language in a way that is not backward compatible
>     (e.g. OverloadedList, probably some dependent Haskell things too)
> 12. Enable features whose mere presence has a performance impact
>     (e.g. Template Haskell, and that's probably it)
> 13. CPP (this one is very unique isn't it?)

(This might be more controversial, but I think these are also all the same use-case, which I would dub "Change the language in a way that will never become the default".)

Yes, these are valid use-cases. But, many existing cases of this use targeted pragmas (e.g. OVERLAPPING) rather than module-level extensions. I think both should be allowed, but the targeted version is preferred unless you really do want to change the behavior module-wide.

From arnaud.spiwack at tweag.io  Wed Apr 26 11:00:00 2023
From: arnaud.spiwack at tweag.io (Arnaud Spiwack)
Date: Wed, 26 Apr 2023 13:00:00 +0200
Subject: [ghc-steering-committee] =?utf-8?q?Language_Extension_Policy_?=
	=?utf-8?b?4oCTIFJvdW5kIDI=?=
In-Reply-To: <aec3f84ed4eb6a7761679fbc7e80937ded7bc0e4.camel@joachim-breitner.de>
References: <CAGwnsnkY39xPChb5a=ESM0-WtXRDz=9dk+RDqGUCJE0=6vpH4g@mail.gmail.com>
 <aec3f84ed4eb6a7761679fbc7e80937ded7bc0e4.camel@joachim-breitner.de>
Message-ID: <CAGwnsnnPbcc8sYgqXEkqCRH-2uS9UzSQdcZV8Lh09AzwetgkVA@mail.gmail.com>

Dear all,

I'm currently on holiday. I've scheduled this email to be sent before I
left. Remember to vote if you haven't voted yet: I'll be back next week and
tally the results some time during said week. Let me take the opportunity
to send in my votes.

1.1: yes
1.2: yes
1.2.Y: yes: extensions rolled in GHC20xx are clearly marked as no longer
experimental. GHC20xx can have a stronger policy for backward compatibility
clearly marking extensions which are at risk of making non-forward
compatible code.

2.1: no
2.2: no
2.2.N: I think I'd push such code-style rules into a linter

3.1: no I think that the report has lost relevance in practice. Nobody is
willing to come up with the next version, and GHC20xx has taken its place
3.2: yes
3.2.Y: no, I'd say GHC20xx embodies the opposite of this use-case

4.1: no
4.2: no
4.2.N: like (2), I'd rather use a linter

5.1: yes
5.2: no
5.2.N: I'd name things in the manual. Actually, this is something Haskell
has historically been rather good at.

6.1: yes for those who can't be avoided (e.g. printing unicode, but not
parsing unicode)
6.2: no
6.2.N: It should simply be a flag. E.g. for printing unicode in error
messages this is something that you may want to configure globally for your
machine rather than for a project.

7.1: yes
7.2: no, though extensions have proved decent at it, so not a hill I would
die on
7.2.N: version bounds seem to me sufficient, and since they are still
necessary, I don't see why we would need to pay attention to this aspect in
the design of extensions.

8.1: yes
8.2: yes
8.2.Y: yes. As I imagine that pegging to a particular GHC20xx version would
keep the deprecated feature going.

9.1: no, though I admit it can be argued.
9.2: yes
9.2.Y: yes, if we keep support GHC20xx version indefinitely we'd de facto
keep deprecated behaviour indefinitely.

10.1: no
10.2: yes. Not that I think that extensions are a good way to do this, but
I can't think of a better way.
10.2.Y: no

11.1: yes
11.2: yes
11.2.Y: yes, as these extensions can eventually become the standard
behaviour.

12.1: yes
12.2: yes
12.2.Y: no

13.1: no (but this is obviously a ship that has long sailed)
13.2: yes
13.2.Y: no

On Thu, 20 Apr 2023 at 11:42, Joachim Breitner <mail at joachim-breitner.de>
wrote:

> Hi,
>
> Am Mittwoch, dem 19.04.2023 um 14:20 +0200 schrieb Arnaud Spiwack:
> > The 13 use-cases are
> >
> > 1. Gain early access to experimental or unstable features
> >    (e.g. because they're working on a research prototype, or because
> >    the feature is valuable enough to them to forgo some stability)
>
> 1: Yes, worthwhile usecase.
> 2: Yes, Extensions serve this well.
> 2Y: By definition GHC20xx doesn’t help, because it doesn’t touch
> experimental or unstable features.
>
> > 2. Restrict the use of more complex features (e.g. for easier
> >    onboarding of new developers or as educators to teach a
> >    well-delimited subset of the language)
>
> 1: No, I don’t think that’s a task that the compiler is necessary best
> suited for. At least not at the current “accidential” complexity – if
> there was a push for real language levels as a first-class, well
> designed feature, things would be different.
>
> 2: No. They kinda work, but maybe warning flags are more suitable.
>
> 2N: Waring flags or, maybe better, external tools (hlint).
>
> > 3. Restrict the use of novel features since the last established
> >    standard/report.
>
> 1: Yes, worthwhile to support. Although I’d phrase it dually: It’s
> worthwhile for GHC to support, in addition to “current GHC Haskell”,
> the standardized dialects.
>
> 2: Yes, kinda.
> 2Y: Yes, at least in the general sense that GHC20xx, like Haskell2021,
> selects a language dialect alltogether, instead of having to turn off
> and on individual flags.
>
> > 4. Restrict the use to features that they don't like (e.g.
> > controversial
> >    features like RecordWildcard or ImplicitParameters)
>
> Same answers as for 2.
>
> > 5. Name/refer to a particular feature when talking/writing/searching
> >    about it.
>
> 1: Yes, very useful to have names for things!
>
> 2: I’m unsure. The extension names work quite well. But if this would
> be come an actively supported use-case (rather than an accidential
> one), should we come up with names for existing things as well?
> (-XWhereBindings). It doens’t seem to be a good idea to couple “well-
> identified feature with a clear name” and “compiler flag”
>
> > 6. Restrict the use of features which require support from outside
> >    the Haskell ecosystem that can't be taken for granted (I think
> > this
> >    concerns only UnicodeSyntax)
>
> Again similar to 2. I don’t see anything wrong with GHC just accepting
> unicode syntax when it encounters them, just like it accepts non-ASCII
> variable names.
>
> (This is independent of whether GHC should print syntax in Unicode
> style unless asked to do it, but that’s not a language design
> question.)
>
> > 7. As library authors, to signal which features the library actually
> >    uses, hence which version of GHC the library is compatible with.
>
>
> 1: Yes, useful.
>
> 2: Possibly, but that would require a more defined story about
> backwards compatibility within an extension. Can we change extensions?
> Or only those that are somehow labeled to be more stable?
>
> 2Y: It could help if “being in GHC20xx” is used as a proxy for “kinda
> stable”, which is a prerequisite for this signallingto work reliably.
>
> 2N: That said, I don’t see much benefit of using this indirect compat
> signalling over just stating in the library which GHC versions it is
> known to work with, just like we do with library dependencies.
>
> > 8. Retain access to deprecated features to smooth out migration over
> >    the deprecation period.
>
> 1: Yes, useful. Similar to question 3
>
> 2: Yes
> 2Y: Yes, by using an older GHC20xx one pins an older feature set,
> possibly including deprecated versions. This decouples “upgrading GHC”
> and “adopting the code base to the new dialect”, which should make life
> easier for developers.
>
> > 9. Retain access to deprecated features indefinitely.
>
> 1: Unsure. Depends on how commonly used it is, and how expensive it is
> to carry around.
>
> > 10. Change the default behaviour of (part of) the language
> >     (e.g. StrictData, I think some of the dependent Haskell work
> > falls
> >     in this category, but I can't pinpoint an example)
>
> 1: I’m leaning to say no. Haskell + StrictData is a different language,
> and one that we can’t envision to be the default (I’d say). That use
> case should ideally be addressed in a different way that is a language
> extension, not a language change.
>
> 2: No
> 2N: Annotations maybe, or a new keyword?
>
> > 11. Extend the language in a way that is not backward compatible
> >     (e.g. OverloadedList, probably some dependent Haskell things too)
>
> 1: Strong yes. Barring ourselves from making changes that may affect
> some existing programs is no longer avoiding success at all costs.
>
> 2: Yes
> 2Y: Yes, definitely: It means that the programmer is in control when to
> apply a change like OverloadedStrings which may require some code
> changes.
>
> > 12. Enable features whose mere presence has a performance impact
> >     (e.g. Template Haskell, and that's probably it)
>
> 1: Yes.
>
> 2: No, a dedicated pragma would probably be cleaner, but willing to
> entertain that single odd case.
>
> It would also be more consistent to always _parse_ the TH syntax (to
> avoid breakage when it is enabled, and to make reading code less
> ambiguous), and simply fail if the pragma is not set given.
>
>
> > 13. CPP (this one is very unique isn't it?)
>
> 1: Yes
> 2: Again, dedicated pragma might be cleaner. Also helps programs
> parsing Haskell programs if the information is _always_ local in the
> file.
>
>
>
>
> Cheers,
> Joachim
> --
> 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/20230426/76c3eae3/attachment.html>

From simon.peytonjones at gmail.com  Wed Apr 26 12:23:20 2023
From: simon.peytonjones at gmail.com (Simon Peyton Jones)
Date: Wed, 26 Apr 2023 13:23:20 +0100
Subject: [ghc-steering-committee] =?utf-8?q?Language_Extension_Policy_?=
	=?utf-8?b?4oCTIFJvdW5kIDI=?=
In-Reply-To: <CAGwnsnkY39xPChb5a=ESM0-WtXRDz=9dk+RDqGUCJE0=6vpH4g@mail.gmail.com>
References: <CAGwnsnkY39xPChb5a=ESM0-WtXRDz=9dk+RDqGUCJE0=6vpH4g@mail.gmail.com>
Message-ID: <CAJKmMz8j1X2izs3aGO_-tBFj65hAi_7MX029FL6StRtG2AppHw@mail.gmail.com>

>
> In this next round, I want us to give our opinion, on each of these
> use-cases, on whether we believe that this use-case is best served by
> extension. My goal, in this round, is not necessarily to build
> consensus for a policy, but to discover where there is consensus, and
> where there is controversy, so that we can discuss the relevant
> use-cases in more detail.
>


I went down the list and in every case I thought "yes, language extensions
allow a user to do this, if they want".   I struggled to answer your
questions.  Eg

   - X1 is this a use-case GHC should support.  Well it already supports
   it.   I suppose we could debate which are active goals and which are
   accidental, but before burning the midnight oil on that debate I'd love to
   know where this is going.
   - X2 is this use case best served by extensions.  When you say "best
   served" you imply that, in each case, there is a well-defined alternative
   or alternatives that could be better.  But I don't know what are the
   alternatives that we should be comparing with.
   - X3 Does GHC20xx help?  What do you mean by "GHC20xx".  I think you
   mean "The occasional release of a new flag, GHC2025, say, that implies a
   bunch of others.   That seems a rather different debate, but in general I
   think the idea is a good one, if not done too frequently

I feel as if I'm not being very helpful, which probably means I'm missing
the point somehow!


Simon

On Wed, 19 Apr 2023 at 13:21, Arnaud Spiwack <arnaud.spiwack at tweag.io>
wrote:

> Dear all,
>
> In Round 1', we have gathered no less than 13 use-cases (see below)
> found in the community for Haskellers to motivate the need for
> extensions. Some of these use-cases are specific to a pretty definite
> list of extensions, some are not. Some extensions fall squarely in one
> use-case, some don't. Use-cases are not a classification of
> extensions, they're a classification of justifications for extensions
> to exist. Surely we've missed some, but it's alright to not be fully
> exhaustive.
>
> In this next round, I want us to give our opinion, on each of these
> use-cases, on whether we believe that this use-case is best served by
> extension. My goal, in this round, is not necessarily to build
> consensus for a policy, but to discover where there is consensus, and
> where there is controversy, so that we can discuss the relevant
> use-cases in more detail.
>
> In this round, I'm asking you, for each X∈{1,…,13}, to answer the
> following questions:
>
> X.1: do you believe that this a use-case that GHC should support? (yes/no)
> X.2: regardless of your answer in X.1, if GHC supports this use-case,
>   do you believe that this use-case is best served by extensions. (yes/no)
> X.2.Y: Do you believe that GHC20xx helps support this use-case (yes/no)
> X.2.N: if you've answered “no” to X.2: what mechanism would you rather
>   see supporting this use-case (free form)
>
> I'll be on holiday next week, and will tally the results on the first
> week on May.
>
> The 13 use-cases are
>
> 1. Gain early access to experimental or unstable features
>    (e.g. because they're working on a research prototype, or because
>    the feature is valuable enough to them to forgo some stability)
> 2. Restrict the use of more complex features (e.g. for easier
>    onboarding of new developers or as educators to teach a
>    well-delimited subset of the language)
> 3. Restrict the use of novel features since the last established
>    standard/report.
> 4. Restrict the use to features that they don't like (e.g. controversial
>    features like RecordWildcard or ImplicitParameters)
> 5. Name/refer to a particular feature when talking/writing/searching
>    about it.
> 6. Restrict the use of features which require support from outside
>    the Haskell ecosystem that can't be taken for granted (I think this
>    concerns only UnicodeSyntax)
> 7. As library authors, to signal which features the library actually
>    uses, hence which version of GHC the library is compatible with.
> 8. Retain access to deprecated features to smooth out migration over
>    the deprecation period.
> 9. Retain access to deprecated features indefinitely.
> 10. Change the default behaviour of (part of) the language
>     (e.g. StrictData, I think some of the dependent Haskell work falls
>     in this category, but I can't pinpoint an example)
> 11. Extend the language in a way that is not backward compatible
>     (e.g. OverloadedList, probably some dependent Haskell things too)
> 12. Enable features whose mere presence has a performance impact
>     (e.g. Template Haskell, and that's probably it)
> 13. CPP (this one is very unique isn't it?)
> _______________________________________________
> 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/20230426/7c07a65d/attachment-0001.html>

From chris at chrisdornan.com  Wed Apr 26 13:32:30 2023
From: chris at chrisdornan.com (Chris Dornan)
Date: Wed, 26 Apr 2023 14:32:30 +0100
Subject: [ghc-steering-committee] =?utf-8?q?Language_Extension_Policy_?=
 =?utf-8?b?4oCTIFJvdW5kIDI=?=
In-Reply-To: <CAJKmMz8j1X2izs3aGO_-tBFj65hAi_7MX029FL6StRtG2AppHw@mail.gmail.com>
References: <CAGwnsnkY39xPChb5a=ESM0-WtXRDz=9dk+RDqGUCJE0=6vpH4g@mail.gmail.com>
 <CAJKmMz8j1X2izs3aGO_-tBFj65hAi_7MX029FL6StRtG2AppHw@mail.gmail.com>
Message-ID: <F27917B1-CED7-4C68-A9AF-BB317C31FAD5@chrisdornan.com>

I agree with Simon. These all seem entirely reasonable ways of using the compiler to me.

Chris  

> On 26 Apr 2023, at 13:23, Simon Peyton Jones <simon.peytonjones at gmail.com> wrote:
> 
>> In this next round, I want us to give our opinion, on each of these
>> use-cases, on whether we believe that this use-case is best served by
>> extension. My goal, in this round, is not necessarily to build
>> consensus for a policy, but to discover where there is consensus, and
>> where there is controversy, so that we can discuss the relevant
>> use-cases in more detail. 
> 
> 
> I went down the list and in every case I thought "yes, language extensions allow a user to do this, if they want".   I struggled to answer your questions.  Eg 
> X1 is this a use-case GHC should support.  Well it already supports it.   I suppose we could debate which are active goals and which are accidental, but before burning the midnight oil on that debate I'd love to know where this is going.  
> X2 is this use case best served by extensions.  When you say "best served" you imply that, in each case, there is a well-defined alternative or alternatives that could be better.  But I don't know what are the alternatives that we should be comparing with.
> X3 Does GHC20xx help?  What do you mean by "GHC20xx".  I think you mean "The occasional release of a new flag, GHC2025, say, that implies a bunch of others.   That seems a rather different debate, but in general I think the idea is a good one, if not done too frequently
> I feel as if I'm not being very helpful, which probably means I'm missing the point somehow!
> 
> 
> Simon
> 
> On Wed, 19 Apr 2023 at 13:21, Arnaud Spiwack <arnaud.spiwack at tweag.io <mailto:arnaud.spiwack at tweag.io>> wrote:
>> Dear all,
>> 
>> In Round 1', we have gathered no less than 13 use-cases (see below)
>> found in the community for Haskellers to motivate the need for
>> extensions. Some of these use-cases are specific to a pretty definite
>> list of extensions, some are not. Some extensions fall squarely in one
>> use-case, some don't. Use-cases are not a classification of
>> extensions, they're a classification of justifications for extensions
>> to exist. Surely we've missed some, but it's alright to not be fully
>> exhaustive.
>> 
>> In this next round, I want us to give our opinion, on each of these
>> use-cases, on whether we believe that this use-case is best served by
>> extension. My goal, in this round, is not necessarily to build
>> consensus for a policy, but to discover where there is consensus, and
>> where there is controversy, so that we can discuss the relevant
>> use-cases in more detail.
>> 
>> In this round, I'm asking you, for each X∈{1,…,13}, to answer the
>> following questions:
>> 
>> X.1: do you believe that this a use-case that GHC should support? (yes/no)
>> X.2: regardless of your answer in X.1, if GHC supports this use-case,
>>   do you believe that this use-case is best served by extensions. (yes/no)
>> X.2.Y: Do you believe that GHC20xx helps support this use-case (yes/no)
>> X.2.N: if you've answered “no” to X.2: what mechanism would you rather
>>   see supporting this use-case (free form)
>> 
>> I'll be on holiday next week, and will tally the results on the first
>> week on May.
>> 
>> The 13 use-cases are
>> 
>> 1. Gain early access to experimental or unstable features
>>    (e.g. because they're working on a research prototype, or because
>>    the feature is valuable enough to them to forgo some stability)
>> 2. Restrict the use of more complex features (e.g. for easier
>>    onboarding of new developers or as educators to teach a
>>    well-delimited subset of the language)
>> 3. Restrict the use of novel features since the last established
>>    standard/report.
>> 4. Restrict the use to features that they don't like (e.g. controversial
>>    features like RecordWildcard or ImplicitParameters)
>> 5. Name/refer to a particular feature when talking/writing/searching
>>    about it.
>> 6. Restrict the use of features which require support from outside
>>    the Haskell ecosystem that can't be taken for granted (I think this
>>    concerns only UnicodeSyntax)
>> 7. As library authors, to signal which features the library actually
>>    uses, hence which version of GHC the library is compatible with.
>> 8. Retain access to deprecated features to smooth out migration over
>>    the deprecation period.
>> 9. Retain access to deprecated features indefinitely.
>> 10. Change the default behaviour of (part of) the language
>>     (e.g. StrictData, I think some of the dependent Haskell work falls
>>     in this category, but I can't pinpoint an example)
>> 11. Extend the language in a way that is not backward compatible
>>     (e.g. OverloadedList, probably some dependent Haskell things too)
>> 12. Enable features whose mere presence has a performance impact
>>     (e.g. Template Haskell, and that's probably it)
>> 13. CPP (this one is very unique isn't it?)
>> _______________________________________________
>> ghc-steering-committee mailing list
>> ghc-steering-committee at haskell.org <mailto: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/20230426/63cd6352/attachment.html>

From adam at well-typed.com  Wed Apr 26 20:21:34 2023
From: adam at well-typed.com (Adam Gundry)
Date: Wed, 26 Apr 2023 21:21:34 +0100
Subject: [ghc-steering-committee] =?utf-8?q?Language_Extension_Policy_?=
 =?utf-8?b?4oCTIFJvdW5kIDI=?=
In-Reply-To: <CAJKmMz8j1X2izs3aGO_-tBFj65hAi_7MX029FL6StRtG2AppHw@mail.gmail.com>
References: <CAGwnsnkY39xPChb5a=ESM0-WtXRDz=9dk+RDqGUCJE0=6vpH4g@mail.gmail.com>
 <CAJKmMz8j1X2izs3aGO_-tBFj65hAi_7MX029FL6StRtG2AppHw@mail.gmail.com>
Message-ID: <49ade32f-ab42-8b5f-d767-0f15f4c5aa9c@well-typed.com>

On 26/04/2023 13:23, Simon Peyton Jones wrote:
 >
> I went down the list and in every case I thought "yes, language 
> extensions allow a user to do this, if they want".   I struggled to 
> answer your questions.  Eg
> 
>   * X1 is this a use-case GHC should support.  Well it already supports
>     it.   I suppose we could debate which are active goals and which are
>     accidental, but before burning the midnight oil on that debate I'd
>     love to know where this is going.

I understand Arnaud's intention here to be that we debate what the 
purpose and goals of the extensions system should be. This might include 
saying that GHC shouldn't try to support certain use cases, or that for 
some use-cases we don't believe extensions are the right mechanism to use.

My basic position is that it is crucial for extensions to be 
well-defined and introduce orthogonal language features. This isn't 
something GHC has always been good at historically, as a few extensions 
have accreted multiple somewhat-related effects. But given that caveat, 
I'm generally in favour of keeping many extensions (including splitting 
up extensions into small simple parts where appropriate). If users are 
intimidated by long extension lists, the solution IMHO is to create 
groups of related extensions, enable them by default (as in GHC20xx), 
and document them accordingly.

With that in mind, here are my (tentative) answers...


On 19/04/2023 13:20, Arnaud Spiwack wrote:

 > X.1: do you believe that this a use-case that GHC should support? 
(yes/no)
 > X.2: regardless of your answer in X.1, if GHC supports this use-case,
 >    do you believe that this use-case is best served by extensions. 
(yes/no)
 > X.2.Y: Do you believe that GHC20xx helps support this use-case (yes/no)
 > X.2.N: if you've answered “no” to X.2: what mechanism would you rather
 >    see supporting this use-case (free form)


 > 1. Gain early access to experimental or unstable features
 >     (e.g. because they're working on a research prototype, or because
 >     the feature is valuable enough to them to forgo some stability)

1.1: Yes
1.2: Yes
1.2.Y: Yes (GHC20xx can be used as a baseline, thereby making clear 
which extensions are more experimental and avoiding the need to list the 
non-experimental ones)


 > 2. Restrict the use of more complex features (e.g. for easier
 >     onboarding of new developers or as educators to teach a
 >     well-delimited subset of the language)

2.1: Yes
2.2: Yes
2.2.Y: Yes

In my view, it's not the fact of features being more complex that is 
crucial; rather the point is to have a language that is built up as a 
composition of pieces that can be understood (and enabled) independently.


 > 3. Restrict the use of novel features since the last established
 >     standard/report.

3.1: Yes
3.2: Yes
3.2.Y: No

I think it would be a shame to drop support for Haskell98/Haskell2010 
unless there is a clear cost to maintaining such support.


 > 4. Restrict the use to features that they don't like (e.g.
 >     controversial features like RecordWildcard or ImplicitParameters)

4.1: No
4.2: No
4.2.N: Merely disliking a feature isn't a good reason to make an 
extension out of it; using the warnings system is better, or moving a 
check to an external linter. Though of course controversial features may 
be extensions for other reasons.


 > 5. Name/refer to a particular feature when talking/writing/searching
 >     about it.

5.1: Yes
5.2: No
5.2.N: We should strive to use consistent terminology and document 
feature names clearly, but that doesn't by itself require an extension.


 > 6. Restrict the use of features which require support from outside
 >     the Haskell ecosystem that can't be taken for granted (I think
 >     this concerns only UnicodeSyntax)

I (sorry, belatedly) think at least one use case should cover tools 
"outside the GHC ecosystem" rather than the "Haskell ecosystem"; in 
particular we should keep in mind the needs of other Haskell compilers 
and tools. On that basis:

6.1: Yes
6.2: Yes
6.2.Y: Yes


 > 7. As library authors, to signal which features the library actually
 >     uses, hence which version of GHC the library is compatible with.

7.1: No
7.2: No
7.2.N: The fundamental issue here is that GHC doesn't maintain stable 
meanings for extensions over time (and it doesn't seem feasible to do 
so). Thus I think it would be better if libraries communicate supported 
GHC versions in their cabal files, and the cabal solver used that 
information directly rather than relying on the other-extensions field.


 > 8. Retain access to deprecated features to smooth out migration over
 >     the deprecation period.
 > 9. Retain access to deprecated features indefinitely.

{8,9}.1: Yes
{8,9}.2: Yes (where the feature being deprecated is an existing language 
extension or one can be sensibly defined retrospectively, as with 
DeepSubsumption)
{8,9}.2.Y: Yes

I see the question of whether deprecated features are available only for 
a migration period or indefinitely as orthogonal to whether they are 
extensions. Instead it depends on the specific case (how widely used is 
it, how easy is the migration path, how expensive is it to continue 
support). I think it's reasonable to have a feature deprecated 
indefinitely (because we advise against its use for new code, but it 
doesn't hurt to keep it around for backwards compatibility).


 > 10. Change the default behaviour of (part of) the language
 >      (e.g. StrictData, I think some of the dependent Haskell work
 >      falls in this category, but I can't pinpoint an example)
 > 11. Extend the language in a way that is not backward compatible
 >      (e.g. OverloadedList, probably some dependent Haskell things too)

I don't see a clear distinction between these categories. Is it that 10 
covers changes that will never be on by default, whereas 11 covers 
changes that we want to become the default but need a migration path?

{10,11}.1: Yes
{10,11}.2: Yes
{10,11}.2.Y: Yes


 > 12. Enable features whose mere presence has a performance impact
 >      (e.g. Template Haskell, and that's probably it)

12.1: Yes
12.2: No
12.2.N: Controls over (compile-time?) performance should be expressed as 
`-f...` flags (but of course TemplateHaskell is an extension for other 
reasons).


 > 13. CPP (this one is very unique isn't it?)

13.1: Yes
13.2: Yes (perhaps if we were to start again this could be its own 
pragma, but there's no point changing it now)
13.2.Y: N/A



-- 
Adam Gundry, Haskell Consultant
Well-Typed LLP, https://www.well-typed.com/

Registered in England & Wales, OC335890
27 Old Gloucester Street, London WC1N 3AX, England


From marlowsd at gmail.com  Thu Apr 27 07:34:43 2023
From: marlowsd at gmail.com (Simon Marlow)
Date: Thu, 27 Apr 2023 08:34:43 +0100
Subject: [ghc-steering-committee] =?utf-8?q?Language_Extension_Policy_?=
	=?utf-8?b?4oCTIFJvdW5kIDI=?=
In-Reply-To: <CAGwnsnkY39xPChb5a=ESM0-WtXRDz=9dk+RDqGUCJE0=6vpH4g@mail.gmail.com>
References: <CAGwnsnkY39xPChb5a=ESM0-WtXRDz=9dk+RDqGUCJE0=6vpH4g@mail.gmail.com>
Message-ID: <CANsrgPJTkUxqAAaPcW1AfQLq7+J9d3XSbVaKR0CLPs4ft_6=Vg@mail.gmail.com>

This is interesting. I find myself answering "no" to "do you believe this
use-case is best served by extensions" for almost all use-cases, the only
exception being for experimental/unstable language features and language
features with a performance impact. Everything else can be served by either
GHC20xx or warnings. Yes that means being less fine-grained in some cases,
but that might be a good tradeoff between flexibility for users and
complexity in the compiler - fewer combinations of extensions to consider
would simplify things and leave less room for bugs.

Answers below:

On Wed, 19 Apr 2023 at 13:21, Arnaud Spiwack <arnaud.spiwack at tweag.io>
wrote:

>
> X.1: do you believe that this a use-case that GHC should support? (yes/no)
> X.2: regardless of your answer in X.1, if GHC supports this use-case,
>   do you believe that this use-case is best served by extensions. (yes/no)
> X.2.Y: Do you believe that GHC20xx helps support this use-case (yes/no)
> X.2.N: if you've answered “no” to X.2: what mechanism would you rather
>   see supporting this use-case (free form)
>
> The 13 use-cases are
>
> 1. Gain early access to experimental or unstable features
>    (e.g. because they're working on a research prototype, or because
>    the feature is valuable enough to them to forgo some stability)
>

1. yes
2. yes
2.Y no


> 2. Restrict the use of more complex features (e.g. for easier
>    onboarding of new developers or as educators to teach a
>    well-delimited subset of the language)
>

1. yes
2. no
2.N warnings, -Werror=feature


> 3. Restrict the use of novel features since the last established
>    standard/report.
>

1. yes
2. no
2.N -XHaskell2010 and/or warnings


> 4. Restrict the use to features that they don't like (e.g. controversial
>    features like RecordWildcard or ImplicitParameters)
>

1. yes
2. no
2.N warnings


> 5. Name/refer to a particular feature when talking/writing/searching
>    about it.
>

1. yes
2. no - we don't need to support extensions to be able to name language
features.
2.N continue to use the names we have now, but without supporting -XFoo for
all extensions


> 6. Restrict the use of features which require support from outside
>    the Haskell ecosystem that can't be taken for granted (I think this
>    concerns only UnicodeSyntax)
>

1. yes
2. no
2.N warnings


> 7. As library authors, to signal which features the library actually
>    uses, hence which version of GHC the library is compatible with.
>

1. yes
2. no
2.N GHC20xx


> 8. Retain access to deprecated features to smooth out migration over
>    the deprecation period.
>

1. yes
2.no
2.N GHC20xx


> 9. Retain access to deprecated features indefinitely.
>

1. no


> 10. Change the default behaviour of (part of) the language
>     (e.g. StrictData, I think some of the dependent Haskell work falls
>     in this category, but I can't pinpoint an example)
>

1. yes
2. no
2.N GHC20xx


> 11. Extend the language in a way that is not backward compatible
>     (e.g. OverloadedList, probably some dependent Haskell things too)
>

1. yes
2. no
2.N GHC20xx


> 12. Enable features whose mere presence has a performance impact
>     (e.g. Template Haskell, and that's probably it)
>

1. yes
2. yes
2.Y no


> 13. CPP (this one is very unique isn't it?)
>

1. yes
2. no
2.N it should probably be a flag


> _______________________________________________
> 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/20230427/8f7ab546/attachment-0001.html>

From simon.peytonjones at gmail.com  Thu Apr 27 08:09:08 2023
From: simon.peytonjones at gmail.com (Simon Peyton Jones)
Date: Thu, 27 Apr 2023 09:09:08 +0100
Subject: [ghc-steering-committee] =?utf-8?q?Language_Extension_Policy_?=
	=?utf-8?b?4oCTIFJvdW5kIDI=?=
In-Reply-To: <CANsrgPJTkUxqAAaPcW1AfQLq7+J9d3XSbVaKR0CLPs4ft_6=Vg@mail.gmail.com>
References: <CAGwnsnkY39xPChb5a=ESM0-WtXRDz=9dk+RDqGUCJE0=6vpH4g@mail.gmail.com>
 <CANsrgPJTkUxqAAaPcW1AfQLq7+J9d3XSbVaKR0CLPs4ft_6=Vg@mail.gmail.com>
Message-ID: <CAJKmMz-OEutWF2HQnL7e3TbUt0T44dvYUi3yWxZkWX-4M6wKGA@mail.gmail.com>

> Everything else can be served by either GHC20xx or warnings.

Let's unpack that statement a bit.  I think GHC20xx is a bit of a red
herring ... it doesn't change rapidly enough, and there will always be
people who want a different combination.

The thing about warnings is different.  I think you are suggesting that we
should:

   - Remove (say) MultiParamTypeClasses as an extension
   - Accept programs that use MultiParamTypeClasses unconditionally
   - But with a warning
   - That can be suppressed with -fno-warn-multi-param-type-classes

So a long {-# LANGUAGE X1, X2 #-} preamble will be replace with a long {-#
OPTIONS_GHC -fno-warn-X1 -fno-warn-X2 #-} block.

Is that what you meant by "everything else best served by warnings"?

I think that is a consistent position for extensions that use new syntax.
But

   - Not all extensions use new syntax (e.g. -XPolyKinds).
   - You say "the only exception being for experimental/unstable language
   features and language features with a performance impact", but
   - if an experimental/unstable feature uses new syntax, it would again be
      fine with "Warning: you are using an experimental feature"
      - Ditto features that use new syntax with a perf impact
      - what about RebindableSyntax or Strict, which change semantics but
      add no new syntax?
      - It's not clear to me that saying `OPTIONS_GHC -no-warn-X1` is
   superior to `LANGUAGE X1`.  In fact I mildly prefer the latter
   - It'd be a big upheaval to get from where we are, to get there

But it is a consistent position.   Are you advocating that change?

Simon

On Thu, 27 Apr 2023 at 08:35, Simon Marlow <marlowsd at gmail.com> wrote:

> This is interesting. I find myself answering "no" to "do you believe this
> use-case is best served by extensions" for almost all use-cases, the only
> exception being for experimental/unstable language features and language
> features with a performance impact. Everything else can be served by either
> GHC20xx or warnings. Yes that means being less fine-grained in some cases,
> but that might be a good tradeoff between flexibility for users and
> complexity in the compiler - fewer combinations of extensions to consider
> would simplify things and leave less room for bugs.
>
> Answers below:
>
> On Wed, 19 Apr 2023 at 13:21, Arnaud Spiwack <arnaud.spiwack at tweag.io>
> wrote:
>
>>
>> X.1: do you believe that this a use-case that GHC should support? (yes/no)
>> X.2: regardless of your answer in X.1, if GHC supports this use-case,
>>   do you believe that this use-case is best served by extensions. (yes/no)
>> X.2.Y: Do you believe that GHC20xx helps support this use-case (yes/no)
>> X.2.N: if you've answered “no” to X.2: what mechanism would you rather
>>   see supporting this use-case (free form)
>>
>> The 13 use-cases are
>>
>> 1. Gain early access to experimental or unstable features
>>    (e.g. because they're working on a research prototype, or because
>>    the feature is valuable enough to them to forgo some stability)
>>
>
> 1. yes
> 2. yes
> 2.Y no
>
>
>> 2. Restrict the use of more complex features (e.g. for easier
>>    onboarding of new developers or as educators to teach a
>>    well-delimited subset of the language)
>>
>
> 1. yes
> 2. no
> 2.N warnings, -Werror=feature
>
>
>> 3. Restrict the use of novel features since the last established
>>    standard/report.
>>
>
> 1. yes
> 2. no
> 2.N -XHaskell2010 and/or warnings
>
>
>> 4. Restrict the use to features that they don't like (e.g. controversial
>>    features like RecordWildcard or ImplicitParameters)
>>
>
> 1. yes
> 2. no
> 2.N warnings
>
>
>> 5. Name/refer to a particular feature when talking/writing/searching
>>    about it.
>>
>
> 1. yes
> 2. no - we don't need to support extensions to be able to name language
> features.
> 2.N continue to use the names we have now, but without supporting -XFoo
> for all extensions
>
>
>> 6. Restrict the use of features which require support from outside
>>    the Haskell ecosystem that can't be taken for granted (I think this
>>    concerns only UnicodeSyntax)
>>
>
> 1. yes
> 2. no
> 2.N warnings
>
>
>> 7. As library authors, to signal which features the library actually
>>    uses, hence which version of GHC the library is compatible with.
>>
>
> 1. yes
> 2. no
> 2.N GHC20xx
>
>
>> 8. Retain access to deprecated features to smooth out migration over
>>    the deprecation period.
>>
>
> 1. yes
> 2.no
> 2.N GHC20xx
>
>
>> 9. Retain access to deprecated features indefinitely.
>>
>
> 1. no
>
>
>> 10. Change the default behaviour of (part of) the language
>>     (e.g. StrictData, I think some of the dependent Haskell work falls
>>     in this category, but I can't pinpoint an example)
>>
>
> 1. yes
> 2. no
> 2.N GHC20xx
>
>
>> 11. Extend the language in a way that is not backward compatible
>>     (e.g. OverloadedList, probably some dependent Haskell things too)
>>
>
> 1. yes
> 2. no
> 2.N GHC20xx
>
>
>> 12. Enable features whose mere presence has a performance impact
>>     (e.g. Template Haskell, and that's probably it)
>>
>
> 1. yes
> 2. yes
> 2.Y no
>
>
>> 13. CPP (this one is very unique isn't it?)
>>
>
> 1. yes
> 2. no
> 2.N it should probably be a flag
>
>
>> _______________________________________________
>> 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/20230427/cf5a3ec8/attachment.html>

From eric at seidel.io  Thu Apr 27 14:11:42 2023
From: eric at seidel.io (Eric Seidel)
Date: Thu, 27 Apr 2023 10:11:42 -0400
Subject: [ghc-steering-committee] =?utf-8?q?Language_Extension_Policy_?=
 =?utf-8?b?4oCTIFJvdW5kIDI=?=
In-Reply-To: <CAJKmMz-OEutWF2HQnL7e3TbUt0T44dvYUi3yWxZkWX-4M6wKGA@mail.gmail.com>
References: <CAGwnsnkY39xPChb5a=ESM0-WtXRDz=9dk+RDqGUCJE0=6vpH4g@mail.gmail.com>
 <CANsrgPJTkUxqAAaPcW1AfQLq7+J9d3XSbVaKR0CLPs4ft_6=Vg@mail.gmail.com>
 <CAJKmMz-OEutWF2HQnL7e3TbUt0T44dvYUi3yWxZkWX-4M6wKGA@mail.gmail.com>
Message-ID: <5e1bbcbf-9674-4167-9d62-c058b669cb92@app.fastmail.com>

On Thu, Apr 27, 2023, at 04:09, Simon Peyton Jones wrote:
> The thing about warnings is different.  I think you are suggesting that 
> we should:
>  • Remove (say) MultiParamTypeClasses as an extension
>  • Accept programs that use MultiParamTypeClasses unconditionally
>  • But with a warning
>  • That can be suppressed with -fno-warn-multi-param-type-classes
> So a long {-# LANGUAGE X1, X2 #-} preamble will be replace with a long 
> {-# OPTIONS_GHC -fno-warn-X1 -fno-warn-X2 #-} block.

I can't speak for Simon, but I felt similarly about Extensions vs Warnings. What you're saying here is not quite what I had in mind. For me it's more like

>  • Remove (say) MultiParamTypeClasses as an extension
>  • Accept programs that use MultiParamTypeClasses unconditionally
>  • If you want to disallow MPTCs, you can disable them with `-Wmulti-param-type-classes -Werror`

In other words, MPTCs are simply part of the language now. Not a second class citizen that must be opted into with an Extension or by *disabling* a Warning. We leave an escape hatch in the form of an opt-in warning for those who would rather not use MPTCs, much like other aspects of the language the may be controversial.

From adam at well-typed.com  Thu Apr 27 15:40:29 2023
From: adam at well-typed.com (Adam Gundry)
Date: Thu, 27 Apr 2023 16:40:29 +0100
Subject: [ghc-steering-committee] =?utf-8?q?Language_Extension_Policy_?=
 =?utf-8?b?4oCTIFJvdW5kIDI=?=
In-Reply-To: <5e1bbcbf-9674-4167-9d62-c058b669cb92@app.fastmail.com>
References: <CAGwnsnkY39xPChb5a=ESM0-WtXRDz=9dk+RDqGUCJE0=6vpH4g@mail.gmail.com>
 <CANsrgPJTkUxqAAaPcW1AfQLq7+J9d3XSbVaKR0CLPs4ft_6=Vg@mail.gmail.com>
 <CAJKmMz-OEutWF2HQnL7e3TbUt0T44dvYUi3yWxZkWX-4M6wKGA@mail.gmail.com>
 <5e1bbcbf-9674-4167-9d62-c058b669cb92@app.fastmail.com>
Message-ID: <654e444d-3313-6675-c506-fc80f0425f20@well-typed.com>

On 27/04/2023 15:11, Eric Seidel wrote:
> 
> I can't speak for Simon, but I felt similarly about Extensions vs
> Warnings. What you're saying here is not quite what I had in mind.
> For me it's more like
> 
>> • Remove (say) MultiParamTypeClasses as an extension
>> • Accept programs that use MultiParamTypeClasses unconditionally
>> • If you want to disallow MPTCs, you can disable them with
>> `-Wmulti-param-type-classes -Werror`
> 
> In other words, MPTCs are simply part of the language now. Not a
> second class citizen that must be opted into with an Extension or by
> *disabling* a Warning. We leave an escape hatch in the form of an
> opt-in warning for those who would rather not use MPTCs, much like
> other aspects of the language the may be controversial.

Here's what I don't quite understand: MultiParamTypeClasses is already 
part of GHC2021 and thus enabled by default (unless the program is 
specifying e.g. Haskell2010 as the default-language). Given that, why is 
it worthwhile to go through the churn of replacing 
`-XNoMultiParamTypeClasses` with `-Werror=multi-param-type-classes`?

If the issue is implementation complexity, then I don't see how changing 
one flag to another really helps that; to fundamentally simplify the 
implementation you have to eliminate the ability to disable the feature 
altogether. (And I would argue that the way to keep the implementation 
simple is to design language features that are orthogonal, rather than 
having one big monolithic language that can't be decomposed...)

If it's a conceptual/documentation issue, could we instead rewrite the 
user's guide so that it assumes GHC2021 as a baseline, and presents 
multi-parameter type classes as a feature of "GHC Haskell" (with a side 
note that they can be disabled with NoMultiParamTypeClasses)?

I'm sure I'm missing something... :-)

Adam

-- 
Adam Gundry, Haskell Consultant
Well-Typed LLP, https://www.well-typed.com/

Registered in England & Wales, OC335890
27 Old Gloucester Street, London WC1N 3AX, England


From eric at seidel.io  Thu Apr 27 22:49:07 2023
From: eric at seidel.io (Eric Seidel)
Date: Thu, 27 Apr 2023 18:49:07 -0400
Subject: [ghc-steering-committee] =?utf-8?q?Language_Extension_Policy_?=
 =?utf-8?b?4oCTIFJvdW5kIDI=?=
In-Reply-To: <654e444d-3313-6675-c506-fc80f0425f20@well-typed.com>
References: <CAGwnsnkY39xPChb5a=ESM0-WtXRDz=9dk+RDqGUCJE0=6vpH4g@mail.gmail.com>
 <CANsrgPJTkUxqAAaPcW1AfQLq7+J9d3XSbVaKR0CLPs4ft_6=Vg@mail.gmail.com>
 <CAJKmMz-OEutWF2HQnL7e3TbUt0T44dvYUi3yWxZkWX-4M6wKGA@mail.gmail.com>
 <5e1bbcbf-9674-4167-9d62-c058b669cb92@app.fastmail.com>
 <654e444d-3313-6675-c506-fc80f0425f20@well-typed.com>
Message-ID: <50323da1-1c43-4acb-937c-14e7603145e8@app.fastmail.com>

On Thu, Apr 27, 2023, at 11:40, Adam Gundry wrote:
> Here's what I don't quite understand: MultiParamTypeClasses is already 
> part of GHC2021 and thus enabled by default (unless the program is 
> specifying e.g. Haskell2010 as the default-language). Given that, why is 
> it worthwhile to go through the churn of replacing 
> `-XNoMultiParamTypeClasses` with `-Werror=multi-param-type-classes`?

It may not be, but that's not the question we're trying to answer right now, at least not as I understood it. Arnaud asked us whether these are valid use cases for extensions. That's a "what should be" question. My answer is that restricting to a subset of the language should be done via warnings or linters, rather than via extensions. That's not the current pattern in GHC, but it's what I would do if we were starting over.

Once we've established "what should be", we can then discuss "what to do about it", i.e. should we undertake a large refactoring of GHC to migrate all of these extensions to warnings? We might decide that it's worthwhile because of some reduction in code complexity. Or we might decide that it's not worthwhile because of the churn it would cause. But either way we have learned something about language design that can guide future decisions.

From marlowsd at gmail.com  Fri Apr 28 08:17:37 2023
From: marlowsd at gmail.com (Simon Marlow)
Date: Fri, 28 Apr 2023 09:17:37 +0100
Subject: [ghc-steering-committee] =?utf-8?q?Language_Extension_Policy_?=
	=?utf-8?b?4oCTIFJvdW5kIDI=?=
In-Reply-To: <CAJKmMz-OEutWF2HQnL7e3TbUt0T44dvYUi3yWxZkWX-4M6wKGA@mail.gmail.com>
References: <CAGwnsnkY39xPChb5a=ESM0-WtXRDz=9dk+RDqGUCJE0=6vpH4g@mail.gmail.com>
 <CANsrgPJTkUxqAAaPcW1AfQLq7+J9d3XSbVaKR0CLPs4ft_6=Vg@mail.gmail.com>
 <CAJKmMz-OEutWF2HQnL7e3TbUt0T44dvYUi3yWxZkWX-4M6wKGA@mail.gmail.com>
Message-ID: <CANsrgPLJPtmjcPyR5HZQEKGzXcFcT05Ec=HhqfmHGLpd4pfCag@mail.gmail.com>

Good! I'm glad we're discussing where this alternative design leads. I'm
not sure whether I'm 100% advocating for it - it may be that ultimately
it's not enough of an improvement over extension flags to warrant the
churn. But I think it's worthwhile to explore it. (to be clear I don't
think the idea of using warnings was mine, I forgot who originally
suggested it but it came out of the discussion on the GDoc we had earlier)

On Thu, 27 Apr 2023 at 09:07, Simon Peyton Jones <
simon.peytonjones at gmail.com> wrote:

> > Everything else can be served by either GHC20xx or warnings.
>
> Let's unpack that statement a bit.  I think GHC20xx is a bit of a red
> herring ... it doesn't change rapidly enough, and there will always be
> people who want a different combination.
>
> The thing about warnings is different.  I think you are suggesting that we
> should:
>
>    - Remove (say) MultiParamTypeClasses as an extension
>    - Accept programs that use MultiParamTypeClasses unconditionally
>
> Only with GHC2021 and later

>
>    - But with a warning
>
> which is disabled by default

>
>    - That can be suppressed with -fno-warn-multi-param-type-classes
>
> maybe we call it -WMultiParamTypeClasses to keep the naming consistent. So
-Werror=MultiParamTypeClasses would be the way to disable it.


> So a long {-# LANGUAGE X1, X2 #-} preamble will be replace with a long {-#
> OPTIONS_GHC -fno-warn-X1 -fno-warn-X2 #-} block.
>

No, most use cases would be using `{-# LANGUAGE GHC2021 #-}` or whatever.
Use cases that wanted to use GHC2021 but disable specific extensions would
need a `{-# LANGUAGE -Werror=whatever #-}` or the equivalent in the .cabal
file.

>
> I think that is a consistent position for extensions that use new syntax.
> But
>
>    - Not all extensions use new syntax (e.g. -XPolyKinds).
>
> Sure, so if you want to disable PolyKinds then you must use a GHC20xx
version that doesn't include it. This is of course less flexible than what
we currently have. But it might be advantageous:

   - We don't have to consider what happens when you turn off PolyKinds in
   combination with all the other extensions, and make all those combinations
   behave in some well-defined way (or, disallow certain combinations with an
   error when the combination doesn't make sense). We know that PolyKinds is
   only enabled along with all the other extensions in GHC2024 or whatever.
   Note that other languages do similar things: you can't turn off individual
   extensions in C++17 for example.
   - We're massively reducing the space of language variants to a set of a
   few language versions that we have carefully curated. That is, I postulate,
   a very good thing for most users and for the language in general.


>    - You say "the only exception being for experimental/unstable language
>    features and language features with a performance impact", but
>    - if an experimental/unstable feature uses new syntax, it would again
>       be fine with "Warning: you are using an experimental feature"
>
> We could only do that for things with genuinely new syntax (not stolen
syntax!). So e.g. OverloadedLists couldn't be a warning, it has to be an
experimental extension.

>
>    - Ditto features that use new syntax with a perf impact
>       - what about RebindableSyntax or Strict, which change semantics but
>       add no new syntax?
>
> Both of those cases should arguably be flags instead of language
extensions. `{-# LANGUAGE -frebindable-syntax #-}`.

>
>    -
>    - It's not clear to me that saying `OPTIONS_GHC -no-warn-X1` is
>    superior to `LANGUAGE X1`.  In fact I mildly prefer the latter
>    - It'd be a big upheaval to get from where we are, to get there
>
> Indeed!


> But it is a consistent position.   Are you advocating that change?
>

I'm not sure, but as I said at the top, I think it's worth exploring.

Cheers
Simon


>
> Simon
>
> On Thu, 27 Apr 2023 at 08:35, Simon Marlow <marlowsd at gmail.com> wrote:
>
>> This is interesting. I find myself answering "no" to "do you believe this
>> use-case is best served by extensions" for almost all use-cases, the only
>> exception being for experimental/unstable language features and language
>> features with a performance impact. Everything else can be served by either
>> GHC20xx or warnings. Yes that means being less fine-grained in some cases,
>> but that might be a good tradeoff between flexibility for users and
>> complexity in the compiler - fewer combinations of extensions to consider
>> would simplify things and leave less room for bugs.
>>
>> Answers below:
>>
>> On Wed, 19 Apr 2023 at 13:21, Arnaud Spiwack <arnaud.spiwack at tweag.io>
>> wrote:
>>
>>>
>>> X.1: do you believe that this a use-case that GHC should support?
>>> (yes/no)
>>> X.2: regardless of your answer in X.1, if GHC supports this use-case,
>>>   do you believe that this use-case is best served by extensions.
>>> (yes/no)
>>> X.2.Y: Do you believe that GHC20xx helps support this use-case (yes/no)
>>> X.2.N: if you've answered “no” to X.2: what mechanism would you rather
>>>   see supporting this use-case (free form)
>>>
>>> The 13 use-cases are
>>>
>>> 1. Gain early access to experimental or unstable features
>>>    (e.g. because they're working on a research prototype, or because
>>>    the feature is valuable enough to them to forgo some stability)
>>>
>>
>> 1. yes
>> 2. yes
>> 2.Y no
>>
>>
>>> 2. Restrict the use of more complex features (e.g. for easier
>>>    onboarding of new developers or as educators to teach a
>>>    well-delimited subset of the language)
>>>
>>
>> 1. yes
>> 2. no
>> 2.N warnings, -Werror=feature
>>
>>
>>> 3. Restrict the use of novel features since the last established
>>>    standard/report.
>>>
>>
>> 1. yes
>> 2. no
>> 2.N -XHaskell2010 and/or warnings
>>
>>
>>> 4. Restrict the use to features that they don't like (e.g. controversial
>>>    features like RecordWildcard or ImplicitParameters)
>>>
>>
>> 1. yes
>> 2. no
>> 2.N warnings
>>
>>
>>> 5. Name/refer to a particular feature when talking/writing/searching
>>>    about it.
>>>
>>
>> 1. yes
>> 2. no - we don't need to support extensions to be able to name language
>> features.
>> 2.N continue to use the names we have now, but without supporting -XFoo
>> for all extensions
>>
>>
>>> 6. Restrict the use of features which require support from outside
>>>    the Haskell ecosystem that can't be taken for granted (I think this
>>>    concerns only UnicodeSyntax)
>>>
>>
>> 1. yes
>> 2. no
>> 2.N warnings
>>
>>
>>> 7. As library authors, to signal which features the library actually
>>>    uses, hence which version of GHC the library is compatible with.
>>>
>>
>> 1. yes
>> 2. no
>> 2.N GHC20xx
>>
>>
>>> 8. Retain access to deprecated features to smooth out migration over
>>>    the deprecation period.
>>>
>>
>> 1. yes
>> 2.no
>> 2.N GHC20xx
>>
>>
>>> 9. Retain access to deprecated features indefinitely.
>>>
>>
>> 1. no
>>
>>
>>> 10. Change the default behaviour of (part of) the language
>>>     (e.g. StrictData, I think some of the dependent Haskell work falls
>>>     in this category, but I can't pinpoint an example)
>>>
>>
>> 1. yes
>> 2. no
>> 2.N GHC20xx
>>
>>
>>> 11. Extend the language in a way that is not backward compatible
>>>     (e.g. OverloadedList, probably some dependent Haskell things too)
>>>
>>
>> 1. yes
>> 2. no
>> 2.N GHC20xx
>>
>>
>>> 12. Enable features whose mere presence has a performance impact
>>>     (e.g. Template Haskell, and that's probably it)
>>>
>>
>> 1. yes
>> 2. yes
>> 2.Y no
>>
>>
>>> 13. CPP (this one is very unique isn't it?)
>>>
>>
>> 1. yes
>> 2. no
>> 2.N it should probably be a flag
>>
>>
>>> _______________________________________________
>>> 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/20230428/da936e0d/attachment-0001.html>

From mail at joachim-breitner.de  Fri Apr 28 11:20:05 2023
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Fri, 28 Apr 2023 13:20:05 +0200
Subject: [ghc-steering-committee] =?utf-8?q?Language_Extension_Policy_?=
 =?utf-8?b?4oCTIFJvdW5kIDI=?=
In-Reply-To: <CANsrgPLJPtmjcPyR5HZQEKGzXcFcT05Ec=HhqfmHGLpd4pfCag@mail.gmail.com>
References: <CAGwnsnkY39xPChb5a=ESM0-WtXRDz=9dk+RDqGUCJE0=6vpH4g@mail.gmail.com>
 <CANsrgPJTkUxqAAaPcW1AfQLq7+J9d3XSbVaKR0CLPs4ft_6=Vg@mail.gmail.com>
 <CAJKmMz-OEutWF2HQnL7e3TbUt0T44dvYUi3yWxZkWX-4M6wKGA@mail.gmail.com>
 <CANsrgPLJPtmjcPyR5HZQEKGzXcFcT05Ec=HhqfmHGLpd4pfCag@mail.gmail.com>
Message-ID: <645c23058bff47264e49fdecd16d3eedce2167bd.camel@joachim-breitner.de>

Hi,

Am Freitag, dem 28.04.2023 um 09:17 +0100 schrieb Simon Marlow:
> Good! I'm glad we're discussing where this alternative design leads.
> I'm not sure whether I'm 100% advocating for it - it may be that
> ultimately it's not enough of an improvement over extension flags to
> warrant the churn. But I think it's worthwhile to explore it. (to be
> clear I don't think the idea of using warnings was mine, I forgot who
> originally suggested it but it came out of the discussion on the GDoc
> we had earlier)

I believe it was Richard’s.


I also think this is a worthwhile discussion, even if the outcome would
be that the design is desirable, but not worth the transition. What’s
appealing about it is the pivot of perspective:  No longer 2^n
different Haskell-like languages, but rather one evolving Glorious
Haskell, plus tools that help those who want to restrict themselves for
whatever reason.


Cheers,
Joachim



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