From mail at joachim-breitner.de  Sat Jul  1 10:38:39 2023
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Sat, 01 Jul 2023 12:38:39 +0200
Subject: [ghc-steering-committee] #596: sized literals in Show,
 rec: accept
In-Reply-To: <CAJKmMz96+rypF73qgb2=wxFhT34rpObR+gE-wLJWY7est=r7Wg@mail.gmail.com>
References: <0a90849c93122ead8026bf5f9414f8da91a5f3c2.camel@joachim-breitner.de>
 <CAJKmMz96+rypF73qgb2=wxFhT34rpObR+gE-wLJWY7est=r7Wg@mail.gmail.com>
Message-ID: <f276f04699da546d470e95d02a83fc347843bf21.camel@joachim-breitner.de>

Hi,

CLC appreciates the ping but says it’s out of scope:
https://github.com/haskell/core-libraries-committee/issues/183#issuecomment-1615827603

Cheers,
Joachim

Am Donnerstag, dem 29.06.2023 um 08:16 +0100 schrieb Simon Peyton
Jones:
> Looks good to me.
> 
> I have suggested that @monoidal opens a CLC issue.  (This change the
> `base` API.)
> 
> Simon
> 
> On Thu, 29 Jun 2023 at 07:21, Joachim Breitner
> <mail at joachim-breitner.de> wrote:
> > Dear committee,
> > 
> > Krzysztof Gogolewski in
> > https://github.com/ghc-proposals/ghc-proposals/pull/596
> > amends the sized literals proposal so that GHC uses the syntax 
> > 42#Int8 instead of (intToInt8# 42#) in the stock derived Show
> > instances
> > for data types with sized unboxed numbers.
> > 
> > Implementation is also ready.
> > 
> > Now that we have a syntax for these literals it’s clear that we
> > want to
> > use them in the show instances. 
> > 
> > 
> > There is no risk of breaking Show-Read-roundtripping, as Read
> > instances
> > cannot be derived (at the moment).
> > 
> > This is a change in behavior of Show, so we should think for a
> > moment
> > how this affects stability. But none of the libraries in
> > libraries/, in
> > particularly not base, are affected by this change, according to
> > Krzysztof.
> > 
> > So I recommend to accept this.
> > 
> > Cheers,
> > Joachim
> > 
> > 
> > 
> > _______________________________________________
> > ghc-steering-committee mailing list
> > ghc-steering-committee at haskell.org
> > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

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


From mail at joachim-breitner.de  Sun Jul  2 19:26:54 2023
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Sun, 02 Jul 2023 21:26:54 +0200
Subject: [ghc-steering-committee] Please review #434: Fine-grained unused
 warnings, Shepherd: Chris
Message-ID: <eaab453ff18530ad7630d7e8e20eb85324305599.camel@joachim-breitner.de>

Dear Committee,

Jakob Brünker proposes more fine-grained control over unused warnings:

https://github.com/ghc-proposals/ghc-proposals/pull/434
https://github.com/JakobBruenker/ghc-proposals/blob/fine-grained-unused/proposals/0000-fine-grained-unused-warnings.rst

I’d like to ask Chris to shepherd this proposal.

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 mail at joachim-breitner.de  Mon Jul  3 07:29:16 2023
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Mon, 03 Jul 2023 09:29:16 +0200
Subject: [ghc-steering-committee]  GHC Steering Committee Status
Message-ID: <3e347d7a6c4013f7341e25b8080ae15c386bfbb6.camel@joachim-breitner.de>

Dear Committee,

besides long discussions understanding our relationship with the CLC,
we even manged to process some proposals. So let’s see what happened 
since the last update (May 17):

 * Our intraction with the CLC is now documented at
   https://github.com/Ericson2314/tech-proposals/blob/ghc-base-libraries/proposals/accepted/050-ghc-base-libraries.rst

 * No news from Arnaud’s quest to understand the roles of Extensions.

 * we were asked to review these proposals:
  
   #194: Updated partial type signatures, Shepherd: Eric (resubmission)
   #581: Namespaces-specified Imports, Shepherd: Moritz
   #586: split -Wunused-imports, Shepherd: Chris
   #596: sized literals in Show, Shepherd: Joachim
   #434: Fine-grained unused warnings, Shepherd: Chris

 * we have a recommendation from the shepherd about:

   #581: Namespaces-specified Imports, rec: accept
   #586: split -Wunused-imports, rec: accept
   #575: deprecation pragmas on instances, rec: accept
   #596: sized literals in Show, rec: accept

 * we have sent the following proposals back to revision

   #532: Clean up and simplify the treatment of implicit binding
   #493: SPECIALISE with expressions, Shepherd: Adam

 * we decided about the following proposals

   #330: Decorate exceptions with backtrace information, accepted
   #579: Backward compat proposal section, accepted
   #586: split -Wunused-imports, accepted
   #575: deprecation pragmas on instances, accepted


So we currently have to act on the following 8 proposals, down by one
from last time:

## Waiting for committee decision

#512: NoFieldSelectors as datatype annotation, Shepherd: Vlad
      2022-09-03: Assigned to Baldur
      2022-10-02: Reassignd to Vlad
      2022-11-30: Vlad recommends rejection
      This needs to be picked up again, it has been lingering too long!

#536: Type-level literals as a sep language extension, Shepherd: Vlad
      2023-02-16 Assigned to Vlad
      2023-03-06 Vlad recommends acceptance
      Some hesitancy in the committee to introduce this extension,
      the ongoing policy clarification process might guide us, 
      but maybe we can resolve this earlier?

#579: sized literals in Show, Shepherd: Joachim
      2023-06-29: Assigned to Joachim
      2023-06-29: Joachim recommends acceptance
      two 👍, rather incontroversial. Will merge in a few days

#581: Namespaces-specified Imports, Shepherd: Moritz
      2023-06-28: Moritz suggests acceptance.
      Mostly positive feedback, can probably be merged in a week’s time


## Waiting for shepherd recommendation

#526: Applicative Comprehensions, Shepherd: Simon M
      2022-10-08: Assigned to Simon M
      Simon, please cast your recommendation!

#585: Amend Or Patterns, Shepherd: Richard
      2023-04-11: Assigned to Richard
      There are votes on syntax going on, ran by Sebastian Graf.
      Maybe this should be in “needs revision” until they are through.
      Richard, I’ll leave this to you

#194: Updated partial type signatures, Shepherd: Eric
      2023-05-25: Came back from needs revision

#434: Fine-grained unused warnings, Shepherd: Chris
      2023-07-02: Assigned to Chris

Cheers,
Joachim



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


From arnaud.spiwack at tweag.io  Thu Jul  6 09:03:17 2023
From: arnaud.spiwack at tweag.io (Arnaud Spiwack)
Date: Thu, 6 Jul 2023 11:03:17 +0200
Subject: [ghc-steering-committee] =?utf-8?q?Language_Extension_Policy_?=
	=?utf-8?b?4oCTIFJvdW5kIDI=?=
In-Reply-To: <010f0187fb3b0c6c-f138abf5-e3b9-415b-811d-f3b74b24e595-000000@us-east-2.amazonses.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>
 <645c23058bff47264e49fdecd16d3eedce2167bd.camel@joachim-breitner.de>
 <010f0187d50efae1-7ff2c457-95dc-4f22-9e75-400eb068952d-000000@us-east-2.amazonses.com>
 <0b6911af-db25-b510-1074-6bd1765e82c8@well-typed.com>
 <010f0187fb3b0c6c-f138abf5-e3b9-415b-811d-f3b74b24e595-000000@us-east-2.amazonses.com>
Message-ID: <CAGwnsnkUt6oiheEiScSBysgo08=yFX0ELUQezh6w0oRPR3ZBrg@mail.gmail.com>

Dear all,

A (very belated) thank you for the interesting conversation on this thread.
I'm being very slow, but I'm still digesting the contents. I've tallied the
answer on the questionnaire in this spreadsheet, that I've tried to make as
helpful as possible (if only for my benefit, as I'm trying to make it speak)

https://docs.google.com/spreadsheets/d/1cRTJ2go5opXjIp-kojR_eOA-RWNBq2jzmecoSfhnvuE/edit?usp=sharing

The rest of the conversation, I have yet to figure out what to do, but the
discussion on classifying the extensions by stability seems to intersect
very much with the recent proposal that has been submitted by the Haskell
Foundation's Stability Working Group don't hesitate to check it out
https://github.com/ghc-proposals/ghc-proposals/pull/601 .

One thing I will say is that among the respondents, there appears to be a
pretty clear consensus that extensions should not be forever. I'll probably
make my next round about this (if things go right, later today; but I'm
loath to make any promise, considering how late I've been on the previous
rounds).

/Arnaud

On Mon, 8 May 2023 at 13:59, Richard Eisenberg <lists at richarde.dev> wrote:

>
>
> On May 1, 2023, at 8:59 AM, Adam Gundry <adam at well-typed.com> wrote:
>
>
> * recommended (part of the language, fairly stable);
>
> * experimental (not yet resolved one way or the other); or
>
> * discouraged (supported primarily for backwards compatibility).
>
>
> Yes! And also Simon's addition of "language variation".
>
> My stance is (I claim) it is hard for users to navigate the current
> extension maze (e.g. it's pretty hard for someone to know that
> scary-sounding UndecidableInstances is safe to use in practice but that
> TypeFamilies may break their type inference, even if they never write a
> type family). We should strive to simplify this maze so that it's easier
> for our users to write effective Haskell.
>
> One way to phrase this is "stable and liberal".
>
> Richard
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>


-- 
Arnaud Spiwack
Director, Research at https://moduscreate.com and https://tweag.io.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20230706/d6506443/attachment.html>

From arnaud.spiwack at tweag.io  Thu Jul  6 12:45:16 2023
From: arnaud.spiwack at tweag.io (Arnaud Spiwack)
Date: Thu, 6 Jul 2023 14:45:16 +0200
Subject: [ghc-steering-committee] #596: sized literals in Show,
	rec: accept
In-Reply-To: <f276f04699da546d470e95d02a83fc347843bf21.camel@joachim-breitner.de>
References: <0a90849c93122ead8026bf5f9414f8da91a5f3c2.camel@joachim-breitner.de>
 <CAJKmMz96+rypF73qgb2=wxFhT34rpObR+gE-wLJWY7est=r7Wg@mail.gmail.com>
 <f276f04699da546d470e95d02a83fc347843bf21.camel@joachim-breitner.de>
Message-ID: <CAGwnsn=B_z+p=0n2VGEsSiYFJ=nh8fxB-dZnzfJhCeQ5Gf=u-w@mail.gmail.com>

This proposal could break a few things, in particular if someone made a
Read instance for a type with sized integer fields (though considering how
the Show instance looks, I'd probably not have gone that path personally,
so I expect it to be quite rare).

Probably, just in case, this should be advertised pretty loudly in the
release note.

Apart from that, this is a clear improvement. The author's patch even
removes some net lines from GHC, which is always welcome.

I'm in favour.

On Sat, 1 Jul 2023 at 12:38, Joachim Breitner <mail at joachim-breitner.de>
wrote:

> Hi,
>
> CLC appreciates the ping but says it’s out of scope:
>
> https://github.com/haskell/core-libraries-committee/issues/183#issuecomment-1615827603
>
> Cheers,
> Joachim
>
> Am Donnerstag, dem 29.06.2023 um 08:16 +0100 schrieb Simon Peyton
> Jones:
> > Looks good to me.
> >
> > I have suggested that @monoidal opens a CLC issue.  (This change the
> > `base` API.)
> >
> > Simon
> >
> > On Thu, 29 Jun 2023 at 07:21, Joachim Breitner
> > <mail at joachim-breitner.de> wrote:
> > > Dear committee,
> > >
> > > Krzysztof Gogolewski in
> > > https://github.com/ghc-proposals/ghc-proposals/pull/596
> > > amends the sized literals proposal so that GHC uses the syntax
> > > 42#Int8 instead of (intToInt8# 42#) in the stock derived Show
> > > instances
> > > for data types with sized unboxed numbers.
> > >
> > > Implementation is also ready.
> > >
> > > Now that we have a syntax for these literals it’s clear that we
> > > want to
> > > use them in the show instances.
> > >
> > >
> > > There is no risk of breaking Show-Read-roundtripping, as Read
> > > instances
> > > cannot be derived (at the moment).
> > >
> > > This is a change in behavior of Show, so we should think for a
> > > moment
> > > how this affects stability. But none of the libraries in
> > > libraries/, in
> > > particularly not base, are affected by this change, according to
> > > Krzysztof.
> > >
> > > So I recommend to accept this.
> > >
> > > Cheers,
> > > Joachim
> > >
> > >
> > >
> > > _______________________________________________
> > > ghc-steering-committee mailing list
> > > ghc-steering-committee at haskell.org
> > >
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>
> --
> 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
>


-- 
Arnaud Spiwack
Director, Research at https://moduscreate.com and https://tweag.io.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20230706/04b28fcf/attachment.html>

From arnaud.spiwack at tweag.io  Fri Jul  7 07:43:46 2023
From: arnaud.spiwack at tweag.io (Arnaud Spiwack)
Date: Fri, 7 Jul 2023 09:43:46 +0200
Subject: [ghc-steering-committee] =?utf-8?q?Language_Extension_Policy_?=
	=?utf-8?b?4oCTIFJvdW5kIDM=?=
Message-ID: <CAGwnsnkwsp8FbQ5bj+zMrkNH6JpODNaczYVHB2GxSz+9aZMahw@mail.gmail.com>

Dear all,

For this round, I'd like to build on the results of last round [1]. One
thing that strikes me in the results, bearing in mind that 6 out of 10
members answered the question directly, and that none of this is without
dissent anyway, is that there seems to be a general feeling that extension
should not stay forever.

What I'm reading is that most respondents seem to believe that when an
extension becomes part of GHC20xx, it should be removed (with a deprecation
period, I'd imagine): if you want the feature, use GHC20xx.

Now, before I explore this question further, I should acknowledge that this
doesn't directly help answering the questions that I set to resolve when
this all began. Namely, under what principles do we judge extensions (in
particular whether a proposal should be one of several extensions). But I
think it's likely to help. I'm starting with this conversation because it's
relatively concrete, probably less controversial than other questions, and
as such, I'm hoping that it'll help us discuss the more difficult questions
with a little more understanding of what we collectively believe.

Let's explore what it would mean for an extension to be removed.
- The extension wouldn't appear in `$ ghc --show-options` (currently `$ ghc
--show-options | grep '\-X'` has 268 lines, almost every extension accounts
for 2 lines)
- The programmer can't turn the extension on or off directly
- The documentation, in the user manual, of the corresponding feature would
be moved from the “Language extension” section to somewhere else (maybe a
new section “Language features”? Not sure what is natural here)
- Error messages about the feature not being activated would stop
suggesting you use the extension, but instead that you use one of the
appropriate GHC20xx.
- For some extension, we could provide a warning (off by default) to allow
those who want to avoid the corresponding to disallow it in their codebase.
But certainly not all extensions would be turned into warnings: I don't
anticipate anybody will want to specifically avoid -XBinaryLiteral for
instance.
- Am I forgetting something?

It doesn't mean that the extension must disappear in the implementation of
GHC: this is an implementation detail (maybe it'll be beneficial for some
extensions to be removed and other not, I don't feel capable of
anticipating this). But the extension would not be visible or accessible to
the user.

Now the question is: ignoring the question of whether we have time to
retroactively do this, does this look like this would be part of your ideal
vision for GHC. If not, please argue.

[1]
https://docs.google.com/spreadsheets/d/1cRTJ2go5opXjIp-kojR_eOA-RWNBq2jzmecoSfhnvuE/edit?usp=sharing

-- 
Arnaud Spiwack
Director, Research at https://moduscreate.com and https://tweag.io.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20230707/195f4dfe/attachment.html>

From simon.peytonjones at gmail.com  Fri Jul  7 08:20:47 2023
From: simon.peytonjones at gmail.com (Simon Peyton Jones)
Date: Fri, 7 Jul 2023 09:20:47 +0100
Subject: [ghc-steering-committee] =?utf-8?q?Language_Extension_Policy_?=
	=?utf-8?b?4oCTIFJvdW5kIDM=?=
In-Reply-To: <CAGwnsnkwsp8FbQ5bj+zMrkNH6JpODNaczYVHB2GxSz+9aZMahw@mail.gmail.com>
References: <CAGwnsnkwsp8FbQ5bj+zMrkNH6JpODNaczYVHB2GxSz+9aZMahw@mail.gmail.com>
Message-ID: <CAJKmMz_NLY2EJ5V=TxpiTe5N6nhnPdEthnfuOaEBugt3_jqb-w@mail.gmail.com>

>
> What I'm reading is that most respondents seem to believe that when an
> extension becomes part of GHC20xx, it should be removed (with a deprecation
> period, I'd imagine): if you want the feature, use GHC20xx.
>

I don't have a strong opinion myself either way.  But I am a little
concerned that if we decided to do it, we'd then have to pour energy into
implementation (admittedly not hard, just deleting extension-parsing code
and updating documentation) and publicity.  More controversially, zillions
of library authors would be forced to update their packages.  In pursuit of
what?  A compiler that can do slightly less than it could before the change.

So I'm a bit sceptical.  What would sway me is if our users consistently
said "yes!  Please remove those extensions in favour of GHC20xx".   The
question is concrete enough that we could survey our users, and I think we
probably should before doing this, even if there is a consensus among us.

Simon

On Fri, 7 Jul 2023 at 08:44, Arnaud Spiwack <arnaud.spiwack at tweag.io> wrote:

> Dear all,
>
> For this round, I'd like to build on the results of last round [1]. One
> thing that strikes me in the results, bearing in mind that 6 out of 10
> members answered the question directly, and that none of this is without
> dissent anyway, is that there seems to be a general feeling that extension
> should not stay forever.
>
> What I'm reading is that most respondents seem to believe that when an
> extension becomes part of GHC20xx, it should be removed (with a deprecation
> period, I'd imagine): if you want the feature, use GHC20xx.
>
> Now, before I explore this question further, I should acknowledge that
> this doesn't directly help answering the questions that I set to resolve
> when this all began. Namely, under what principles do we judge extensions
> (in particular whether a proposal should be one of several extensions). But
> I think it's likely to help. I'm starting with this conversation because
> it's relatively concrete, probably less controversial than other questions,
> and as such, I'm hoping that it'll help us discuss the more difficult
> questions with a little more understanding of what we collectively believe.
>
> Let's explore what it would mean for an extension to be removed.
> - The extension wouldn't appear in `$ ghc --show-options` (currently `$
> ghc --show-options | grep '\-X'` has 268 lines, almost every extension
> accounts for 2 lines)
> - The programmer can't turn the extension on or off directly
> - The documentation, in the user manual, of the corresponding feature
> would be moved from the “Language extension” section to somewhere else
> (maybe a new section “Language features”? Not sure what is natural here)
> - Error messages about the feature not being activated would stop
> suggesting you use the extension, but instead that you use one of the
> appropriate GHC20xx.
> - For some extension, we could provide a warning (off by default) to allow
> those who want to avoid the corresponding to disallow it in their codebase.
> But certainly not all extensions would be turned into warnings: I don't
> anticipate anybody will want to specifically avoid -XBinaryLiteral for
> instance.
> - Am I forgetting something?
>
> It doesn't mean that the extension must disappear in the implementation of
> GHC: this is an implementation detail (maybe it'll be beneficial for some
> extensions to be removed and other not, I don't feel capable of
> anticipating this). But the extension would not be visible or accessible to
> the user.
>
> Now the question is: ignoring the question of whether we have time to
> retroactively do this, does this look like this would be part of your ideal
> vision for GHC. If not, please argue.
>
> [1]
> https://docs.google.com/spreadsheets/d/1cRTJ2go5opXjIp-kojR_eOA-RWNBq2jzmecoSfhnvuE/edit?usp=sharing
>
> --
> Arnaud Spiwack
> Director, Research at https://moduscreate.com and https://tweag.io.
> _______________________________________________
> 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/20230707/6653bb99/attachment-0001.html>

From chris at chrisdornan.com  Fri Jul  7 11:59:29 2023
From: chris at chrisdornan.com (Chris Dornan)
Date: Fri, 7 Jul 2023 12:59:29 +0100
Subject: [ghc-steering-committee] =?utf-8?q?Language_Extension_Policy_?=
 =?utf-8?b?4oCTIFJvdW5kIDM=?=
In-Reply-To: <CAGwnsnkwsp8FbQ5bj+zMrkNH6JpODNaczYVHB2GxSz+9aZMahw@mail.gmail.com>
References: <CAGwnsnkwsp8FbQ5bj+zMrkNH6JpODNaczYVHB2GxSz+9aZMahw@mail.gmail.com>
Message-ID: <28F5A63C-9E18-436F-BBD3-355EEC5FDEEE@chrisdornan.com>

Arnoud,

Sorry, I do have a problem with this process.

I think this committee needs to be really careful about trying to, in effect, rationalise and reshape Haskell. You have expressed here and elsewhere I think how difficult this process is.  If we are going to make any progress I think we need a measure of candour added to this discussion that I feel is currently missing.

There appears to be a widespread feeling that Haskell is suffering from committee-itus, leading us to a bloated language, causing us to lose out to more nimble competitors that can rely on industrial benefactors to weald the iron fist and shape a more compelling product -- which then proceeds to 'eat our lunch'. (We can probably see this kind of dialectic playing out in the wider world where democratic traditions are getting a bad rep with more streamlined autocratic methods gaining traction in the face of existential challenges.)

I want to float an alternative -- not necessarily one that I subscribe to -- but one that I think we should bear in mind. In this telling, the community has just settled down from the communal strife that nearly ended it immediately before the formation of the HF.  With the effort put into dowsing those fires now starting to pay off, the community is starting to heal and gather for The Next Big Thing (TM). That creates a vacuum that is looking to be filled and inevitably folks are going to have visions about what the future of Haskell should be, and seek to propagate those in the wider community. To me it seems obvious, that unskilful initiatives will encounter pushback and could tip us into another round of conflict -- one that we can ill afford. If you want to see how easily this can happen just look at the tremendous difficulty the GHC team had in getting agreement for what I assumed was a really straightforward reorganisation of how the GHC team structures its internal libraries. It encountered strong pushback from the CLC and the resulting discussion was highly illuminating on many levels.

My takeaway is never try to short circuit messy consensus building on the grounds that we cannot afford it. What we should have learned by now is that this is an illusion, that we cannot afford to not build consensus. I think we should trust that we are all invested in the success of the wider project, that we are all rational and well intentioned. If we are having difficulty reaching consensus despite extensive open discussion then that is probably for a good reason, and not likely because of various shortcomings in the dissenters.

More specifically my problem with the process that we are undertaking is that I get the strong sense that although we are ostensibly embarking on a framework to make sense of GHC-Haskell language extensions, there is a push by those that subscribe to the Haskell-needs-rationalising thesis to use this process to rationalise GHC-Haskell going forward, and it makes me deeply uncomfortable. To be clear, I am not necessarily against rationalising GHC-Haskell -- just that if we are going to do it then it needs to be done super carefully (and probably incrementally). I think ff we are going to reshape GHC-Haskell then we are going to have to get everyone in the steering committee entirely on board, but also we will need to think about how build consensus in the wider community for such changes.

I have tried to indicate clearly in the discussion that I think GHC should be supporting pretty much every current use case. But when I read that we can see a kernel of support for something in 6 out of 10 board members and that should use that as the basis for the next round of refinement then I worry.

Something that I want to make clear is that I am not at all persuaded by an argument that we can see GHC is clearly being used for purpose X but that purpose could be fulfilled by some alternative tool (a linter say) so let's stop developers from being able to use GHC in this way and force them to use the alternative tools.

Even milder reforms like deleting extensions that clearly have been superseded should be done with great care. Thousands of packages that could require revision to work with modern GHCs and that can create significant organisational problems, never mind the social problems.

I don't want to come across as all negative here so I will propose an alternative way of approaching reform.

An Alternative

Why don't we approach this like we would refactor a codebase. The first phase in any refactoring is to invest a great deal of time and effort doing precisely nothing of course. Here we are reshaping the code according to our revised understanding of what the various modules should do and how they should be organised, but without changing the overall behaviour of the system. Done rightly, we can carry out our revolution non-disruptively until we are ready to make the actual change, at which point the change itself becomes almost trivial.

Applied to our situation: if we believe radical change is necessary then we are going to have to put in the hard yards to bring the community into alignment with our way of thinking but without disrupting anyone. It is very important to take disruption right off the table, otherwise you we just going to encounter vigorous pushback to even establishing a shared conceptual framework. This is especially true if you propose a new conceptual framework with a thinly disguised radical program at its core.

I am really proposing that we spend some time merely understanding how GHC and its language extensions are actually being used without any view to deciding what is a legitimate use or not. Getting agreement and buy-in for this will be challenging in itself (and incredibly valuable I might add).

But we have to do this in stages. Build the conceptual framework first, including the wider shared understanding of it. Then, and only then, contemplate making any disruptive change.

Chris



> On 7 Jul 2023, at 08:43, Arnaud Spiwack <arnaud.spiwack at tweag.io> wrote:
> 
> Dear all,
> 
> For this round, I'd like to build on the results of last round [1]. One thing that strikes me in the results, bearing in mind that 6 out of 10 members answered the question directly, and that none of this is without dissent anyway, is that there seems to be a general feeling that extension should not stay forever.
> 
> What I'm reading is that most respondents seem to believe that when an extension becomes part of GHC20xx, it should be removed (with a deprecation period, I'd imagine): if you want the feature, use GHC20xx.
> 
> Now, before I explore this question further, I should acknowledge that this doesn't directly help answering the questions that I set to resolve when this all began. Namely, under what principles do we judge extensions (in particular whether a proposal should be one of several extensions). But I think it's likely to help. I'm starting with this conversation because it's relatively concrete, probably less controversial than other questions, and as such, I'm hoping that it'll help us discuss the more difficult questions with a little more understanding of what we collectively believe.
> 
> Let's explore what it would mean for an extension to be removed.
> - The extension wouldn't appear in `$ ghc --show-options` (currently `$ ghc --show-options | grep '\-X'` has 268 lines, almost every extension accounts for 2 lines)
> - The programmer can't turn the extension on or off directly
> - The documentation, in the user manual, of the corresponding feature would be moved from the “Language extension” section to somewhere else (maybe a new section “Language features”? Not sure what is natural here)
> - Error messages about the feature not being activated would stop suggesting you use the extension, but instead that you use one of the appropriate GHC20xx.
> - For some extension, we could provide a warning (off by default) to allow those who want to avoid the corresponding to disallow it in their codebase. But certainly not all extensions would be turned into warnings: I don't anticipate anybody will want to specifically avoid -XBinaryLiteral for instance.
> - Am I forgetting something?
> 
> It doesn't mean that the extension must disappear in the implementation of GHC: this is an implementation detail (maybe it'll be beneficial for some extensions to be removed and other not, I don't feel capable of anticipating this). But the extension would not be visible or accessible to the user.
> 
> Now the question is: ignoring the question of whether we have time to retroactively do this, does this look like this would be part of your ideal vision for GHC. If not, please argue.
> 
> [1] https://docs.google.com/spreadsheets/d/1cRTJ2go5opXjIp-kojR_eOA-RWNBq2jzmecoSfhnvuE/edit?usp=sharing
> 
> -- 
> Arnaud Spiwack
> Director, Research at https://moduscreate.com <https://moduscreate.com/> and https://tweag.io <https://tweag.io/>.
> _______________________________________________
> 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/20230707/68038d3c/attachment.html>

From mail at joachim-breitner.de  Sat Jul  8 12:34:04 2023
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Sat, 08 Jul 2023 14:34:04 +0200
Subject: [ghc-steering-committee] =?utf-8?q?Language_Extension_Policy_?=
 =?utf-8?b?4oCTIFJvdW5kIDM=?=
In-Reply-To: <CAGwnsnkwsp8FbQ5bj+zMrkNH6JpODNaczYVHB2GxSz+9aZMahw@mail.gmail.com>
References: <CAGwnsnkwsp8FbQ5bj+zMrkNH6JpODNaczYVHB2GxSz+9aZMahw@mail.gmail.com>
Message-ID: <e076399f7e37fc67707949ad042978eb0e13cc7b.camel@joachim-breitner.de>

Hi,

good input!

Am Freitag, dem 07.07.2023 um 09:43 +0200 schrieb Arnaud Spiwack:
> What I'm reading is that most respondents seem to believe that when
> an extension becomes part of GHC20xx, it should be removed (with a
> deprecation period, I'd imagine): if you want the feature, use
> GHC20xx.

TL;DR: Yes, if “remove” means “remove from sight from developers
working on “modern” code; but not when compiling “old” code.


this indeed sounds surprisingly hard, and it may depend on what
“removes” mean.

I do believe that the 2^n complexity is hurting us. But I also do
believe that not being to compile old code with new compilers is
hurting us.

So on the one hand I hope that in a hopefully not so distant future,
nobody on up-to-day code will even have to know that -XDeriveFunctor 
was a thing. It should just work by default. The documentation should
frame it as a “normal” feature, not an “extension”. And if the compiler
encounters a Haskell2010 module that tries to derive Functor, it should
probably indeed suggest “please use GHC20xx”.

On the other hand, as long as we can afford the engineering effort, we
can keep supporting Haskell98+DeriveFunctor, so that existing code
keeps working.

This already helps a bit fighting the 2^n mental complexity, because
the set of extensions a (non-archaeological) developer encounters is
smaller.

It further help with the 2^n implementation complexity if we’d say

 * Old extensions cannot be turned off. So if you have choose
   LANGAUGE GHC2024 as the language edition, you simply don’t get to
   select -XNoDeriveFunctor.
   (Maybe we offer _warnings_ if people want help avoiding some 
   feature.)

 * New extensions can only be used with new based editions. If we get 
   add -XFuzzyTypes next year, this feature is only available in 
   modules that have GHC2024 as the base language edition

This means, for example, that nobody has to worry about the interaction
between FuzzyTypes with NoDeriveFunctor, and the 2^n explosion gets
better.

(I think this is very close to what you are saying?)

Cheers,
Joachim

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


From vlad.z.4096 at gmail.com  Sun Jul  9 04:53:15 2023
From: vlad.z.4096 at gmail.com (Vladislav)
Date: Sun, 09 Jul 2023 06:53:15 +0200
Subject: [ghc-steering-committee] Base library organisation
In-Reply-To: <CAJKmMz8pCy5fgYsgU1NvyC1mJm1Fjeaqc+ndKgYCs_yaa-EQYA@mail.gmail.com>
References: <CAJKmMz-VCBsWarL-uDhS=vfNPOKecdnHfbxPTmwM9zP1cKYW1Q@mail.gmail.com>
 <CANsrgPKhcaxa6Kd1_fPr3_jygvZf1SsrUE1xTmHQc7yZcKZCUg@mail.gmail.com>
 <CAJKmMz8pCy5fgYsgU1NvyC1mJm1Fjeaqc+ndKgYCs_yaa-EQYA@mail.gmail.com>
Message-ID: <RWIIXR.T0DPXRQV2Z3P2@gmail.com>

This proposal has just popped up in another discussion, and its 
implications dawned on me.

I see two major issues with the proposal in its current form:

1. Proposal authors shouldn't need to interact with two committees 
instead of one. It is generally fine to have coordination between 
committees, so I can imagine a system where GHC SC cannot approve a 
proposal on its own and must contact CLC when a proposal touches base. 
Proposal authors mustn't be bothered with the intricacies of this 
process, they need to write a single document, submit it on a single 
platform, and then either have it accepted or rejected, whether by GHC 
SC alone or by a joint GHC SC + CLC committee.

2. Proposal implementors need a single source of truth for the accepted 
changes. If the proposal document has been marked accepted, it means 
that it's ready for implementation. Now, I have no problem whatsoever 
with involving CLC before a proposal is accepted, but once it's done, 
it's done. It's quite important to be able to point potential 
contributors to a document that describes the changes we want to see in 
GHC and its libraries, and it can't be that parts of this document are 
actually accepted and parts of it are 
kind-of-accepted-but-non-binding-and-another-proposal-on-another-platform-is-pending.

So I agree with the general idea that it's important to get CLC 
involved, but for the sake of proposal authors and proposal 
implementors, this should be a committee-to-committee interaction, not 
a person-to-two-committees interaction; and acceptance of a proposal 
needs to be a single atomic operation instead of having 
kind-of-accepted documents floating around in the ghc-proposals repo.

Vlad

On jeu., juin 29 2023 at 09:49:09 +01:00:00, Simon Peyton Jones 
<simon.peytonjones at gmail.com> wrote:
>>   make the GHC proposal in conjunction with a CLC proposal and land 
>> them in GHC together. Streamlining this process would be good
> 
> That is absolutely an option, yes.
> 
> Simon
> 
> On Thu, 29 Jun 2023 at 08:27, Simon Marlow <marlowsd at gmail.com 
> <mailto:marlowsd at gmail.com>> wrote:
>> The link in the email is broken BTW, is there any updated URL?
>> 
>> Just based on the summary in the email, what immediately springs to 
>> mind is that adding functions to ghc-experimental and then moving 
>> them to base implies an extra migration that clients have to do in 
>> the future (would the APIs in ghc-experimental be deprecated first? 
>> For how long? etc.). It probably makes sense only to do this for 
>> additions of fairly large new APIs, and for smaller changes we 
>> should probably shortcut the process and make the GHC proposal in 
>> conjunction with a CLC proposal and land them in GHC together. 
>> Streamlining this process would be good. Maybe the actual proposal 
>> already says a lot of this?
>> 
>> Cheers
>> Simon
>> 
>> 
>> On Thu, 15 Jun 2023 at 10:04, Simon Peyton Jones 
>> <simon.peytonjones at gmail.com <mailto:simon.peytonjones at gmail.com>> 
>> wrote:
>>> Dear GHC Steering Committee
>>> 
>>> Over the last few weeks, Ben Gamari and I have been discussing with 
>>> Andrew and Julian from the Core Libraries Committee how to make the 
>>> Core Libraries Committee and the GHC developers work together more 
>>> fluidly; and that includes the GHC Steering Committee.
>>> 
>>> We now have a fairly well fleshed out proposal here. 
>>> <https://github.com/Ericson2314/tech-proposals/blob/ghc-base-libraries/proposals/accepted/050-ghc-base-libraries.rst>
>>> 
>>> I hope you like it.  As far as this committee is concerned there 
>>> are two particular points of note
>>> We propose a new package, *ghc-experimental*, which depends on 
>>> *base*.  Many GHC proposals involve defining new types and 
>>> functions.  The idea is that these would initially be in 
>>> *ghc-experimental*.  After they stabilise and become widely 
>>> adopted, the author (or anyone else) can make a CLC proposal to 
>>> move them to *base*, which has much stronger stability 
>>> guarantees.Section 5.1 suggests a mechanism to involve CLC members 
>>> in proposals that involve new functions and types, at an earlier 
>>> stage.  Some involve /changing/existing types and functions.  It is 
>>> clearly unproductive for us to debate such things at length, and 
>>> only /then/to land it on the CLC.
>>> 
>>> Section 5.1 also suggests that proposals should explicitly (in a 
>>> separate section) call out
>>> What new types and functions it definesWhat existing types and 
>>> functions are changed.
>>> We should add that to our template.
>>> 
>>> At the moment we are just sharing the proposal with relevant 
>>> stakeholders (yourselves, CLC, stack folk, cabal folk etc), so that 
>>> we can polish any rough edges before making it public.
>>> 
>>> So, any views?  Personally I think this is a Big Step Forward.
>>> 
>>> Simon
>>> 
>>> 
>>> 
>>>  _______________________________________________
>>>  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>

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

From mail at joachim-breitner.de  Sun Jul  9 10:19:08 2023
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Sun, 09 Jul 2023 12:19:08 +0200
Subject: [ghc-steering-committee] Base library organisation
In-Reply-To: <RWIIXR.T0DPXRQV2Z3P2@gmail.com>
References: <CAJKmMz-VCBsWarL-uDhS=vfNPOKecdnHfbxPTmwM9zP1cKYW1Q@mail.gmail.com>
 <CANsrgPKhcaxa6Kd1_fPr3_jygvZf1SsrUE1xTmHQc7yZcKZCUg@mail.gmail.com>
 <CAJKmMz8pCy5fgYsgU1NvyC1mJm1Fjeaqc+ndKgYCs_yaa-EQYA@mail.gmail.com>
 <RWIIXR.T0DPXRQV2Z3P2@gmail.com>
Message-ID: <6c9b2d312a2a8d6243e154c8b879f61357b73bfb.camel@joachim-breitner.de>

Hi,

Am Sonntag, dem 09.07.2023 um 06:53 +0200 schrieb Vladislav:
> So I agree with the general idea that it's important to get CLC
> involved, but for the sake of proposal authors and proposal
> implementors, this should be a committee-to-committee interaction,
> not a person-to-two-committees interaction

I agree, that would be desirable.

Could we invite a CLC member to join the GHC committee? Either a full
member if someone wants, or a special “observer” who represents the
(procedural) interests of the CLC? A bit like the Holy Sea has a seat
at the UN…


> and acceptance of a proposal needs to be a single atomic operation
> instead of having kind-of-accepted documents floating around in the
> ghc-proposals repo.

That’s a bit harder because acceptance means different things in the
two proposal systems:

 * The GHC proposal proposal (so far) says “This idea and design is
   good” but the implementation can still fail (too hard, technical
   issues, possibly even rejection of the GHC devs based on
   implementation isuses). 
 * The CLC committee decides (usually) on almost ready-to-merge
   proposals, with an impact assessment and possibly patches to
   libraries out there.

There is clearly an mismatch here that seems to be hard to resolve
without changing at least one of the two processes (which are like that
for good reasons). But at least we should try to make this transparent:
Get a (non-binding) positive assessment of the CLC on proposals that
touch base when accepting a GHC proposal, and communicate the need to
get final approval when the implementation is done

Cheers,
Joachim



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

From ghc-sc at schmits.me  Sun Jul  9 10:49:08 2023
From: ghc-sc at schmits.me (Torsten Schmits)
Date: Sun, 9 Jul 2023 12:49:08 +0200
Subject: [ghc-steering-committee] Base library organisation
In-Reply-To: <6c9b2d312a2a8d6243e154c8b879f61357b73bfb.camel@joachim-breitner.de>
References: <CAJKmMz-VCBsWarL-uDhS=vfNPOKecdnHfbxPTmwM9zP1cKYW1Q@mail.gmail.com>
 <CANsrgPKhcaxa6Kd1_fPr3_jygvZf1SsrUE1xTmHQc7yZcKZCUg@mail.gmail.com>
 <CAJKmMz8pCy5fgYsgU1NvyC1mJm1Fjeaqc+ndKgYCs_yaa-EQYA@mail.gmail.com>
 <RWIIXR.T0DPXRQV2Z3P2@gmail.com>
 <6c9b2d312a2a8d6243e154c8b879f61357b73bfb.camel@joachim-breitner.de>
Message-ID: <2339b927-af0a-26c5-2b4d-8a98422454b9@schmits.me>

Maybe the proposal template could include a section about potential CLC 
interactions, to take advantage of the pre-submission discussion. People 
usually debate minute details on there quite eagerly, and it would 
provide a contact point and overview for CLC members.

On 7/9/23 12:19, Joachim Breitner wrote:
> There is clearly an mismatch here that seems to be hard to resolve
> without changing at least one of the two processes (which are like that
> for good reasons). But at least we should try to make this transparent:
> Get a (non-binding) positive assessment of the CLC on proposals that
> touch base when accepting a GHC proposal, and communicate the need to
> get final approval when the implementation is done
>


From ghc-sc at schmits.me  Sun Jul  9 10:58:36 2023
From: ghc-sc at schmits.me (Torsten Schmits)
Date: Sun, 9 Jul 2023 12:58:36 +0200
Subject: [ghc-steering-committee] Base library organisation
In-Reply-To: <6c9b2d312a2a8d6243e154c8b879f61357b73bfb.camel@joachim-breitner.de>
References: <CAJKmMz-VCBsWarL-uDhS=vfNPOKecdnHfbxPTmwM9zP1cKYW1Q@mail.gmail.com>
 <CANsrgPKhcaxa6Kd1_fPr3_jygvZf1SsrUE1xTmHQc7yZcKZCUg@mail.gmail.com>
 <CAJKmMz8pCy5fgYsgU1NvyC1mJm1Fjeaqc+ndKgYCs_yaa-EQYA@mail.gmail.com>
 <RWIIXR.T0DPXRQV2Z3P2@gmail.com>
 <6c9b2d312a2a8d6243e154c8b879f61357b73bfb.camel@joachim-breitner.de>
Message-ID: <4f70e98e-906f-7195-9998-14604f305fb0@schmits.me>

Joachim, there already is a CLC member on the SC!

On 7/9/23 12:19, Joachim Breitner wrote:
>
> Could we invite a CLC member to join the GHC committee? Either a full
> member if someone wants, or a special “observer” who represents the
> (procedural) interests of the CLC? A bit like the Holy Sea has a seat
> at the UN…
>

From mail at joachim-breitner.de  Sun Jul  9 11:04:05 2023
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Sun, 09 Jul 2023 13:04:05 +0200
Subject: [ghc-steering-committee] Base library organisation
In-Reply-To: <4f70e98e-906f-7195-9998-14604f305fb0@schmits.me>
References: <CAJKmMz-VCBsWarL-uDhS=vfNPOKecdnHfbxPTmwM9zP1cKYW1Q@mail.gmail.com>
 <CANsrgPKhcaxa6Kd1_fPr3_jygvZf1SsrUE1xTmHQc7yZcKZCUg@mail.gmail.com>
 <CAJKmMz8pCy5fgYsgU1NvyC1mJm1Fjeaqc+ndKgYCs_yaa-EQYA@mail.gmail.com>
 <RWIIXR.T0DPXRQV2Z3P2@gmail.com>
 <6c9b2d312a2a8d6243e154c8b879f61357b73bfb.camel@joachim-breitner.de>
 <4f70e98e-906f-7195-9998-14604f305fb0@schmits.me>
Message-ID: <37b796eb3dce691e2e92246209192a2da3402a5c.camel@joachim-breitner.de>

Hi,

Am Sonntag, dem 09.07.2023 um 12:58 +0200 schrieb Torsten Schmits via
ghc-steering-committee:
> Maybe the proposal template could include a section about potential
> CLC interactions, to take advantage of the pre-submission discussion.
> People  usually debate minute details on there quite eagerly, and it
> would  provide a contact point and overview for CLC members.

Great idea, yes! Would you care to propose some wording (in a PR
updating the template)?

> Joachim, there already is a CLC member on the SC!

oh, of course. Sorry, Moritz!

Then the question, put bluntly, becomes: Moritz, would you be willing
to represent the CLC’s interests in the GHC proposal?

(It’s ok to say “no”, we can try to share that responsibility, or try
to find someone to fill that role.)

Cheers,
Joachim

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


From ghc-sc at schmits.me  Sun Jul  9 11:05:24 2023
From: ghc-sc at schmits.me (Torsten Schmits)
Date: Sun, 9 Jul 2023 13:05:24 +0200
Subject: [ghc-steering-committee] Base library organisation
In-Reply-To: <37b796eb3dce691e2e92246209192a2da3402a5c.camel@joachim-breitner.de>
References: <CAJKmMz-VCBsWarL-uDhS=vfNPOKecdnHfbxPTmwM9zP1cKYW1Q@mail.gmail.com>
 <CANsrgPKhcaxa6Kd1_fPr3_jygvZf1SsrUE1xTmHQc7yZcKZCUg@mail.gmail.com>
 <CAJKmMz8pCy5fgYsgU1NvyC1mJm1Fjeaqc+ndKgYCs_yaa-EQYA@mail.gmail.com>
 <RWIIXR.T0DPXRQV2Z3P2@gmail.com>
 <6c9b2d312a2a8d6243e154c8b879f61357b73bfb.camel@joachim-breitner.de>
 <4f70e98e-906f-7195-9998-14604f305fb0@schmits.me>
 <37b796eb3dce691e2e92246209192a2da3402a5c.camel@joachim-breitner.de>
Message-ID: <5e040b06-1a09-4f19-8895-f484f77f86e9@schmits.me>

On 7/9/23 13:04, Joachim Breitner wrote:

> Hi,
>
> Am Sonntag, dem 09.07.2023 um 12:58 +0200 schrieb Torsten Schmits via
> ghc-steering-committee:
>> Maybe the proposal template could include a section about potential
>> CLC interactions, to take advantage of the pre-submission discussion.
>> People  usually debate minute details on there quite eagerly, and it
>> would  provide a contact point and overview for CLC members.
> Great idea, yes! Would you care to propose some wording (in a PR
> updating the template)?
>
Gladly!

From mail at joachim-breitner.de  Sun Jul  9 19:17:32 2023
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Sun, 09 Jul 2023 21:17:32 +0200
Subject: [ghc-steering-committee] #596: sized literals in Show,
 rec: accept
In-Reply-To: <0a90849c93122ead8026bf5f9414f8da91a5f3c2.camel@joachim-breitner.de>
References: <0a90849c93122ead8026bf5f9414f8da91a5f3c2.camel@joachim-breitner.de>
Message-ID: <e59a833a18a04f3ce077d175272223aaf8d4e413.camel@joachim-breitner.de>

Hi,

I only got positive feedback, so I’ll merge this in a few days.

Cheers,
Joachim

Am Donnerstag, dem 29.06.2023 um 08:20 +0200 schrieb Joachim Breitner:
> Dear committee,
> 
> Krzysztof Gogolewski in
> https://github.com/ghc-proposals/ghc-proposals/pull/596
> amends the sized literals proposal so that GHC uses the syntax 
> 42#Int8 instead of (intToInt8# 42#) in the stock derived Show instances
> for data types with sized unboxed numbers.
> 
> Implementation is also ready.
> 
> Now that we have a syntax for these literals it’s clear that we want to
> use them in the show instances. 
> 
> 
> There is no risk of breaking Show-Read-roundtripping, as Read instances
> cannot be derived (at the moment).
> 
> This is a change in behavior of Show, so we should think for a moment
> how this affects stability. But none of the libraries in libraries/, in
> particularly not base, are affected by this change, according to
> Krzysztof.
> 
> So I recommend to accept this.
> 
> Cheers,
> Joachim
> 
> 
> 

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


From mail at joachim-breitner.de  Sun Jul  9 19:18:28 2023
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Sun, 09 Jul 2023 21:18:28 +0200
Subject: [ghc-steering-committee] Please consider GHC Proposal #581 for
 acceptance.
In-Reply-To: <CAKfdd-xreE+-NQjqkPnbym4SFyba-qYbMxvE=ZUMxwbpnM+9tw@mail.gmail.com>
References: <CAKfdd-xreE+-NQjqkPnbym4SFyba-qYbMxvE=ZUMxwbpnM+9tw@mail.gmail.com>
Message-ID: <7159d26b3282d2173635faa423a8b70893169122.camel@joachim-breitner.de>

Hi,

this got lots of positive feedback. Will merge in a few days.

Cheers,
Joachim

Am Mittwoch, dem 28.06.2023 um 07:27 +0200 schrieb Moritz Angermann:
> Dear Steering Committee,
> 
> Adam, Artyom and Chris wrote the Namespace-specified imports
> proposal. It seeks to make importing more impressive, allowing import
> statements to choose from the type and data namespaces explicitly.
> 
> I believe this proposal adds value in expressiveness to import
> statements. After the last syntax refinement comes naturally to the
> language. I recommend acceptance of this proposal.
> 
> Best regards,
>  Moritz
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

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


From simon.peytonjones at gmail.com  Sun Jul  9 21:27:20 2023
From: simon.peytonjones at gmail.com (Simon Peyton Jones)
Date: Sun, 9 Jul 2023 22:27:20 +0100
Subject: [ghc-steering-committee] Base library organisation
In-Reply-To: <RWIIXR.T0DPXRQV2Z3P2@gmail.com>
References: <CAJKmMz-VCBsWarL-uDhS=vfNPOKecdnHfbxPTmwM9zP1cKYW1Q@mail.gmail.com>
 <CANsrgPKhcaxa6Kd1_fPr3_jygvZf1SsrUE1xTmHQc7yZcKZCUg@mail.gmail.com>
 <CAJKmMz8pCy5fgYsgU1NvyC1mJm1Fjeaqc+ndKgYCs_yaa-EQYA@mail.gmail.com>
 <RWIIXR.T0DPXRQV2Z3P2@gmail.com>
Message-ID: <CAJKmMz-0OD6ypQUDUOWbXQNeaLQOHEMCqEhbv58jpdr7EOaxcA@mail.gmail.com>

This protocol is tricky to get right.  But I think that the ideas sketched
in Section 6.1 come close.  (For completeness, here is the current draft
plan.)
<https://github.com/Ericson2314/tech-proposals/blob/ghc-base-libraries/proposals/accepted/050-ghc-base-libraries.rst>

First, we should make explicit in every proposal what library changes (if
any) there are, and to which libraries.  All by itself that will be helpful.

Second. the ghc-experimental library provides authors with more options
than we had in the past:

   - They can propose changes to base, and accept the additional
   constraints of discussing with the CLC; including any changes that
   subsequently prove to be necessary or desirable
   - Or, in many cases, they can deliver their proposal through
   ghc-experimental, which CLC is quite content for the GHC CS to curate.

Third, we envisage that the shepherd will explicitly invite the CLC to
express a non-binding opinion about any proposal modifying base.   That
greatly lessens the risk of a proposal being accepted that the CLC is
unhappy with.  No one wins if that happens!

The "non-binding" bit is important: the devil is sometimes in the details.
But remember that acceptance of a GHC proposal is *also* non-binding.  We
explicitly say that if the implementation adds too much complexity, or
shows up new issues that were not discussed when the proposal was accepted,
then we may not land it.  Acceptance is a decision in principle.

(Side note.  I don't think we should be legalistic about this, but if CLC
does not voice any objection to changes to base explicitly called out in
the proposal, then it would be very unusual for them to subsequently reject
outright a CLC proposal to implement those same changes.  Let's jump that
bridge if we come to it; I don't think we will!)

So fourth, the protocol does envisage that, as part of the implementation
process, the implementor will make a CLC proposal.  It should be no more
than a copy/paste of the relevant section from the proposal, but it'll be
at the point of "I firmly intend to implement this proposal, so it is worth
requesting CLC bandwidth to discuss the detailed specifics of the API
changes".

This all makes sense to me.  I hope it does to you all, as members of the
GHC SC. Please say if not.  I'm keen to get this tied up so we can
publicise it.

I would be happy to elaborate Section 6.1, to make it more clear and
specific, if anyone has some draft text they would like to propose.

Simon

On Sun, 9 Jul 2023 at 05:53, Vladislav <vlad.z.4096 at gmail.com> wrote:

> This proposal has just popped up in another discussion, and its
> implications dawned on me.
>
> I see two major issues with the proposal in its current form:
>
> 1. Proposal authors shouldn't need to interact with two committees instead
> of one. It is generally fine to have coordination between committees, so I
> can imagine a system where GHC SC cannot approve a proposal on its own and
> must contact CLC when a proposal touches base. Proposal authors mustn't be
> bothered with the intricacies of this process, they need to write a single
> document, submit it on a single platform, and then either have it accepted
> or rejected, whether by GHC SC alone or by a joint GHC SC + CLC committee.
>
> 2. Proposal implementors need a single source of truth for the accepted
> changes. If the proposal document has been marked accepted, it means that
> it's ready for implementation. Now, I have no problem whatsoever with
> involving CLC before a proposal is accepted, but once it's done, it's done.
> It's quite important to be able to point potential contributors to a
> document that describes the changes we want to see in GHC and its
> libraries, and it can't be that parts of this document are actually
> accepted and parts of it are
> kind-of-accepted-but-non-binding-and-another-proposal-on-another-platform-is-pending.
>
> So I agree with the general idea that it's important to get CLC involved,
> but for the sake of proposal authors and proposal implementors, this should
> be a committee-to-committee interaction, not a person-to-two-committees
> interaction; and acceptance of a proposal needs to be a single atomic
> operation instead of having kind-of-accepted documents floating around in
> the ghc-proposals repo.
>
> Vlad
>
> On jeu., juin 29 2023 at 09:49:09 +01:00:00, Simon Peyton Jones <
> simon.peytonjones at gmail.com> wrote:
>
>   make the GHC proposal in conjunction with a CLC proposal and land them
>> in GHC together. Streamlining this process would be good
>>
>
> That is absolutely an option, yes.
>
> Simon
>
> On Thu, 29 Jun 2023 at 08:27, Simon Marlow <marlowsd at gmail.com> wrote:
>
>> The link in the email is broken BTW, is there any updated URL?
>>
>> Just based on the summary in the email, what immediately springs to mind
>> is that adding functions to ghc-experimental and then moving them to base
>> implies an extra migration that clients have to do in the future (would the
>> APIs in ghc-experimental be deprecated first? For how long? etc.). It
>> probably makes sense only to do this for additions of fairly large new
>> APIs, and for smaller changes we should probably shortcut the process and
>> make the GHC proposal in conjunction with a CLC proposal and land them in
>> GHC together. Streamlining this process would be good. Maybe the actual
>> proposal already says a lot of this?
>>
>> Cheers
>> Simon
>>
>>
>> On Thu, 15 Jun 2023 at 10:04, Simon Peyton Jones <
>> simon.peytonjones at gmail.com> wrote:
>>
>>> Dear GHC Steering Committee
>>>
>>> Over the last few weeks, Ben Gamari and I have been discussing with
>>> Andrew and Julian from the Core Libraries Committee how to make the Core
>>> Libraries Committee and the GHC developers work together more fluidly; and
>>> that includes the GHC Steering Committee.
>>>
>>> We now have a fairly well fleshed out proposal here.
>>> <https://github.com/Ericson2314/tech-proposals/blob/ghc-base-libraries/proposals/accepted/050-ghc-base-libraries.rst>
>>>
>>> I hope you like it.  As far as this committee is concerned there are two
>>> particular points of note
>>>
>>>    1. We propose a new package, *ghc-experimental*, which depends on
>>>    *base*.  Many GHC proposals involve defining new types and
>>>    functions.  The idea is that these would initially be in
>>>    *ghc-experimental*.  After they stabilise and become widely adopted,
>>>    the author (or anyone else) can make a CLC proposal to move them to
>>>    *base*, which has much stronger stability guarantees.
>>>    2. Section 5.1 suggests a mechanism to involve CLC members in
>>>    proposals that involve new functions and types, at an earlier stage.  Some
>>>    involve *changing *existing types and functions.  It is clearly
>>>    unproductive for us to debate such things at length, and only *then *to
>>>    land it on the CLC.
>>>
>>>    Section 5.1 also suggests that proposals should explicitly (in a
>>>    separate section) call out
>>>
>>>
>>>    - What new types and functions it defines
>>>    - What existing types and functions are changed.
>>>
>>> We should add that to our template.
>>>
>>> At the moment we are just sharing the proposal with relevant
>>> stakeholders (yourselves, CLC, stack folk, cabal folk etc), so that we can
>>> polish any rough edges before making it public.
>>>
>>> So, any views?  Personally I think this is a Big Step Forward.
>>>
>>> Simon
>>>
>>>
>>>
>>> _______________________________________________
>>> 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/20230709/4f1e9dc4/attachment-0001.html>

From arnaud.spiwack at tweag.io  Mon Jul 10 14:13:32 2023
From: arnaud.spiwack at tweag.io (Arnaud Spiwack)
Date: Mon, 10 Jul 2023 16:13:32 +0200
Subject: [ghc-steering-committee] =?utf-8?q?Language_Extension_Policy_?=
	=?utf-8?b?4oCTIFJvdW5kIDM=?=
In-Reply-To: <e076399f7e37fc67707949ad042978eb0e13cc7b.camel@joachim-breitner.de>
References: <CAGwnsnkwsp8FbQ5bj+zMrkNH6JpODNaczYVHB2GxSz+9aZMahw@mail.gmail.com>
 <e076399f7e37fc67707949ad042978eb0e13cc7b.camel@joachim-breitner.de>
Message-ID: <CAGwnsnnTVKLTPPJnj0Q6=Ne-CsA07pJO+0XW=c2-sSA9KV+55g@mail.gmail.com>

*@Chris:*
That's a long email 🙂. I think that when people complain about committees,
what they complain about is too many people deciding, not too few. At any
rate, as the GHC steering committee we are the designated caretakers of
GHC's flavour of Haskell. We are required to make decisions on proposals,
and often asked to consult on what the best course of action for a proposal
is. We use a set of principles as guides. Reducing the number of dialects
of GHC can either be a goal or a non-goal. But the only alternative to
choosing is not making a choice. And we'd be left in the current situation,
where different committee members pull in different directions based on
what extensions mean for them, and whether a proposal is accepted in a
shape or another is largely dependent on which committee member had more
brain cycles that week. Some of us have started this process of thinking
deeply about extensions because we observed that there was a disconnect
within the committee. And we believe that we owe the community better than
this.

That being said, I'm not advocating or even proposing sweeping changes (a
big change in policy would require, like any, a proposal). I'm asking us to
dream a little together and think about what we believe would be most
beneficial for the language. The main outcome that I'm trying to achieve is
a new set of principles relating to extensions.

*@Joachim/@Simon:*
I think both of you are bringing concern about backward compatibility. I
think there are two questions:
1. Moving forward, we could advertise extensions as being temporary, and if
you use them, you should expect to have to rewrite part of your code in the
future. Is the extra work worth it?
2. All the extensions in the past that we've been used to turn on on a
fine-grain basis represent an enormous amount of libraries. Some are
basically unmaintained, having been robust enough to go untouched for 10+
years. Rewriting this would be a tremendous effort. Is the extra work worth
it?

I take your comments as saying that the answer to (2) is almost certainly
“no”. What's your answer to (1)? I can see an argument for saying that
Haskell being a research language, extensions take longer than, say, in
Rust, to be eventually rolled in. As such, we actually expect many to have
extensions turned on, and for long enough that it would become a liability
to erase the extension in the future.

One difficulty is that it's rather fraught to let code with
`-XSomeExtension` compile while not documenting what `-XSomeExtension`
does. We could make it conspicuous in the manual that the extension is
deprecated. But would `--show-options` also contain it? We also need to
make sure that the deprecated extension is not autocompleted by IDEs (I
guess this is a setting for GHCi). I think this is started to look like the
Haskell Foundation's Stability Working Group's proposal mentioned above.

*@Joachim:*
The idea of having extensions work only against certain languages is
intriguing. I think it needs some refinement: First, -XFuzzyTypes would
work against GHC2024 or later, until it's folded into a GHC20xx. And,
probably, you'll still want to be able to call `-XNoFuzzyTypes` on some of
the GHC20xx where it is folded (maybe just 1), at least if it causes some
compatibility issues (I don't think -XDerivingFunctor is of the sort), in
order to smooth out transition.

Another question on this approach is: how would the user guide present this
information without flooding the reader with extensions that don't apply to
the GHC20xx they're using?

*@all*:
A question which can matter as part of this discussion is how much of a
maintenance burden is having so many extensions? From a pure
implementation-of-GHC point of view. Personally, it's never really been in
my way (which may simply mean that I don't contribute a lot), so I'm
focussing, in this discussion, on the impact on Haskell programmers. But
the impact on GHC developers is definitely relevant.

-- 
Arnaud Spiwack
Director, Research at https://moduscreate.com and https://tweag.io.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20230710/5a5672d7/attachment.html>

From simon.peytonjones at gmail.com  Mon Jul 10 14:25:43 2023
From: simon.peytonjones at gmail.com (Simon Peyton Jones)
Date: Mon, 10 Jul 2023 15:25:43 +0100
Subject: [ghc-steering-committee] =?utf-8?q?Language_Extension_Policy_?=
	=?utf-8?b?4oCTIFJvdW5kIDM=?=
In-Reply-To: <CAGwnsnnTVKLTPPJnj0Q6=Ne-CsA07pJO+0XW=c2-sSA9KV+55g@mail.gmail.com>
References: <CAGwnsnkwsp8FbQ5bj+zMrkNH6JpODNaczYVHB2GxSz+9aZMahw@mail.gmail.com>
 <e076399f7e37fc67707949ad042978eb0e13cc7b.camel@joachim-breitner.de>
 <CAGwnsnnTVKLTPPJnj0Q6=Ne-CsA07pJO+0XW=c2-sSA9KV+55g@mail.gmail.com>
Message-ID: <CAJKmMz9Xby3A2sVo0b3q8JRPA8RKzHATzPpG6VYGya_gBVwVVw@mail.gmail.com>

>
> A question which can matter as part of this discussion is how much of a
> maintenance burden is having so many extensions?
>

Generally, not much provided they are well-designed and orthogonal.  Some
flag-testing would disappear if the feature is permanently on.  But not
much complexity beyond that, usually.

Simon

On Mon, 10 Jul 2023 at 15:14, Arnaud Spiwack <arnaud.spiwack at tweag.io>
wrote:

> *@Chris:*
> That's a long email 🙂. I think that when people complain about
> committees, what they complain about is too many people deciding, not too
> few. At any rate, as the GHC steering committee we are the designated
> caretakers of GHC's flavour of Haskell. We are required to make decisions
> on proposals, and often asked to consult on what the best course of action
> for a proposal is. We use a set of principles as guides. Reducing the
> number of dialects of GHC can either be a goal or a non-goal. But the only
> alternative to choosing is not making a choice. And we'd be left in the
> current situation, where different committee members pull in different
> directions based on what extensions mean for them, and whether a proposal
> is accepted in a shape or another is largely dependent on which committee
> member had more brain cycles that week. Some of us have started this
> process of thinking deeply about extensions because we observed that there
> was a disconnect within the committee. And we believe that we owe the
> community better than this.
>
> That being said, I'm not advocating or even proposing sweeping changes (a
> big change in policy would require, like any, a proposal). I'm asking us to
> dream a little together and think about what we believe would be most
> beneficial for the language. The main outcome that I'm trying to achieve is
> a new set of principles relating to extensions.
>
> *@Joachim/@Simon:*
> I think both of you are bringing concern about backward compatibility. I
> think there are two questions:
> 1. Moving forward, we could advertise extensions as being temporary, and
> if you use them, you should expect to have to rewrite part of your code in
> the future. Is the extra work worth it?
> 2. All the extensions in the past that we've been used to turn on on a
> fine-grain basis represent an enormous amount of libraries. Some are
> basically unmaintained, having been robust enough to go untouched for 10+
> years. Rewriting this would be a tremendous effort. Is the extra work worth
> it?
>
> I take your comments as saying that the answer to (2) is almost certainly
> “no”. What's your answer to (1)? I can see an argument for saying that
> Haskell being a research language, extensions take longer than, say, in
> Rust, to be eventually rolled in. As such, we actually expect many to have
> extensions turned on, and for long enough that it would become a liability
> to erase the extension in the future.
>
> One difficulty is that it's rather fraught to let code with
> `-XSomeExtension` compile while not documenting what `-XSomeExtension`
> does. We could make it conspicuous in the manual that the extension is
> deprecated. But would `--show-options` also contain it? We also need to
> make sure that the deprecated extension is not autocompleted by IDEs (I
> guess this is a setting for GHCi). I think this is started to look like the
> Haskell Foundation's Stability Working Group's proposal mentioned above.
>
> *@Joachim:*
> The idea of having extensions work only against certain languages is
> intriguing. I think it needs some refinement: First, -XFuzzyTypes would
> work against GHC2024 or later, until it's folded into a GHC20xx. And,
> probably, you'll still want to be able to call `-XNoFuzzyTypes` on some of
> the GHC20xx where it is folded (maybe just 1), at least if it causes some
> compatibility issues (I don't think -XDerivingFunctor is of the sort), in
> order to smooth out transition.
>
> Another question on this approach is: how would the user guide present
> this information without flooding the reader with extensions that don't
> apply to the GHC20xx they're using?
>
> *@all*:
> A question which can matter as part of this discussion is how much of a
> maintenance burden is having so many extensions? From a pure
> implementation-of-GHC point of view. Personally, it's never really been in
> my way (which may simply mean that I don't contribute a lot), so I'm
> focussing, in this discussion, on the impact on Haskell programmers. But
> the impact on GHC developers is definitely relevant.
>
> --
> Arnaud Spiwack
> Director, Research at https://moduscreate.com and https://tweag.io.
> _______________________________________________
> 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/20230710/5c2aad22/attachment.html>

From simon.peytonjones at gmail.com  Mon Jul 10 22:05:20 2023
From: simon.peytonjones at gmail.com (Simon Peyton Jones)
Date: Mon, 10 Jul 2023 23:05:20 +0100
Subject: [ghc-steering-committee] Base library organisation
In-Reply-To: <CAJKmMz-VCBsWarL-uDhS=vfNPOKecdnHfbxPTmwM9zP1cKYW1Q@mail.gmail.com>
References: <CAJKmMz-VCBsWarL-uDhS=vfNPOKecdnHfbxPTmwM9zP1cKYW1Q@mail.gmail.com>
Message-ID: <CAJKmMz_YHSQFERR1rRuofOtnOEbsE11Q4orKwWh8VdXj2wyShQ@mail.gmail.com>

Dear Ghc-Steering-Committee

Any further views about the base-library plan
<https://github.com/Ericson2314/tech-proposals/blob/ghc-base-libraries/proposals/accepted/051-ghc-base-libraries.rst>?


We have Torsten's helpful patch
<https://github.com/ghc-proposals/ghc-proposals/pull/602>to our GHC
Proposal template.  Any views about that?

RSVP.  If you want to see any changes, can you offer concrete text that
you'd prefer to see?

I'd like to indicate our assent as a committee -- but only if we are all
happy!  CLC is voting in favour -- I expect a result in a day or two.

RSVP.  I'll take silence as assent by say Thursday. Yell if you need more
time.

Simon




On Thu, 15 Jun 2023 at 10:03, Simon Peyton Jones <
simon.peytonjones at gmail.com> wrote:

> Dear GHC Steering Committee
>
> Over the last few weeks, Ben Gamari and I have been discussing with Andrew
> and Julian from the Core Libraries Committee how to make the Core Libraries
> Committee and the GHC developers work together more fluidly; and that
> includes the GHC Steering Committee.
>
> We now have a fairly well fleshed out proposal here.
> <https://github.com/Ericson2314/tech-proposals/blob/ghc-base-libraries/proposals/accepted/050-ghc-base-libraries.rst>
>
> I hope you like it.  As far as this committee is concerned there are two
> particular points of note
>
>    1. We propose a new package, *ghc-experimental*, which depends on
>    *base*.  Many GHC proposals involve defining new types and functions.
>    The idea is that these would initially be in *ghc-experimental*.
>    After they stabilise and become widely adopted, the author (or anyone else)
>    can make a CLC proposal to move them to *base*, which has much
>    stronger stability guarantees.
>    2. Section 5.1 suggests a mechanism to involve CLC members in
>    proposals that involve new functions and types, at an earlier stage.  Some
>    involve *changing *existing types and functions.  It is clearly
>    unproductive for us to debate such things at length, and only *then *to
>    land it on the CLC.
>
>    Section 5.1 also suggests that proposals should explicitly (in a
>    separate section) call out
>
>
>    - What new types and functions it defines
>    - What existing types and functions are changed.
>
> We should add that to our template.
>
> At the moment we are just sharing the proposal with relevant stakeholders
> (yourselves, CLC, stack folk, cabal folk etc), so that we can polish any
> rough edges before making it public.
>
> So, any views?  Personally I think this is a Big Step Forward.
>
> Simon
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20230710/1bb493a8/attachment-0001.html>

From simon.peytonjones at gmail.com  Tue Jul 11 21:47:56 2023
From: simon.peytonjones at gmail.com (Simon Peyton Jones)
Date: Tue, 11 Jul 2023 22:47:56 +0100
Subject: [ghc-steering-committee] Fwd: [haskellfoundation/tech-proposals]
 GHC's base libraries: Combining stability with innovation (PR #51)
In-Reply-To: <haskellfoundation/tech-proposals/pull/51/c1631552317@github.com>
References: <haskellfoundation/tech-proposals/pull/51@github.com>
 <haskellfoundation/tech-proposals/pull/51/c1631552317@github.com>
Message-ID: <CAJKmMz-Y42a1=Ro7CrpG6LBWqx=X0FppuazvHoN962RfiEnPgg@mail.gmail.com>

Dear GHC SC

CLC approves!

Simon

---------- Forwarded message ---------
From: ˌbodʲɪˈɡrʲim <notifications at github.com>
Date: Tue, 11 Jul 2023 at 22:45
Subject: Re: [haskellfoundation/tech-proposals] GHC's base libraries:
Combining stability with innovation (PR #51)
To: haskellfoundation/tech-proposals <tech-proposals at noreply.github.com>
Cc: Simon Peyton Jones <simon.peytonjones at gmail.com>, Mention <
mention at noreply.github.com>


I'm happy to announce that the proposal
<https://github.com/haskellfoundation/tech-proposals/pull/51/commits/c157f56c4f77ee1c7caaf5c1433296427971ed94>
has been approved unanimously
<https://groups.google.com/g/haskell-core-libraries/c/10SyhA9Lm98/m/Zimb2ZZUAAAJ>
by CLC.

—
Reply to this email directly, view it on GitHub
<https://github.com/haskellfoundation/tech-proposals/pull/51#issuecomment-1631552317>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAEOY62ZSZ6RZ4LTLPSKSOLXPXCQ5ANCNFSM6AAAAAAZUUZN5E>
.
You are receiving this because you were mentioned.Message ID:
<haskellfoundation/tech-proposals/pull/51/c1631552317 at github.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20230711/cdb3aa3a/attachment.html>

From chris at chrisdornan.com  Wed Jul 12 00:14:46 2023
From: chris at chrisdornan.com (Chris Dornan)
Date: Wed, 12 Jul 2023 01:14:46 +0100
Subject: [ghc-steering-committee] Fwd:
 [haskellfoundation/tech-proposals] GHC's base libraries: Combining
 stability with innovation (PR #51)
In-Reply-To: <CAJKmMz-Y42a1=Ro7CrpG6LBWqx=X0FppuazvHoN962RfiEnPgg@mail.gmail.com>
References: <haskellfoundation/tech-proposals/pull/51@github.com>
 <haskellfoundation/tech-proposals/pull/51/c1631552317@github.com>
 <CAJKmMz-Y42a1=Ro7CrpG6LBWqx=X0FppuazvHoN962RfiEnPgg@mail.gmail.com>
Message-ID: <CABSB5jXbdUvgoSVMm5nSmfrDbWPs4Wr93kPK-YAu4e-ni5057Q@mail.gmail.com>

marvellous!

On Tue, 11 Jul 2023 at 22:48, Simon Peyton Jones <
simon.peytonjones at gmail.com> wrote:

> Dear GHC SC
>
> CLC approves!
>
> Simon
>
> ---------- Forwarded message ---------
> From: ˌbodʲɪˈɡrʲim <notifications at github.com>
> Date: Tue, 11 Jul 2023 at 22:45
> Subject: Re: [haskellfoundation/tech-proposals] GHC's base libraries:
> Combining stability with innovation (PR #51)
> To: haskellfoundation/tech-proposals <tech-proposals at noreply.github.com>
> Cc: Simon Peyton Jones <simon.peytonjones at gmail.com>, Mention <
> mention at noreply.github.com>
>
>
> I'm happy to announce that the proposal
> <https://github.com/haskellfoundation/tech-proposals/pull/51/commits/c157f56c4f77ee1c7caaf5c1433296427971ed94>
> has been approved unanimously
> <https://groups.google.com/g/haskell-core-libraries/c/10SyhA9Lm98/m/Zimb2ZZUAAAJ>
> by CLC.
>
> —
> Reply to this email directly, view it on GitHub
> <https://github.com/haskellfoundation/tech-proposals/pull/51#issuecomment-1631552317>,
> or unsubscribe
> <https://github.com/notifications/unsubscribe-auth/AAEOY62ZSZ6RZ4LTLPSKSOLXPXCQ5ANCNFSM6AAAAAAZUUZN5E>
> .
> You are receiving this because you were mentioned.Message ID:
> <haskellfoundation/tech-proposals/pull/51/c1631552317 at github.com>
> _______________________________________________
> 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/20230712/0bea2837/attachment.html>

From mail at joachim-breitner.de  Sat Jul 15 16:45:23 2023
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Sat, 15 Jul 2023 18:45:23 +0200
Subject: [ghc-steering-committee] #596: sized literals in Show,
 rec: accept
In-Reply-To: <e59a833a18a04f3ce077d175272223aaf8d4e413.camel@joachim-breitner.de>
References: <0a90849c93122ead8026bf5f9414f8da91a5f3c2.camel@joachim-breitner.de>
 <e59a833a18a04f3ce077d175272223aaf8d4e413.camel@joachim-breitner.de>
Message-ID: <68a3f709a9faed04e19ea52f7b9937ba6ba5d192.camel@joachim-breitner.de>

Merged!

Am Sonntag, dem 09.07.2023 um 21:17 +0200 schrieb Joachim Breitner:
> Hi,
> 
> I only got positive feedback, so I’ll merge this in a few days.
> 
> Cheers,
> Joachim
> 
> Am Donnerstag, dem 29.06.2023 um 08:20 +0200 schrieb Joachim Breitner:
> > Dear committee,
> > 
> > Krzysztof Gogolewski in
> > https://github.com/ghc-proposals/ghc-proposals/pull/596
> > amends the sized literals proposal so that GHC uses the syntax 
> > 42#Int8 instead of (intToInt8# 42#) in the stock derived Show instances
> > for data types with sized unboxed numbers.
> > 
> > Implementation is also ready.
> > 
> > Now that we have a syntax for these literals it’s clear that we want to
> > use them in the show instances. 
> > 
> > 
> > There is no risk of breaking Show-Read-roundtripping, as Read instances
> > cannot be derived (at the moment).
> > 
> > This is a change in behavior of Show, so we should think for a moment
> > how this affects stability. But none of the libraries in libraries/, in
> > particularly not base, are affected by this change, according to
> > Krzysztof.
> > 
> > So I recommend to accept this.
> > 
> > Cheers,
> > Joachim
> > 
> > 
> > 
> 

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


From mail at joachim-breitner.de  Sat Jul 15 16:51:51 2023
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Sat, 15 Jul 2023 18:51:51 +0200
Subject: [ghc-steering-committee] Please consider GHC Proposal #581 for
 acceptance.
In-Reply-To: <7159d26b3282d2173635faa423a8b70893169122.camel@joachim-breitner.de>
References: <CAKfdd-xreE+-NQjqkPnbym4SFyba-qYbMxvE=ZUMxwbpnM+9tw@mail.gmail.com>
 <7159d26b3282d2173635faa423a8b70893169122.camel@joachim-breitner.de>
Message-ID: <1a4010bf54148d1c44f54c2c6f0592c5d03fdbb1.camel@joachim-breitner.de>

Merged.

Am Sonntag, dem 09.07.2023 um 21:18 +0200 schrieb Joachim Breitner:
> Hi,
> 
> this got lots of positive feedback. Will merge in a few days.
> 
> Cheers,
> Joachim
> 
> Am Mittwoch, dem 28.06.2023 um 07:27 +0200 schrieb Moritz Angermann:
> > Dear Steering Committee,
> > 
> > Adam, Artyom and Chris wrote the Namespace-specified imports
> > proposal. It seeks to make importing more impressive, allowing import
> > statements to choose from the type and data namespaces explicitly.
> > 
> > I believe this proposal adds value in expressiveness to import
> > statements. After the last syntax refinement comes naturally to the
> > language. I recommend acceptance of this proposal.
> > 
> > Best regards,
> >  Moritz
> > _______________________________________________
> > ghc-steering-committee mailing list
> > ghc-steering-committee at haskell.org
> > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
> 

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


From mail at joachim-breitner.de  Sun Jul 16 18:57:26 2023
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Sun, 16 Jul 2023 20:57:26 +0200
Subject: [ghc-steering-committee] #604: do not let -XScopedTypeVariables
 imply -XTypeAbstractions, rec: accept
Message-ID: <bf46bcd23c1b497592949961f96bb57d9392ae9c.camel@joachim-breitner.de>

Dear committee,

John Ericsson in
https://github.com/ghc-proposals/ghc-proposals/pull/604
proposes an amendment to #448.

I’ll shepherd this myself.

Status Quo:
  ScopedTypeVariables implies TypeAbstractions.
New behavior:
  TypeAbstractions needs to be enabled explicitly.
  (Plus, as a compat feature, ScopedTypeVariables&TypeApplications 
  enable TypeAbstractions, with a deprecation warning upon use.)


John makes a good argument that it’s odd to expand the meaning of an
existing extension like ScopedTypeVariables without need, and the
proposed way sounds good to me, so I recommend to accept this.


This is a minor change and would be good to have clarity soon. If no
discussion happens, I’ll merge in a week. I am particularly keen on
feedback from Richard (original author) and Arnaud (original shepherd),
of course.

Cheers,
Joachim




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


From arnaud.spiwack at tweag.io  Mon Jul 17 08:39:39 2023
From: arnaud.spiwack at tweag.io (Arnaud Spiwack)
Date: Mon, 17 Jul 2023 10:39:39 +0200
Subject: [ghc-steering-committee] =?utf-8?q?Language_Extension_Policy_?=
	=?utf-8?b?4oCTIFJvdW5kIDM=?=
In-Reply-To: <CAJKmMz9Xby3A2sVo0b3q8JRPA8RKzHATzPpG6VYGya_gBVwVVw@mail.gmail.com>
References: <CAGwnsnkwsp8FbQ5bj+zMrkNH6JpODNaczYVHB2GxSz+9aZMahw@mail.gmail.com>
 <e076399f7e37fc67707949ad042978eb0e13cc7b.camel@joachim-breitner.de>
 <CAGwnsnnTVKLTPPJnj0Q6=Ne-CsA07pJO+0XW=c2-sSA9KV+55g@mail.gmail.com>
 <CAJKmMz9Xby3A2sVo0b3q8JRPA8RKzHATzPpG6VYGya_gBVwVVw@mail.gmail.com>
Message-ID: <CAGwnsnnHb-qf26n4Pp8usmV4MNw4soUdjqrAF+oYJiKYyco=PQ@mail.gmail.com>

This discussion seems to be of little interest to most of us. I must
confess that I'm quite surprised: I expected a rather heated debate. To try
and get a better understanding of where everybody stands, it would help me
to have everyone post even a short comment, even half-baked, expressing
their sentiment on the issue.

Do pay attention to Joachim's idea, which is not in my original email,
whereby extensions could only be made valid under a subset of base
languages (Haskell98, Haskell2010, GHC20xx).

On Mon, 10 Jul 2023 at 16:26, Simon Peyton Jones <
simon.peytonjones at gmail.com> wrote:

> A question which can matter as part of this discussion is how much of a
>> maintenance burden is having so many extensions?
>>
>
> Generally, not much provided they are well-designed and orthogonal.  Some
> flag-testing would disappear if the feature is permanently on.  But not
> much complexity beyond that, usually.
>
> Simon
>
> On Mon, 10 Jul 2023 at 15:14, Arnaud Spiwack <arnaud.spiwack at tweag.io>
> wrote:
>
>> *@Chris:*
>> That's a long email 🙂. I think that when people complain about
>> committees, what they complain about is too many people deciding, not too
>> few. At any rate, as the GHC steering committee we are the designated
>> caretakers of GHC's flavour of Haskell. We are required to make decisions
>> on proposals, and often asked to consult on what the best course of action
>> for a proposal is. We use a set of principles as guides. Reducing the
>> number of dialects of GHC can either be a goal or a non-goal. But the only
>> alternative to choosing is not making a choice. And we'd be left in the
>> current situation, where different committee members pull in different
>> directions based on what extensions mean for them, and whether a proposal
>> is accepted in a shape or another is largely dependent on which committee
>> member had more brain cycles that week. Some of us have started this
>> process of thinking deeply about extensions because we observed that there
>> was a disconnect within the committee. And we believe that we owe the
>> community better than this.
>>
>> That being said, I'm not advocating or even proposing sweeping changes (a
>> big change in policy would require, like any, a proposal). I'm asking us to
>> dream a little together and think about what we believe would be most
>> beneficial for the language. The main outcome that I'm trying to achieve is
>> a new set of principles relating to extensions.
>>
>> *@Joachim/@Simon:*
>> I think both of you are bringing concern about backward compatibility. I
>> think there are two questions:
>> 1. Moving forward, we could advertise extensions as being temporary, and
>> if you use them, you should expect to have to rewrite part of your code in
>> the future. Is the extra work worth it?
>> 2. All the extensions in the past that we've been used to turn on on a
>> fine-grain basis represent an enormous amount of libraries. Some are
>> basically unmaintained, having been robust enough to go untouched for 10+
>> years. Rewriting this would be a tremendous effort. Is the extra work worth
>> it?
>>
>> I take your comments as saying that the answer to (2) is almost certainly
>> “no”. What's your answer to (1)? I can see an argument for saying that
>> Haskell being a research language, extensions take longer than, say, in
>> Rust, to be eventually rolled in. As such, we actually expect many to have
>> extensions turned on, and for long enough that it would become a liability
>> to erase the extension in the future.
>>
>> One difficulty is that it's rather fraught to let code with
>> `-XSomeExtension` compile while not documenting what `-XSomeExtension`
>> does. We could make it conspicuous in the manual that the extension is
>> deprecated. But would `--show-options` also contain it? We also need to
>> make sure that the deprecated extension is not autocompleted by IDEs (I
>> guess this is a setting for GHCi). I think this is started to look like the
>> Haskell Foundation's Stability Working Group's proposal mentioned above.
>>
>> *@Joachim:*
>> The idea of having extensions work only against certain languages is
>> intriguing. I think it needs some refinement: First, -XFuzzyTypes would
>> work against GHC2024 or later, until it's folded into a GHC20xx. And,
>> probably, you'll still want to be able to call `-XNoFuzzyTypes` on some of
>> the GHC20xx where it is folded (maybe just 1), at least if it causes some
>> compatibility issues (I don't think -XDerivingFunctor is of the sort), in
>> order to smooth out transition.
>>
>> Another question on this approach is: how would the user guide present
>> this information without flooding the reader with extensions that don't
>> apply to the GHC20xx they're using?
>>
>> *@all*:
>> A question which can matter as part of this discussion is how much of a
>> maintenance burden is having so many extensions? From a pure
>> implementation-of-GHC point of view. Personally, it's never really been in
>> my way (which may simply mean that I don't contribute a lot), so I'm
>> focussing, in this discussion, on the impact on Haskell programmers. But
>> the impact on GHC developers is definitely relevant.
>>
>> --
>> Arnaud Spiwack
>> Director, Research at https://moduscreate.com and https://tweag.io.
>> _______________________________________________
>> ghc-steering-committee mailing list
>> ghc-steering-committee at haskell.org
>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>>
>

-- 
Arnaud Spiwack
Director, Research at https://moduscreate.com and https://tweag.io.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20230717/acd21391/attachment.html>

From simon.peytonjones at gmail.com  Mon Jul 17 08:52:58 2023
From: simon.peytonjones at gmail.com (Simon Peyton Jones)
Date: Mon, 17 Jul 2023 09:52:58 +0100
Subject: [ghc-steering-committee] =?utf-8?q?Language_Extension_Policy_?=
	=?utf-8?b?4oCTIFJvdW5kIDM=?=
In-Reply-To: <CAGwnsnnHb-qf26n4Pp8usmV4MNw4soUdjqrAF+oYJiKYyco=PQ@mail.gmail.com>
References: <CAGwnsnkwsp8FbQ5bj+zMrkNH6JpODNaczYVHB2GxSz+9aZMahw@mail.gmail.com>
 <e076399f7e37fc67707949ad042978eb0e13cc7b.camel@joachim-breitner.de>
 <CAGwnsnnTVKLTPPJnj0Q6=Ne-CsA07pJO+0XW=c2-sSA9KV+55g@mail.gmail.com>
 <CAJKmMz9Xby3A2sVo0b3q8JRPA8RKzHATzPpG6VYGya_gBVwVVw@mail.gmail.com>
 <CAGwnsnnHb-qf26n4Pp8usmV4MNw4soUdjqrAF+oYJiKYyco=PQ@mail.gmail.com>
Message-ID: <CAJKmMz9i=ff6E23_aY+RioP6iRNLOT=PFK6iD-9EKEnUuu+7hw@mail.gmail.com>

My personal view is this.

   - I find it hard to bring energy to this meta-conversation about
   extension policy.  For me it's a funny combination of too abstract (what
   are we trying to achieve?) and too detailed (*thirteen *possible use
   cases for each extension?).
   - My general position is: let's define well-specified extensions, and
   let users choose which ones to use.
   - I'm not against grouping them into GHC20xx groups, but I don't have a
   strong view about what should be in which groups.  My instinct is to
   produce GHC20xx rather infrequently, much less than annually.
   - David's recent extension policy proposal
   <https://github.com/ghc-proposals/ghc-proposals/pull/601>makes sense to
   me.  It is simple, concrete, and actionable.

If all this is important to others I'm not against continuing the
conversation.  But if it were me I'd just focus around agreeing David's
proposal (if there is general support), and then let it be.

None of this is to criticise Arnaud and Joachim's work in herding cats.
Thank you -- it's a tricky topic!  I'm just not sure that it is the highest
priority problem.   But: remember that I am an out-lier.  This conversation
mostly impacts users, and I am unrepresentative of that constituency.

Simon

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

> This discussion seems to be of little interest to most of us. I must
> confess that I'm quite surprised: I expected a rather heated debate. To try
> and get a better understanding of where everybody stands, it would help me
> to have everyone post even a short comment, even half-baked, expressing
> their sentiment on the issue.
>
> Do pay attention to Joachim's idea, which is not in my original email,
> whereby extensions could only be made valid under a subset of base
> languages (Haskell98, Haskell2010, GHC20xx).
>
> On Mon, 10 Jul 2023 at 16:26, Simon Peyton Jones <
> simon.peytonjones at gmail.com> wrote:
>
>> A question which can matter as part of this discussion is how much of a
>>> maintenance burden is having so many extensions?
>>>
>>
>> Generally, not much provided they are well-designed and orthogonal.  Some
>> flag-testing would disappear if the feature is permanently on.  But not
>> much complexity beyond that, usually.
>>
>> Simon
>>
>> On Mon, 10 Jul 2023 at 15:14, Arnaud Spiwack <arnaud.spiwack at tweag.io>
>> wrote:
>>
>>> *@Chris:*
>>> That's a long email 🙂. I think that when people complain about
>>> committees, what they complain about is too many people deciding, not too
>>> few. At any rate, as the GHC steering committee we are the designated
>>> caretakers of GHC's flavour of Haskell. We are required to make decisions
>>> on proposals, and often asked to consult on what the best course of action
>>> for a proposal is. We use a set of principles as guides. Reducing the
>>> number of dialects of GHC can either be a goal or a non-goal. But the only
>>> alternative to choosing is not making a choice. And we'd be left in the
>>> current situation, where different committee members pull in different
>>> directions based on what extensions mean for them, and whether a proposal
>>> is accepted in a shape or another is largely dependent on which committee
>>> member had more brain cycles that week. Some of us have started this
>>> process of thinking deeply about extensions because we observed that there
>>> was a disconnect within the committee. And we believe that we owe the
>>> community better than this.
>>>
>>> That being said, I'm not advocating or even proposing sweeping changes
>>> (a big change in policy would require, like any, a proposal). I'm asking us
>>> to dream a little together and think about what we believe would be most
>>> beneficial for the language. The main outcome that I'm trying to achieve is
>>> a new set of principles relating to extensions.
>>>
>>> *@Joachim/@Simon:*
>>> I think both of you are bringing concern about backward compatibility. I
>>> think there are two questions:
>>> 1. Moving forward, we could advertise extensions as being temporary, and
>>> if you use them, you should expect to have to rewrite part of your code in
>>> the future. Is the extra work worth it?
>>> 2. All the extensions in the past that we've been used to turn on on a
>>> fine-grain basis represent an enormous amount of libraries. Some are
>>> basically unmaintained, having been robust enough to go untouched for 10+
>>> years. Rewriting this would be a tremendous effort. Is the extra work worth
>>> it?
>>>
>>> I take your comments as saying that the answer to (2) is almost
>>> certainly “no”. What's your answer to (1)? I can see an argument for saying
>>> that Haskell being a research language, extensions take longer than, say,
>>> in Rust, to be eventually rolled in. As such, we actually expect many to
>>> have extensions turned on, and for long enough that it would become a
>>> liability to erase the extension in the future.
>>>
>>> One difficulty is that it's rather fraught to let code with
>>> `-XSomeExtension` compile while not documenting what `-XSomeExtension`
>>> does. We could make it conspicuous in the manual that the extension is
>>> deprecated. But would `--show-options` also contain it? We also need to
>>> make sure that the deprecated extension is not autocompleted by IDEs (I
>>> guess this is a setting for GHCi). I think this is started to look like the
>>> Haskell Foundation's Stability Working Group's proposal mentioned above.
>>>
>>> *@Joachim:*
>>> The idea of having extensions work only against certain languages is
>>> intriguing. I think it needs some refinement: First, -XFuzzyTypes would
>>> work against GHC2024 or later, until it's folded into a GHC20xx. And,
>>> probably, you'll still want to be able to call `-XNoFuzzyTypes` on some of
>>> the GHC20xx where it is folded (maybe just 1), at least if it causes some
>>> compatibility issues (I don't think -XDerivingFunctor is of the sort), in
>>> order to smooth out transition.
>>>
>>> Another question on this approach is: how would the user guide present
>>> this information without flooding the reader with extensions that don't
>>> apply to the GHC20xx they're using?
>>>
>>> *@all*:
>>> A question which can matter as part of this discussion is how much of a
>>> maintenance burden is having so many extensions? From a pure
>>> implementation-of-GHC point of view. Personally, it's never really been in
>>> my way (which may simply mean that I don't contribute a lot), so I'm
>>> focussing, in this discussion, on the impact on Haskell programmers. But
>>> the impact on GHC developers is definitely relevant.
>>>
>>> --
>>> Arnaud Spiwack
>>> Director, Research at https://moduscreate.com and https://tweag.io.
>>> _______________________________________________
>>> ghc-steering-committee mailing list
>>> ghc-steering-committee at haskell.org
>>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>>>
>>
>
> --
> Arnaud Spiwack
> Director, Research at https://moduscreate.com and https://tweag.io.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20230717/00d1808b/attachment-0001.html>

From simon.peytonjones at gmail.com  Mon Jul 17 09:58:25 2023
From: simon.peytonjones at gmail.com (Simon Peyton Jones)
Date: Mon, 17 Jul 2023 10:58:25 +0100
Subject: [ghc-steering-committee] #604: do not let -XScopedTypeVariables
 imply -XTypeAbstractions, rec: accept
In-Reply-To: <bf46bcd23c1b497592949961f96bb57d9392ae9c.camel@joachim-breitner.de>
References: <bf46bcd23c1b497592949961f96bb57d9392ae9c.camel@joachim-breitner.de>
Message-ID: <CAJKmMz9vu_ewUodLnj8xdop3m=sgpFK4d+cCrJ9S366ez2yBQw@mail.gmail.com>

I have made some clarifying suggestions but I'm broadly supportive.

Simon

On Sun, 16 Jul 2023 at 19:57, Joachim Breitner <mail at joachim-breitner.de>
wrote:

> Dear committee,
>
> John Ericsson in
> https://github.com/ghc-proposals/ghc-proposals/pull/604
> proposes an amendment to #448.
>
> I’ll shepherd this myself.
>
> Status Quo:
>   ScopedTypeVariables implies TypeAbstractions.
> New behavior:
>   TypeAbstractions needs to be enabled explicitly.
>   (Plus, as a compat feature, ScopedTypeVariables&TypeApplications
>   enable TypeAbstractions, with a deprecation warning upon use.)
>
>
> John makes a good argument that it’s odd to expand the meaning of an
> existing extension like ScopedTypeVariables without need, and the
> proposed way sounds good to me, so I recommend to accept this.
>
>
> This is a minor change and would be good to have clarity soon. If no
> discussion happens, I’ll merge in a week. I am particularly keen on
> feedback from Richard (original author) and Arnaud (original shepherd),
> of course.
>
> 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/20230717/b475467d/attachment.html>

From simon.peytonjones at gmail.com  Mon Jul 17 10:11:54 2023
From: simon.peytonjones at gmail.com (Simon Peyton Jones)
Date: Mon, 17 Jul 2023 11:11:54 +0100
Subject: [ghc-steering-committee] Base library organisation
In-Reply-To: <CAJKmMz_YHSQFERR1rRuofOtnOEbsE11Q4orKwWh8VdXj2wyShQ@mail.gmail.com>
References: <CAJKmMz-VCBsWarL-uDhS=vfNPOKecdnHfbxPTmwM9zP1cKYW1Q@mail.gmail.com>
 <CAJKmMz_YHSQFERR1rRuofOtnOEbsE11Q4orKwWh8VdXj2wyShQ@mail.gmail.com>
Message-ID: <CAJKmMz-GhdZkQTF4fsUBCJA4Joije8Y6YhMnCGUTy9GoQKKVCA@mail.gmail.com>

Dear GHC steering committee

I didn't get any further feedback, so I declare the support of the GHC
steering committee for the base-library plan
<https://github.com/Ericson2314/tech-proposals/blob/ghc-base-libraries/proposals/accepted/051-ghc-base-libraries.rst>
.

The CLC and HF technical working group both voted in favour, so it has now
been merged in the HF TWG repository.

Onward and upward!

Simon




On Mon, 10 Jul 2023 at 23:05, Simon Peyton Jones <
simon.peytonjones at gmail.com> wrote:

> Dear Ghc-Steering-Committee
>
> Any further views about the base-library plan
> <https://github.com/Ericson2314/tech-proposals/blob/ghc-base-libraries/proposals/accepted/051-ghc-base-libraries.rst>?
>
>
> We have Torsten's helpful patch
> <https://github.com/ghc-proposals/ghc-proposals/pull/602>to our GHC
> Proposal template.  Any views about that?
>
> RSVP.  If you want to see any changes, can you offer concrete text that
> you'd prefer to see?
>
> I'd like to indicate our assent as a committee -- but only if we are all
> happy!  CLC is voting in favour -- I expect a result in a day or two.
>
> RSVP.  I'll take silence as assent by say Thursday. Yell if you need more
> time.
>
> Simon
>
>
>
>
> On Thu, 15 Jun 2023 at 10:03, Simon Peyton Jones <
> simon.peytonjones at gmail.com> wrote:
>
>> Dear GHC Steering Committee
>>
>> Over the last few weeks, Ben Gamari and I have been discussing with
>> Andrew and Julian from the Core Libraries Committee how to make the Core
>> Libraries Committee and the GHC developers work together more fluidly; and
>> that includes the GHC Steering Committee.
>>
>> We now have a fairly well fleshed out proposal here.
>> <https://github.com/Ericson2314/tech-proposals/blob/ghc-base-libraries/proposals/accepted/050-ghc-base-libraries.rst>
>>
>> I hope you like it.  As far as this committee is concerned there are two
>> particular points of note
>>
>>    1. We propose a new package, *ghc-experimental*, which depends on
>>    *base*.  Many GHC proposals involve defining new types and
>>    functions.  The idea is that these would initially be in
>>    *ghc-experimental*.  After they stabilise and become widely adopted,
>>    the author (or anyone else) can make a CLC proposal to move them to
>>    *base*, which has much stronger stability guarantees.
>>    2. Section 5.1 suggests a mechanism to involve CLC members in
>>    proposals that involve new functions and types, at an earlier stage.  Some
>>    involve *changing *existing types and functions.  It is clearly
>>    unproductive for us to debate such things at length, and only *then *to
>>    land it on the CLC.
>>
>>    Section 5.1 also suggests that proposals should explicitly (in a
>>    separate section) call out
>>
>>
>>    - What new types and functions it defines
>>    - What existing types and functions are changed.
>>
>> We should add that to our template.
>>
>> At the moment we are just sharing the proposal with relevant stakeholders
>> (yourselves, CLC, stack folk, cabal folk etc), so that we can polish any
>> rough edges before making it public.
>>
>> So, any views?  Personally I think this is a Big Step Forward.
>>
>> Simon
>>
>>
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20230717/61f4e2e9/attachment.html>

From moritz.angermann at gmail.com  Mon Jul 17 10:16:01 2023
From: moritz.angermann at gmail.com (Moritz Angermann)
Date: Mon, 17 Jul 2023 12:16:01 +0200
Subject: [ghc-steering-committee] =?utf-8?q?Language_Extension_Policy_?=
	=?utf-8?b?4oCTIFJvdW5kIDM=?=
In-Reply-To: <CAJKmMz9i=ff6E23_aY+RioP6iRNLOT=PFK6iD-9EKEnUuu+7hw@mail.gmail.com>
References: <CAGwnsnkwsp8FbQ5bj+zMrkNH6JpODNaczYVHB2GxSz+9aZMahw@mail.gmail.com>
 <e076399f7e37fc67707949ad042978eb0e13cc7b.camel@joachim-breitner.de>
 <CAGwnsnnTVKLTPPJnj0Q6=Ne-CsA07pJO+0XW=c2-sSA9KV+55g@mail.gmail.com>
 <CAJKmMz9Xby3A2sVo0b3q8JRPA8RKzHATzPpG6VYGya_gBVwVVw@mail.gmail.com>
 <CAGwnsnnHb-qf26n4Pp8usmV4MNw4soUdjqrAF+oYJiKYyco=PQ@mail.gmail.com>
 <CAJKmMz9i=ff6E23_aY+RioP6iRNLOT=PFK6iD-9EKEnUuu+7hw@mail.gmail.com>
Message-ID: <CAKfdd-w_HdRb1WWf16HP+VSPudR7xYvYzhgpDftORUiXNhT-0w@mail.gmail.com>

My view is, I don’t have much of a concrete opinion on this. I *do* have a
very strong belief around backwards compatibility. I think that the
constant churn that breaking changes cause are a major detriment to Haskell
adoption. If I were in a position to make a technological decision. I’m not
sure I’d be able to choose Haskell.

I do think we have *way* too many extensions, and their interaction is hard
to understand for new developers. I also think we should put a lot of the
new developments (research compiler) behind a -DRESEARCH or -DEXPERIMENTAL
flags and have separate binary distributions for those, clearly marked as
such.

But all this is orthogonal to this.

Reducing the amount of language extension complexities, by building
groupings seems sensible. Having this come along with the compiler
suggesting upgrading to language groups (GHC20XX) to reduce a lot of
extension noise in files and better understood extensions interaction
(ideally with the compiler providing the relevant patches or auto
migration), would be something I consider sensible.

Removing extensions that lead to existing, but then broken code is
something I’m *highly* opposed to. With lengthily deprecation cycles and
some monitoring across the ecosystem this might be doable. I will however
oppose none or short deprecation cycles.

Ultimately for the specific choice which extensions are grouped, and how,
I’m not the right person to ask.

On Mon, 17 Jul 2023 at 10:53 AM, Simon Peyton Jones <
simon.peytonjones at gmail.com> wrote:

> My personal view is this.
>
>    - I find it hard to bring energy to this meta-conversation about
>    extension policy.  For me it's a funny combination of too abstract (what
>    are we trying to achieve?) and too detailed (*thirteen *possible use
>    cases for each extension?).
>    - My general position is: let's define well-specified extensions, and
>    let users choose which ones to use.
>    - I'm not against grouping them into GHC20xx groups, but I don't have
>    a strong view about what should be in which groups.  My instinct is to
>    produce GHC20xx rather infrequently, much less than annually.
>    - David's recent extension policy proposal
>    <https://github.com/ghc-proposals/ghc-proposals/pull/601>makes sense
>    to me.  It is simple, concrete, and actionable.
>
> If all this is important to others I'm not against continuing the
> conversation.  But if it were me I'd just focus around agreeing David's
> proposal (if there is general support), and then let it be.
>
> None of this is to criticise Arnaud and Joachim's work in herding cats.
> Thank you -- it's a tricky topic!  I'm just not sure that it is the highest
> priority problem.   But: remember that I am an out-lier.  This conversation
> mostly impacts users, and I am unrepresentative of that constituency.
>
>
> Simon
>
> On Mon, 17 Jul 2023 at 09:40, Arnaud Spiwack <arnaud.spiwack at tweag.io>
> wrote:
>
>> This discussion seems to be of little interest to most of us. I must
>> confess that I'm quite surprised: I expected a rather heated debate. To try
>> and get a better understanding of where everybody stands, it would help me
>> to have everyone post even a short comment, even half-baked, expressing
>> their sentiment on the issue.
>>
>> Do pay attention to Joachim's idea, which is not in my original email,
>> whereby extensions could only be made valid under a subset of base
>> languages (Haskell98, Haskell2010, GHC20xx).
>>
>> On Mon, 10 Jul 2023 at 16:26, Simon Peyton Jones <
>> simon.peytonjones at gmail.com> wrote:
>>
>>> A question which can matter as part of this discussion is how much of a
>>>> maintenance burden is having so many extensions?
>>>>
>>>
>>> Generally, not much provided they are well-designed and orthogonal.
>>> Some flag-testing would disappear if the feature is permanently on.  But
>>> not much complexity beyond that, usually.
>>>
>>> Simon
>>>
>>> On Mon, 10 Jul 2023 at 15:14, Arnaud Spiwack <arnaud.spiwack at tweag.io>
>>> wrote:
>>>
>>>> *@Chris:*
>>>> That's a long email 🙂. I think that when people complain about
>>>> committees, what they complain about is too many people deciding, not too
>>>> few. At any rate, as the GHC steering committee we are the designated
>>>> caretakers of GHC's flavour of Haskell. We are required to make decisions
>>>> on proposals, and often asked to consult on what the best course of action
>>>> for a proposal is. We use a set of principles as guides. Reducing the
>>>> number of dialects of GHC can either be a goal or a non-goal. But the only
>>>> alternative to choosing is not making a choice. And we'd be left in the
>>>> current situation, where different committee members pull in different
>>>> directions based on what extensions mean for them, and whether a proposal
>>>> is accepted in a shape or another is largely dependent on which committee
>>>> member had more brain cycles that week. Some of us have started this
>>>> process of thinking deeply about extensions because we observed that there
>>>> was a disconnect within the committee. And we believe that we owe the
>>>> community better than this.
>>>>
>>>> That being said, I'm not advocating or even proposing sweeping changes
>>>> (a big change in policy would require, like any, a proposal). I'm asking us
>>>> to dream a little together and think about what we believe would be most
>>>> beneficial for the language. The main outcome that I'm trying to achieve is
>>>> a new set of principles relating to extensions.
>>>>
>>>> *@Joachim/@Simon:*
>>>> I think both of you are bringing concern about backward compatibility.
>>>> I think there are two questions:
>>>> 1. Moving forward, we could advertise extensions as being temporary,
>>>> and if you use them, you should expect to have to rewrite part of your code
>>>> in the future. Is the extra work worth it?
>>>> 2. All the extensions in the past that we've been used to turn on on a
>>>> fine-grain basis represent an enormous amount of libraries. Some are
>>>> basically unmaintained, having been robust enough to go untouched for 10+
>>>> years. Rewriting this would be a tremendous effort. Is the extra work worth
>>>> it?
>>>>
>>>> I take your comments as saying that the answer to (2) is almost
>>>> certainly “no”. What's your answer to (1)? I can see an argument for saying
>>>> that Haskell being a research language, extensions take longer than, say,
>>>> in Rust, to be eventually rolled in. As such, we actually expect many to
>>>> have extensions turned on, and for long enough that it would become a
>>>> liability to erase the extension in the future.
>>>>
>>>> One difficulty is that it's rather fraught to let code with
>>>> `-XSomeExtension` compile while not documenting what `-XSomeExtension`
>>>> does. We could make it conspicuous in the manual that the extension is
>>>> deprecated. But would `--show-options` also contain it? We also need to
>>>> make sure that the deprecated extension is not autocompleted by IDEs (I
>>>> guess this is a setting for GHCi). I think this is started to look like the
>>>> Haskell Foundation's Stability Working Group's proposal mentioned above.
>>>>
>>>> *@Joachim:*
>>>> The idea of having extensions work only against certain languages is
>>>> intriguing. I think it needs some refinement: First, -XFuzzyTypes would
>>>> work against GHC2024 or later, until it's folded into a GHC20xx. And,
>>>> probably, you'll still want to be able to call `-XNoFuzzyTypes` on some of
>>>> the GHC20xx where it is folded (maybe just 1), at least if it causes some
>>>> compatibility issues (I don't think -XDerivingFunctor is of the sort), in
>>>> order to smooth out transition.
>>>>
>>>> Another question on this approach is: how would the user guide present
>>>> this information without flooding the reader with extensions that don't
>>>> apply to the GHC20xx they're using?
>>>>
>>>> *@all*:
>>>> A question which can matter as part of this discussion is how much of a
>>>> maintenance burden is having so many extensions? From a pure
>>>> implementation-of-GHC point of view. Personally, it's never really been in
>>>> my way (which may simply mean that I don't contribute a lot), so I'm
>>>> focussing, in this discussion, on the impact on Haskell programmers. But
>>>> the impact on GHC developers is definitely relevant.
>>>>
>>>> --
>>>> Arnaud Spiwack
>>>> Director, Research at https://moduscreate.com and https://tweag.io.
>>>> _______________________________________________
>>>> ghc-steering-committee mailing list
>>>> ghc-steering-committee at haskell.org
>>>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>>>>
>>>
>>
>> --
>> Arnaud Spiwack
>> Director, Research at https://moduscreate.com and https://tweag.io.
>>
> _______________________________________________
> 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/20230717/a47034c0/attachment-0001.html>

From lists at richarde.dev  Fri Jul 21 17:48:44 2023
From: lists at richarde.dev (Richard Eisenberg)
Date: Fri, 21 Jul 2023 17:48:44 +0000
Subject: [ghc-steering-committee] =?utf-8?q?Language_Extension_Policy_?=
 =?utf-8?b?4oCTIFJvdW5kIDM=?=
In-Reply-To: <CAKfdd-w_HdRb1WWf16HP+VSPudR7xYvYzhgpDftORUiXNhT-0w@mail.gmail.com>
References: <CAGwnsnkwsp8FbQ5bj+zMrkNH6JpODNaczYVHB2GxSz+9aZMahw@mail.gmail.com>
 <e076399f7e37fc67707949ad042978eb0e13cc7b.camel@joachim-breitner.de>
 <CAGwnsnnTVKLTPPJnj0Q6=Ne-CsA07pJO+0XW=c2-sSA9KV+55g@mail.gmail.com>
 <CAJKmMz9Xby3A2sVo0b3q8JRPA8RKzHATzPpG6VYGya_gBVwVVw@mail.gmail.com>
 <CAGwnsnnHb-qf26n4Pp8usmV4MNw4soUdjqrAF+oYJiKYyco=PQ@mail.gmail.com>
 <CAJKmMz9i=ff6E23_aY+RioP6iRNLOT=PFK6iD-9EKEnUuu+7hw@mail.gmail.com>
 <CAKfdd-w_HdRb1WWf16HP+VSPudR7xYvYzhgpDftORUiXNhT-0w@mail.gmail.com>
Message-ID: <010f018979917a49-79395fc4-eab7-439c-bef8-83c1a7f0480b-000000@us-east-2.amazonses.com>

My views here:

* This whole push is like weeding an overgrown garden. Weeding is rarely the highest-priority task -- but if you never do it, the lack of care shows. I'm in support of doing *something* here.
* I think our users would benefit most from a clear delineation of the status of the various extensions. There are two challenges here: defining the categories and then doing the categorization. I believe this trek (led heroically by Arnaud) is about tackling that first challenge. David's proposal is also squarely in this space
* I'm against doing anything backward-incompatible about extensions. Extensions are generally seen as bureaucratic overhead; causing breakage because of them would be pedantry run amok. But the various ideas already proposed all sound like the could work to reduce the number of extensions while not causing backward incompatibility.

Richard


> On Jul 17, 2023, at 6:16 AM, Moritz Angermann <moritz.angermann at gmail.com> wrote:
> 
> My view is, I don’t have much of a concrete opinion on this. I *do* have a very strong belief around backwards compatibility. I think that the constant churn that breaking changes cause are a major detriment to Haskell adoption. If I were in a position to make a technological decision. I’m not sure I’d be able to choose Haskell.
> 
> I do think we have *way* too many extensions, and their interaction is hard to understand for new developers. I also think we should put a lot of the new developments (research compiler) behind a -DRESEARCH or -DEXPERIMENTAL flags and have separate binary distributions for those, clearly marked as such.
> 
> But all this is orthogonal to this.
> 
> Reducing the amount of language extension complexities, by building groupings seems sensible. Having this come along with the compiler suggesting upgrading to language groups (GHC20XX) to reduce a lot of extension noise in files and better understood extensions interaction (ideally with the compiler providing the relevant patches or auto migration), would be something I consider sensible. 
> 
> Removing extensions that lead to existing, but then broken code is something I’m *highly* opposed to. With lengthily deprecation cycles and some monitoring across the ecosystem this might be doable. I will however oppose none or short deprecation cycles.
> 
> Ultimately for the specific choice which extensions are grouped, and how, I’m not the right person to ask.
> 
> On Mon, 17 Jul 2023 at 10:53 AM, Simon Peyton Jones <simon.peytonjones at gmail.com <mailto:simon.peytonjones at gmail.com>> wrote:
> My personal view is this. 
> I find it hard to bring energy to this meta-conversation about extension policy.  For me it's a funny combination of too abstract (what are we trying to achieve?) and too detailed (thirteen possible use cases for each extension?).
> My general position is: let's define well-specified extensions, and let users choose which ones to use.
> I'm not against grouping them into GHC20xx groups, but I don't have a strong view about what should be in which groups.  My instinct is to produce GHC20xx rather infrequently, much less than annually.
> David's recent extension policy proposal  <https://github.com/ghc-proposals/ghc-proposals/pull/601>makes sense to me.  It is simple, concrete, and actionable.
> If all this is important to others I'm not against continuing the conversation.  But if it were me I'd just focus around agreeing David's proposal (if there is general support), and then let it be.
> 
> None of this is to criticise Arnaud and Joachim's work in herding cats.  Thank you -- it's a tricky topic!  I'm just not sure that it is the highest priority problem.   But: remember that I am an out-lier.  This conversation mostly impacts users, and I am unrepresentative of that constituency.
> 
> 
> Simon
> 
> On Mon, 17 Jul 2023 at 09:40, Arnaud Spiwack <arnaud.spiwack at tweag.io <mailto:arnaud.spiwack at tweag.io>> wrote:
> This discussion seems to be of little interest to most of us. I must confess that I'm quite surprised: I expected a rather heated debate. To try and get a better understanding of where everybody stands, it would help me to have everyone post even a short comment, even half-baked, expressing their sentiment on the issue.
> 
> Do pay attention to Joachim's idea, which is not in my original email, whereby extensions could only be made valid under a subset of base languages (Haskell98, Haskell2010, GHC20xx).
> 
> On Mon, 10 Jul 2023 at 16:26, Simon Peyton Jones <simon.peytonjones at gmail.com <mailto:simon.peytonjones at gmail.com>> wrote:
> A question which can matter as part of this discussion is how much of a maintenance burden is having so many extensions?
> 
> Generally, not much provided they are well-designed and orthogonal.  Some flag-testing would disappear if the feature is permanently on.  But not much complexity beyond that, usually.
> 
> Simon
> 
> On Mon, 10 Jul 2023 at 15:14, Arnaud Spiwack <arnaud.spiwack at tweag.io <mailto:arnaud.spiwack at tweag.io>> wrote:
> @Chris:
> That's a long email 🙂. I think that when people complain about committees, what they complain about is too many people deciding, not too few. At any rate, as the GHC steering committee we are the designated caretakers of GHC's flavour of Haskell. We are required to make decisions on proposals, and often asked to consult on what the best course of action for a proposal is. We use a set of principles as guides. Reducing the number of dialects of GHC can either be a goal or a non-goal. But the only alternative to choosing is not making a choice. And we'd be left in the current situation, where different committee members pull in different directions based on what extensions mean for them, and whether a proposal is accepted in a shape or another is largely dependent on which committee member had more brain cycles that week. Some of us have started this process of thinking deeply about extensions because we observed that there was a disconnect within the committee. And we believe that we owe the community better than this.
> 
> That being said, I'm not advocating or even proposing sweeping changes (a big change in policy would require, like any, a proposal). I'm asking us to dream a little together and think about what we believe would be most beneficial for the language. The main outcome that I'm trying to achieve is a new set of principles relating to extensions.
> 
> @Joachim/@Simon:
> I think both of you are bringing concern about backward compatibility. I think there are two questions:
> 1. Moving forward, we could advertise extensions as being temporary, and if you use them, you should expect to have to rewrite part of your code in the future. Is the extra work worth it?
> 2. All the extensions in the past that we've been used to turn on on a fine-grain basis represent an enormous amount of libraries. Some are basically unmaintained, having been robust enough to go untouched for 10+ years. Rewriting this would be a tremendous effort. Is the extra work worth it?
> 
> I take your comments as saying that the answer to (2) is almost certainly “no”. What's your answer to (1)? I can see an argument for saying that Haskell being a research language, extensions take longer than, say, in Rust, to be eventually rolled in. As such, we actually expect many to have extensions turned on, and for long enough that it would become a liability to erase the extension in the future.
> 
> One difficulty is that it's rather fraught to let code with `-XSomeExtension` compile while not documenting what `-XSomeExtension` does. We could make it conspicuous in the manual that the extension is deprecated. But would `--show-options` also contain it? We also need to make sure that the deprecated extension is not autocompleted by IDEs (I guess this is a setting for GHCi). I think this is started to look like the Haskell Foundation's Stability Working Group's proposal mentioned above.
> 
> @Joachim:
>  <>
> The idea of having extensions work only against certain languages is intriguing. I think it needs some refinement: First, -XFuzzyTypes would work against GHC2024 or later, until it's folded into a GHC20xx. And, probably, you'll still want to be able to call `-XNoFuzzyTypes` on some of the GHC20xx where it is folded (maybe just 1), at least if it causes some compatibility issues (I don't think -XDerivingFunctor is of the sort), in order to smooth out transition.
> 
> Another question on this approach is: how would the user guide present this information without flooding the reader with extensions that don't apply to the GHC20xx they're using?
> 
> @all:
> A question which can matter as part of this discussion is how much of a maintenance burden is having so many extensions? From a pure implementation-of-GHC point of view. Personally, it's never really been in my way (which may simply mean that I don't contribute a lot), so I'm focussing, in this discussion, on the impact on Haskell programmers. But the impact on GHC developers is definitely relevant.
> 
> -- 
> Arnaud Spiwack
> Director, Research at https://moduscreate.com <https://moduscreate.com/> and https://tweag.io <https://tweag.io/>.
> _______________________________________________
> 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 <https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee>
> 
> 
> -- 
> Arnaud Spiwack
> Director, Research at https://moduscreate.com <https://moduscreate.com/> and https://tweag.io <https://tweag.io/>.
> _______________________________________________
> 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 <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/20230721/08e3d4df/attachment-0001.html>

From mail at joachim-breitner.de  Mon Jul 24 13:35:38 2023
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Mon, 24 Jul 2023 15:35:38 +0200
Subject: [ghc-steering-committee] #604: do not let -XScopedTypeVariables
 imply -XTypeAbstractions, rec: accept
In-Reply-To: <CAJKmMz9vu_ewUodLnj8xdop3m=sgpFK4d+cCrJ9S366ez2yBQw@mail.gmail.com>
References: <bf46bcd23c1b497592949961f96bb57d9392ae9c.camel@joachim-breitner.de>
 <CAJKmMz9vu_ewUodLnj8xdop3m=sgpFK4d+cCrJ9S366ez2yBQw@mail.gmail.com>
Message-ID: <b3445472b97c109d3cb1f3291a61909ae166dc7c.camel@joachim-breitner.de>

Hi,

Am Montag, dem 17.07.2023 um 10:58 +0100 schrieb Simon Peyton Jones:
> I have made some clarifying suggestions but I'm broadly supportive.

so far only Simon and Arnaud have commented.

Arnaud: could John address your remarks?

Simon: John responded to your clarifying suggestions with “suggested
edits” in the PR comments, and seems to be waiting for a 👍 from you.


I plan to merge once Arnaud and Simon indicate that they are happy.

Cheers,
Joachim


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


From mail at joachim-breitner.de  Mon Jul 24 13:39:09 2023
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Mon, 24 Jul 2023 15:39:09 +0200
Subject: [ghc-steering-committee] Please review #601: Extension lifecycle,
	Shepherd: Simon PJ
Message-ID: <1357869695964d4f88703711ca1efbe9e611d252.camel@joachim-breitner.de>

Dear Committee,

David Thrane Christiansen suggested to categorize extensions into
Experimental, Mature, Deprecated and Legacy, and add warning flag to
GHC that allow users to be warned about (or shouted at for) using such
extensions, if they choose so.

https://github.com/ghc-proposals/ghc-proposals/pull/601
https://github.com/david-christiansen/ghc-proposals/blob/extension-lifecycle-proposal/proposals/0000-extension-lifecycle-framework.md

Because of the meta-like aspect of this proposal, I’d like to assign
this to Simon PJ.


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 mail at joachim-breitner.de  Tue Jul 25 13:11:54 2023
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Tue, 25 Jul 2023 15:11:54 +0200
Subject: [ghc-steering-committee] Please review #597: Constraints synonyms
 in deriving heads, Shepherd: Moritz
Message-ID: <079f5406d3ca4a47c6c9c3dd3c39aae657055b7d.camel@joachim-breitner.de>

Dear Committee,

Grigorii Gerasev suggests to allow constraints type synonyms in deriving heads again.

https://github.com/ghc-proposals/ghc-proposals/pull/597
https://github.com/uhbif19/ghc-proposals/blob/uhbif19/allow-constraint-type-synonyms-in-deriving-heads/proposals/0000-allow-constraint-type-synonyms-in-deriving-heads.md

I’d like to assign this to Moritz (mostly because most of the committee
already sits on a proposal… gentle nudge).

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 simon.peytonjones at gmail.com  Tue Jul 25 14:58:53 2023
From: simon.peytonjones at gmail.com (Simon Peyton Jones)
Date: Tue, 25 Jul 2023 15:58:53 +0100
Subject: [ghc-steering-committee] Please review #601: Extension
 lifecycle, Shepherd: Simon PJ
In-Reply-To: <1357869695964d4f88703711ca1efbe9e611d252.camel@joachim-breitner.de>
References: <1357869695964d4f88703711ca1efbe9e611d252.camel@joachim-breitner.de>
Message-ID: <CAJKmMz9R0pbuZxFeNdWb+v4bF7vgoUF8AKZcVQ6DPNTat+hc+A@mail.gmail.com>

Dear GHC Steering Committee

Proposal #601
<https://github.com/david-christiansen/ghc-proposals/blob/extension-lifecycle-proposal/proposals/0000-extension-lifecycle-framework.md>
says

We propose a categorization scheme for Haskell language extensions. This
scheme is simple, in that there are few categories that are described in
terms of the user-relevant aspects, and it is actionable, in that it
suggests concrete changes to the warning system of GHC that allow users to
express their own risk tolerance and get guidance as they upgrade their
compiler

I'm happy with this proposal: it seems simple, comprehensible, and
actionable.

The only question in my mind is whether it is worth the bother.  I'd love
to hear from the practitioners on the committee.

But I propose that we accept it.

Simon


On Mon, 24 Jul 2023 at 14:39, Joachim Breitner <mail at joachim-breitner.de>
wrote:

> Dear Committee,
>
> David Thrane Christiansen suggested to categorize extensions into
> Experimental, Mature, Deprecated and Legacy, and add warning flag to
> GHC that allow users to be warned about (or shouted at for) using such
> extensions, if they choose so.
>
> https://github.com/ghc-proposals/ghc-proposals/pull/601
>
> https://github.com/david-christiansen/ghc-proposals/blob/extension-lifecycle-proposal/proposals/0000-extension-lifecycle-framework.md
>
> Because of the meta-like aspect of this proposal, I’d like to assign
> this to Simon PJ.
>
>
> 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/20230725/6b824904/attachment.html>

From simon.peytonjones at gmail.com  Tue Jul 25 21:47:34 2023
From: simon.peytonjones at gmail.com (Simon Peyton Jones)
Date: Tue, 25 Jul 2023 22:47:34 +0100
Subject: [ghc-steering-committee] #604: do not let -XScopedTypeVariables
 imply -XTypeAbstractions, rec: accept
In-Reply-To: <b3445472b97c109d3cb1f3291a61909ae166dc7c.camel@joachim-breitner.de>
References: <bf46bcd23c1b497592949961f96bb57d9392ae9c.camel@joachim-breitner.de>
 <CAJKmMz9vu_ewUodLnj8xdop3m=sgpFK4d+cCrJ9S366ez2yBQw@mail.gmail.com>
 <b3445472b97c109d3cb1f3291a61909ae166dc7c.camel@joachim-breitner.de>
Message-ID: <CAJKmMz9LFKpC_oxzpRcUJwTGVf-yrfG2Guqd=H3rhPqjACFUow@mail.gmail.com>

I have suggested a few more wording improvements.

Simon

On Mon, 24 Jul 2023 at 14:35, Joachim Breitner <mail at joachim-breitner.de>
wrote:

> Hi,
>
> Am Montag, dem 17.07.2023 um 10:58 +0100 schrieb Simon Peyton Jones:
> > I have made some clarifying suggestions but I'm broadly supportive.
>
> so far only Simon and Arnaud have commented.
>
> Arnaud: could John address your remarks?
>
> Simon: John responded to your clarifying suggestions with “suggested
> edits” in the PR comments, and seems to be waiting for a 👍 from you.
>
>
> I plan to merge once Arnaud and Simon indicate that they are happy.
>
> 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/20230725/fb1a9a29/attachment.html>

From mail at joachim-breitner.de  Wed Jul 26 19:08:48 2023
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Wed, 26 Jul 2023 21:08:48 +0200
Subject: [ghc-steering-committee] Feedback on GHC2021 on Discourse
Message-ID: <d93ec61a2ee16afe75d9b0760b67e4eba0566eff.camel@joachim-breitner.de>

Hi,

for those who are not following discourse, someone kicked up a thread
asking for opinions on GHC2021:
https://discourse.haskell.org/t/anybody-using-ghc2021/7095?u=nomeata

It’s mostly very positive and encouraging (and I hope helps us overcome
the anxiety about this and define an even better GHC2024).

Cheers,
Joachim

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


From arnaud.spiwack at tweag.io  Mon Jul 31 08:21:13 2023
From: arnaud.spiwack at tweag.io (Arnaud Spiwack)
Date: Mon, 31 Jul 2023 10:21:13 +0200
Subject: [ghc-steering-committee] #604: do not let -XScopedTypeVariables
 imply -XTypeAbstractions, rec: accept
In-Reply-To: <CAJKmMz9LFKpC_oxzpRcUJwTGVf-yrfG2Guqd=H3rhPqjACFUow@mail.gmail.com>
References: <bf46bcd23c1b497592949961f96bb57d9392ae9c.camel@joachim-breitner.de>
 <CAJKmMz9vu_ewUodLnj8xdop3m=sgpFK4d+cCrJ9S366ez2yBQw@mail.gmail.com>
 <b3445472b97c109d3cb1f3291a61909ae166dc7c.camel@joachim-breitner.de>
 <CAJKmMz9LFKpC_oxzpRcUJwTGVf-yrfG2Guqd=H3rhPqjACFUow@mail.gmail.com>
Message-ID: <CAGwnsn=9o2NwvptfwU2ds8ee3Fjz1A1mUZ4fKwuNAiCjSj_LdA@mail.gmail.com>

As I've said on the Github thread, now that I understand what the proposal
is proposing, I support acceptance. I agree that it's a better path than
what had been previously proposed.

On Tue, 25 Jul 2023 at 23:47, Simon Peyton Jones <
simon.peytonjones at gmail.com> wrote:

> I have suggested a few more wording improvements.
>
> Simon
>
> On Mon, 24 Jul 2023 at 14:35, Joachim Breitner <mail at joachim-breitner.de>
> wrote:
>
>> Hi,
>>
>> Am Montag, dem 17.07.2023 um 10:58 +0100 schrieb Simon Peyton Jones:
>> > I have made some clarifying suggestions but I'm broadly supportive.
>>
>> so far only Simon and Arnaud have commented.
>>
>> Arnaud: could John address your remarks?
>>
>> Simon: John responded to your clarifying suggestions with “suggested
>> edits” in the PR comments, and seems to be waiting for a 👍 from you.
>>
>>
>> I plan to merge once Arnaud and Simon indicate that they are happy.
>>
>> 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
>>
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>


-- 
Arnaud Spiwack
Director, Research at https://moduscreate.com and https://tweag.io.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20230731/0a44742c/attachment.html>

From arnaud.spiwack at tweag.io  Mon Jul 31 08:36:51 2023
From: arnaud.spiwack at tweag.io (Arnaud Spiwack)
Date: Mon, 31 Jul 2023 10:36:51 +0200
Subject: [ghc-steering-committee] Feedback on GHC2021 on Discourse
In-Reply-To: <d93ec61a2ee16afe75d9b0760b67e4eba0566eff.camel@joachim-breitner.de>
References: <d93ec61a2ee16afe75d9b0760b67e4eba0566eff.camel@joachim-breitner.de>
Message-ID: <CAGwnsnnGc0TB6Xt43EG5JfyM7KCqhAkpH8BaTwer3Z04njfuNw@mail.gmail.com>

I don't think there ever was anxiety about this :-) . I believe that the
broad feeling was that it was too early to do a new iteration. I too am
looking forward to GHC2024.

On Wed, 26 Jul 2023 at 21:08, Joachim Breitner <mail at joachim-breitner.de>
wrote:

> Hi,
>
> for those who are not following discourse, someone kicked up a thread
> asking for opinions on GHC2021:
> https://discourse.haskell.org/t/anybody-using-ghc2021/7095?u=nomeata
>
> It’s mostly very positive and encouraging (and I hope helps us overcome
> the anxiety about this and define an even better GHC2024).
>
> 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
>


-- 
Arnaud Spiwack
Director, Research at https://moduscreate.com and https://tweag.io.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20230731/54256bb4/attachment.html>

From arnaud.spiwack at tweag.io  Mon Jul 31 08:41:34 2023
From: arnaud.spiwack at tweag.io (Arnaud Spiwack)
Date: Mon, 31 Jul 2023 10:41:34 +0200
Subject: [ghc-steering-committee] =?utf-8?q?Language_Extension_Policy_?=
	=?utf-8?b?4oCTIFJvdW5kIDM=?=
In-Reply-To: <010f018979917a49-79395fc4-eab7-439c-bef8-83c1a7f0480b-000000@us-east-2.amazonses.com>
References: <CAGwnsnkwsp8FbQ5bj+zMrkNH6JpODNaczYVHB2GxSz+9aZMahw@mail.gmail.com>
 <e076399f7e37fc67707949ad042978eb0e13cc7b.camel@joachim-breitner.de>
 <CAGwnsnnTVKLTPPJnj0Q6=Ne-CsA07pJO+0XW=c2-sSA9KV+55g@mail.gmail.com>
 <CAJKmMz9Xby3A2sVo0b3q8JRPA8RKzHATzPpG6VYGya_gBVwVVw@mail.gmail.com>
 <CAGwnsnnHb-qf26n4Pp8usmV4MNw4soUdjqrAF+oYJiKYyco=PQ@mail.gmail.com>
 <CAJKmMz9i=ff6E23_aY+RioP6iRNLOT=PFK6iD-9EKEnUuu+7hw@mail.gmail.com>
 <CAKfdd-w_HdRb1WWf16HP+VSPudR7xYvYzhgpDftORUiXNhT-0w@mail.gmail.com>
 <010f018979917a49-79395fc4-eab7-439c-bef8-83c1a7f0480b-000000@us-east-2.amazonses.com>
Message-ID: <CAGwnsnkVp3zSxi7OvKJ80Qn=xXrciXaXt5LVR-Tb1Nx6scJgVA@mail.gmail.com>

I think we've gathered as much data as we can here. Eventually, we'll
probably want to use this thread to come up with a GHC proposal along the
lines of what Joachim came up with (extensions only apply to certain
languages), as it seems like it may be very desirable and there's a clear
consensus that retiring extensions altogether is undesirable.

I'm not sure yet what our next round of discussion will be about. I'll be
on holiday next week and the week after, so I'd like to start something
before then (but I'm making no promises: I need to collect my thoughts).

On Fri, 21 Jul 2023 at 19:49, Richard Eisenberg <lists at richarde.dev> wrote:

> My views here:
>
> * This whole push is like weeding an overgrown garden. Weeding is rarely
> the highest-priority task -- but if you never do it, the lack of care
> shows. I'm in support of doing *something* here.
> * I think our users would benefit most from a clear delineation of the
> status of the various extensions. There are two challenges here: defining
> the categories and then doing the categorization. I believe this trek (led
> heroically by Arnaud) is about tackling that first challenge. David's
> proposal is also squarely in this space
> * I'm against doing anything backward-incompatible about extensions.
> Extensions are generally seen as bureaucratic overhead; causing breakage
> because of them would be pedantry run amok. But the various ideas already
> proposed all sound like the could work to reduce the number of extensions
> while not causing backward incompatibility.
>
> Richard
>
>
> On Jul 17, 2023, at 6:16 AM, Moritz Angermann <moritz.angermann at gmail.com>
> wrote:
>
> My view is, I don’t have much of a concrete opinion on this. I *do* have a
> very strong belief around backwards compatibility. I think that the
> constant churn that breaking changes cause are a major detriment to Haskell
> adoption. If I were in a position to make a technological decision. I’m not
> sure I’d be able to choose Haskell.
>
> I do think we have *way* too many extensions, and their interaction is
> hard to understand for new developers. I also think we should put a lot of
> the new developments (research compiler) behind a -DRESEARCH or
> -DEXPERIMENTAL flags and have separate binary distributions for those,
> clearly marked as such.
>
> But all this is orthogonal to this.
>
> Reducing the amount of language extension complexities, by building
> groupings seems sensible. Having this come along with the compiler
> suggesting upgrading to language groups (GHC20XX) to reduce a lot of
> extension noise in files and better understood extensions interaction
> (ideally with the compiler providing the relevant patches or auto
> migration), would be something I consider sensible.
>
> Removing extensions that lead to existing, but then broken code is
> something I’m *highly* opposed to. With lengthily deprecation cycles and
> some monitoring across the ecosystem this might be doable. I will however
> oppose none or short deprecation cycles.
>
> Ultimately for the specific choice which extensions are grouped, and how,
> I’m not the right person to ask.
>
> On Mon, 17 Jul 2023 at 10:53 AM, Simon Peyton Jones <
> simon.peytonjones at gmail.com> wrote:
>
>> My personal view is this.
>>
>>    - I find it hard to bring energy to this meta-conversation about
>>    extension policy.  For me it's a funny combination of too abstract (what
>>    are we trying to achieve?) and too detailed (*thirteen *possible use
>>    cases for each extension?).
>>    - My general position is: let's define well-specified extensions, and
>>    let users choose which ones to use.
>>    - I'm not against grouping them into GHC20xx groups, but I don't have
>>    a strong view about what should be in which groups.  My instinct is to
>>    produce GHC20xx rather infrequently, much less than annually.
>>    - David's recent extension policy proposal
>>    <https://github.com/ghc-proposals/ghc-proposals/pull/601>makes sense
>>    to me.  It is simple, concrete, and actionable.
>>
>> If all this is important to others I'm not against continuing the
>> conversation.  But if it were me I'd just focus around agreeing David's
>> proposal (if there is general support), and then let it be.
>>
>> None of this is to criticise Arnaud and Joachim's work in herding cats.
>> Thank you -- it's a tricky topic!  I'm just not sure that it is the highest
>> priority problem.   But: remember that I am an out-lier.  This conversation
>> mostly impacts users, and I am unrepresentative of that constituency.
>>
>>
>> Simon
>>
>> On Mon, 17 Jul 2023 at 09:40, Arnaud Spiwack <arnaud.spiwack at tweag.io>
>> wrote:
>>
>>> This discussion seems to be of little interest to most of us. I must
>>> confess that I'm quite surprised: I expected a rather heated debate. To try
>>> and get a better understanding of where everybody stands, it would help me
>>> to have everyone post even a short comment, even half-baked, expressing
>>> their sentiment on the issue.
>>>
>>> Do pay attention to Joachim's idea, which is not in my original email,
>>> whereby extensions could only be made valid under a subset of base
>>> languages (Haskell98, Haskell2010, GHC20xx).
>>>
>>> On Mon, 10 Jul 2023 at 16:26, Simon Peyton Jones <
>>> simon.peytonjones at gmail.com> wrote:
>>>
>>>> A question which can matter as part of this discussion is how much of a
>>>>> maintenance burden is having so many extensions?
>>>>>
>>>>
>>>> Generally, not much provided they are well-designed and orthogonal.
>>>> Some flag-testing would disappear if the feature is permanently on.  But
>>>> not much complexity beyond that, usually.
>>>>
>>>> Simon
>>>>
>>>> On Mon, 10 Jul 2023 at 15:14, Arnaud Spiwack <arnaud.spiwack at tweag.io>
>>>> wrote:
>>>>
>>>>> *@Chris:*
>>>>> That's a long email 🙂. I think that when people complain about
>>>>> committees, what they complain about is too many people deciding, not too
>>>>> few. At any rate, as the GHC steering committee we are the designated
>>>>> caretakers of GHC's flavour of Haskell. We are required to make decisions
>>>>> on proposals, and often asked to consult on what the best course of action
>>>>> for a proposal is. We use a set of principles as guides. Reducing the
>>>>> number of dialects of GHC can either be a goal or a non-goal. But the only
>>>>> alternative to choosing is not making a choice. And we'd be left in the
>>>>> current situation, where different committee members pull in different
>>>>> directions based on what extensions mean for them, and whether a proposal
>>>>> is accepted in a shape or another is largely dependent on which committee
>>>>> member had more brain cycles that week. Some of us have started this
>>>>> process of thinking deeply about extensions because we observed that there
>>>>> was a disconnect within the committee. And we believe that we owe the
>>>>> community better than this.
>>>>>
>>>>> That being said, I'm not advocating or even proposing sweeping changes
>>>>> (a big change in policy would require, like any, a proposal). I'm asking us
>>>>> to dream a little together and think about what we believe would be most
>>>>> beneficial for the language. The main outcome that I'm trying to achieve is
>>>>> a new set of principles relating to extensions.
>>>>>
>>>>> *@Joachim/@Simon:*
>>>>> I think both of you are bringing concern about backward compatibility.
>>>>> I think there are two questions:
>>>>> 1. Moving forward, we could advertise extensions as being temporary,
>>>>> and if you use them, you should expect to have to rewrite part of your code
>>>>> in the future. Is the extra work worth it?
>>>>> 2. All the extensions in the past that we've been used to turn on on a
>>>>> fine-grain basis represent an enormous amount of libraries. Some are
>>>>> basically unmaintained, having been robust enough to go untouched for 10+
>>>>> years. Rewriting this would be a tremendous effort. Is the extra work worth
>>>>> it?
>>>>>
>>>>> I take your comments as saying that the answer to (2) is almost
>>>>> certainly “no”. What's your answer to (1)? I can see an argument for saying
>>>>> that Haskell being a research language, extensions take longer than, say,
>>>>> in Rust, to be eventually rolled in. As such, we actually expect many to
>>>>> have extensions turned on, and for long enough that it would become a
>>>>> liability to erase the extension in the future.
>>>>>
>>>>> One difficulty is that it's rather fraught to let code with
>>>>> `-XSomeExtension` compile while not documenting what `-XSomeExtension`
>>>>> does. We could make it conspicuous in the manual that the extension is
>>>>> deprecated. But would `--show-options` also contain it? We also need to
>>>>> make sure that the deprecated extension is not autocompleted by IDEs (I
>>>>> guess this is a setting for GHCi). I think this is started to look like the
>>>>> Haskell Foundation's Stability Working Group's proposal mentioned above.
>>>>>
>>>>> *@Joachim:*
>>>>> The idea of having extensions work only against certain languages is
>>>>> intriguing. I think it needs some refinement: First, -XFuzzyTypes would
>>>>> work against GHC2024 or later, until it's folded into a GHC20xx. And,
>>>>> probably, you'll still want to be able to call `-XNoFuzzyTypes` on some of
>>>>> the GHC20xx where it is folded (maybe just 1), at least if it causes some
>>>>> compatibility issues (I don't think -XDerivingFunctor is of the sort), in
>>>>> order to smooth out transition.
>>>>>
>>>>> Another question on this approach is: how would the user guide present
>>>>> this information without flooding the reader with extensions that don't
>>>>> apply to the GHC20xx they're using?
>>>>>
>>>>> *@all*:
>>>>> A question which can matter as part of this discussion is how much of
>>>>> a maintenance burden is having so many extensions? From a pure
>>>>> implementation-of-GHC point of view. Personally, it's never really been in
>>>>> my way (which may simply mean that I don't contribute a lot), so I'm
>>>>> focussing, in this discussion, on the impact on Haskell programmers. But
>>>>> the impact on GHC developers is definitely relevant.
>>>>>
>>>>> --
>>>>> Arnaud Spiwack
>>>>> Director, Research at https://moduscreate.com and https://tweag.io.
>>>>> _______________________________________________
>>>>> ghc-steering-committee mailing list
>>>>> ghc-steering-committee at haskell.org
>>>>>
>>>>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>>>>>
>>>>
>>>
>>> --
>>> Arnaud Spiwack
>>> Director, Research at https://moduscreate.com and https://tweag.io.
>>>
>> _______________________________________________
>> 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
>
>
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>


-- 
Arnaud Spiwack
Director, Research at https://moduscreate.com and https://tweag.io.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20230731/2f1c95d4/attachment-0001.html>