From adam at well-typed.com  Tue Aug  1 07:16:39 2023
From: adam at well-typed.com (Adam Gundry)
Date: Tue, 1 Aug 2023 08:16:39 +0100
Subject: [ghc-steering-committee] =?utf-8?q?Language_Extension_Policy_?=
 =?utf-8?b?4oCTIFJvdW5kIDM=?=
In-Reply-To: <CAGwnsnkVp3zSxi7OvKJ80Qn=xXrciXaXt5LVR-Tb1Nx6scJgVA@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>
 <010f018979917a49-79395fc4-eab7-439c-bef8-83c1a7f0480b-000000@us-east-2.amazonses.com>
 <CAGwnsnkVp3zSxi7OvKJ80Qn=xXrciXaXt5LVR-Tb1Nx6scJgVA@mail.gmail.com>
Message-ID: <1d123540-8d0e-0574-7ee1-f66882d04c65@well-typed.com>

Apologies for the delay in responding, I've been away and am generally 
busy thanks to school holidays!

I haven't been through this thread in detail, but to set out my overall 
position:

  * Clearly categorising extensions by stability (along the lines of 
#601) seems like an obvious win.

  * I think it would be a good idea for someone to rewrite the user's 
guide so that it represents the latest GHC20xx as the base language 
(e.g. so BangPatterns are documented as a feature of the language, with 
a brief mention that -XNoBangPatterns exists). We could rename chapter 6 
"Language extensions" to be "The language GHC supports". I suspect it's 
probably better to keep it organised by topic rather than bifurcating it 
into GHC20xx vs non-GHC20xx features, not least because in some cases it 
may need to document the fact that the extension's status changed over time.

  * Error message recommendations can surely be improved to be more 
sensible (not telling users to enable certain extensions).

  * I'm sceptical that reducing choice (e.g. GHC2024 mandating certain 
extensions but prohibiting others, or making it impossible to disable 
certain extensions) is really valuable. We can certainly forbid actually 
problematic interactions (by making it an error to enable two features 
that don't make sense together). But I'm unconvinced that we get any 
real conceptual or implementation benefit from a general prohibition.

Cheers,

Adam


On 31/07/2023 09:41, Arnaud Spiwack wrote:
> 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 
> <mailto: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 <mailto: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. 2^n - 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
>>     <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
>     <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
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee


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

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

From mail at joachim-breitner.de  Wed Aug  2 20:48:48 2023
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Wed, 02 Aug 2023 22:48:48 +0200
Subject: [ghc-steering-committee] #604: do not let -XScopedTypeVariables
 imply -XTypeAbstractions, rec: accept
In-Reply-To: <CAGwnsn=9o2NwvptfwU2ds8ee3Fjz1A1mUZ4fKwuNAiCjSj_LdA@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>
 <CAGwnsn=9o2NwvptfwU2ds8ee3Fjz1A1mUZ4fKwuNAiCjSj_LdA@mail.gmail.com>
Message-ID: <425799b60dc2ae65769d5f401ac93d423e8e3a32.camel@joachim-breitner.de>

Hi,

merged!

Cheers and thanks,
Joachim

Am Montag, dem 31.07.2023 um 10:21 +0200 schrieb Arnaud Spiwack:
> 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
> > > 
> > > 
> > > _______________________________________________
> > > 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  Wed Aug  9 20:24:16 2023
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Wed, 09 Aug 2023 22:24:16 +0200
Subject: [ghc-steering-committee] Away from a keyboard for a week
Message-ID: <9e19920d3c6acd6983cbca79307010bf212ee919.camel@joachim-breitner.de>

So either don’t expect swift secretarial responses, or act secretarial
in my absence.

Cheers,
Joachim

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


From mail at joachim-breitner.de  Thu Aug 17 11:53:20 2023
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Thu, 17 Aug 2023 13:53:20 +0200
Subject: [ghc-steering-committee] Please review #608: no implicit bindings
 with -XPatternSignatures, Shepherd: Richard
Message-ID: <7a7864cf9b885c11fb6924313368dfbbd21da494.camel@joachim-breitner.de>

Dear Committee,

John Ericson continues his series of amendments to #448 (Modern Scoped
Type Variables); in #608 he scales back -XPatternSignatures so that it
does not include pattern signature bindings. This is quite similar to my #119
from 5 years ago.

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

I’d like to assign this to Richard as one of the experts on scoped type variables.


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  Thu Aug 17 11:55:02 2023
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Thu, 17 Aug 2023 13:55:02 +0200
Subject: [ghc-steering-committee]  Please review #583: HasField redesign,
 Shepherd: Arnaud
Message-ID: <92003b507027fafa69c2e0f69717a9ff587fc1c4.camel@joachim-breitner.de>

Dear Committee,

Adam Gundry proposes an overhaul of the HasField type class.

https://github.com/ghc-proposals/ghc-proposals/pull/583
https://github.com/adamgundry/ghc-proposals/blob/hasfield-redesign/proposals/0000-hasfield-redesign.rst

I’d like to assign this to Arnaud.

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  Thu Aug 17 11:58:49 2023
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Thu, 17 Aug 2023 13:58:49 +0200
Subject: [ghc-steering-committee]  Please review #609: (p1;
 p2) for or-patterns, Shepherd: Chris
Message-ID: <1827aab288b44ee4c9b104d06511fb622af0c279.camel@joachim-breitner.de>

Dear Committee,

Sebastian Graf and David Knothe have reasons to revisit the Or-patterns
proposal (#522) and change the syntax, also based on a series of
popular votes.

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

I’d like to assign this to Chris Dornan.

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  Sat Aug 19 09:18:32 2023
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Sat, 19 Aug 2023 11:18:32 +0200
Subject: [ghc-steering-committee] Please review #607: Amendments clarify
 treatment of term variables in types, Shepherd: Vlad
Message-ID: <fcd786f756bea5078f4a2fe25c3dba9bf29321b1.camel@joachim-breitner.de>

Dear Committee,

Jakob Brünker spotted some inconsistencies in 281 (visible forall) and
#378 (Design of DH):

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

I’d like to assign this to Vlad.

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

Dear GHC steering committee

A month ago I wrote to you concerning GHC Proposal 601 about GHC extensions
<https://github.com/david-christiansen/ghc-proposals/blob/extension-lifecycle-proposal/proposals/0000-extension-lifecycle-framework.md>
.

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
>

It's holiday time I know, but still, I did not get a single reply.  Is that
because you all love it or you all hate it?  RSVP!

I propose acceptance, modulo a few clarifications which I have posted on
the discussion thread.

Please reply, yea or nay.

Simon

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

> 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/20230824/58521cb3/attachment.html>

From adam at well-typed.com  Thu Aug 24 19:45:12 2023
From: adam at well-typed.com (Adam Gundry)
Date: Thu, 24 Aug 2023 20:45:12 +0100
Subject: [ghc-steering-committee] Please review #601: Extension
 lifecycle, Shepherd: Simon PJ
In-Reply-To: <CAJKmMz_hP1M9LmVaboxQN7bOUH5qYDFQfZ1if6Gf6uVy-CdWeg@mail.gmail.com>
References: <1357869695964d4f88703711ca1efbe9e611d252.camel@joachim-breitner.de>
 <CAJKmMz9R0pbuZxFeNdWb+v4bF7vgoUF8AKZcVQ6DPNTat+hc+A@mail.gmail.com>
 <CAJKmMz_hP1M9LmVaboxQN7bOUH5qYDFQfZ1if6Gf6uVy-CdWeg@mail.gmail.com>
Message-ID: <299b5773-27c2-7085-0782-e454cddb60c6@well-typed.com>

I support acceptance. Clearly communicating the stability of extensions 
seems like a good step towards reducing uncertainty about their use.

The only reservation I have is that the proposal introduces warnings by 
default for all Experimental and Deprecated extensions, and with -Wall 
for all Legacy extensions. This seems like it could be quite noisy. It 
all hinges on which extensions fall into each category, though, which is 
not yet determined. So I'm content to wait for a follow-up proposal 
defining the categorisation (which will be quite a task in its own 
right!). We can always review the appropriate frequency of warnings when 
we know exactly which extensions will be warned about.

It also occurs to me that extensions like NoFieldSelectors may be 
awkward as we might want to say that FieldSelectors is Stable but 
NoFieldSelectors is Experimental. But I doubt that's insurmountable, and 
we can resolve it in the subsequent proposal.

Cheers,

Adam


On 24/08/2023 16:42, Simon Peyton Jones wrote:
> Dear GHC steering committee
> 
> A month ago I wrote to you concerning GHC Proposal 601 about GHC 
> extensions 
> <https://github.com/david-christiansen/ghc-proposals/blob/extension-lifecycle-proposal/proposals/0000-extension-lifecycle-framework.md>.
> 
>     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 
> 
> 
> It's holiday time I know, but still, I did not get a single reply.  Is 
> that because you all love it or you all hate it?  RSVP!
> 
> I propose acceptance, modulo a few clarifications which I have posted on 
> the discussion thread.
> 
> Please reply, yea or nay.
> 
> Simon
> 
> On Tue, 25 Jul 2023 at 15:58, Simon Peyton Jones 
> <simon.peytonjones at gmail.com <mailto:simon.peytonjones at gmail.com>> wrote:
> 
>     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 <mailto: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/ghc-proposals/ghc-proposals/pull/601>
>         https://github.com/david-christiansen/ghc-proposals/blob/extension-lifecycle-proposal/proposals/0000-extension-lifecycle-framework.md <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
>         <https://github.com/ghc-proposals/ghc-proposals#committee-process>
> 
> 
>         Cheers,
>         Joachim
> 
> 
>         -- 
>         Joachim Breitner
>         mail at joachim-breitner.de <mailto:mail at joachim-breitner.de>
>         http://www.joachim-breitner.de/ <http://www.joachim-breitner.de/>


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

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


From mail at joachim-breitner.de  Thu Aug 24 20:20:59 2023
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Thu, 24 Aug 2023 22:20:59 +0200
Subject: [ghc-steering-committee] Please review #601: Extension
 lifecycle, Shepherd: Simon PJ
In-Reply-To: <CAJKmMz_hP1M9LmVaboxQN7bOUH5qYDFQfZ1if6Gf6uVy-CdWeg@mail.gmail.com>
References: <1357869695964d4f88703711ca1efbe9e611d252.camel@joachim-breitner.de>
 <CAJKmMz9R0pbuZxFeNdWb+v4bF7vgoUF8AKZcVQ6DPNTat+hc+A@mail.gmail.com>
 <CAJKmMz_hP1M9LmVaboxQN7bOUH5qYDFQfZ1if6Gf6uVy-CdWeg@mail.gmail.com>
Message-ID: <363d3648dc545bf2ef897c7f571b4c3ac450d895.camel@joachim-breitner.de>

Hi,

I am lukewarm on the proposal. Of course it would be nice to have such
clear signal. But it’s going to be a lot of work to categorize all
extensions initially, and then update this categorization as we go.
Given that even defining a subset of “very stable and mature” (AKA
GHC20xx) is something that was quite some effort, I am not fully
optimistic that we’ll be able to deliver.

But we can at least say we’d like to try, and then see how the
categorization goes, so yea from me.

Cheers,
Joachim



Am Donnerstag, dem 24.08.2023 um 16:42 +0100 schrieb Simon Peyton
Jones:
> Dear GHC steering committee
> 
> A month ago I wrote to you concerning GHC Proposal 601 about GHC
> extensions.
> 
> > 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 
> > 
> 
> 
> It's holiday time I know, but still, I did not get a single reply. 
> Is that because you all love it or you all hate it?  RSVP!
> 
> I propose acceptance, modulo a few clarifications which I have posted
> on the discussion thread.
> 
> Please reply, yea or nay.
> 
> Simon
> 
> On Tue, 25 Jul 2023 at 15:58, Simon Peyton Jones
> <simon.peytonjones at gmail.com> wrote:
> > Dear GHC Steering Committee
> > 
> > Proposal #601 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
> > > 
> > > 
> > > _______________________________________________
> > > 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 arnaud.spiwack at tweag.io  Fri Aug 25 07:39:02 2023
From: arnaud.spiwack at tweag.io (Arnaud Spiwack)
Date: Fri, 25 Aug 2023 09:39:02 +0200
Subject: [ghc-steering-committee] Please review #601: Extension
 lifecycle, Shepherd: Simon PJ
In-Reply-To: <363d3648dc545bf2ef897c7f571b4c3ac450d895.camel@joachim-breitner.de>
References: <1357869695964d4f88703711ca1efbe9e611d252.camel@joachim-breitner.de>
 <CAJKmMz9R0pbuZxFeNdWb+v4bF7vgoUF8AKZcVQ6DPNTat+hc+A@mail.gmail.com>
 <CAJKmMz_hP1M9LmVaboxQN7bOUH5qYDFQfZ1if6Gf6uVy-CdWeg@mail.gmail.com>
 <363d3648dc545bf2ef897c7f571b4c3ac450d895.camel@joachim-breitner.de>
Message-ID: <CAGwnsnkn=Yn+mz-rw=v79MBir+eSjgdu01nycb7oAnALzEVYXQ@mail.gmail.com>

I'm rather agnostic on the proposal. I'm actually not convinced it solves a
real problem for users (though I can see how this categorisation would
inform our stance on backward compatibility, so it can be very useful for
us steering committee), on the other hand, the proposal seems to be
received with a lot of enthusiasm.

On Thu, 24 Aug 2023 at 22:21, Joachim Breitner <mail at joachim-breitner.de>
wrote:

> Hi,
>
> I am lukewarm on the proposal. Of course it would be nice to have such
> clear signal. But it’s going to be a lot of work to categorize all
> extensions initially, and then update this categorization as we go.
> Given that even defining a subset of “very stable and mature” (AKA
> GHC20xx) is something that was quite some effort, I am not fully
> optimistic that we’ll be able to deliver.
>
> But we can at least say we’d like to try, and then see how the
> categorization goes, so yea from me.
>
> Cheers,
> Joachim
>
>
>
> Am Donnerstag, dem 24.08.2023 um 16:42 +0100 schrieb Simon Peyton
> Jones:
> > Dear GHC steering committee
> >
> > A month ago I wrote to you concerning GHC Proposal 601 about GHC
> > extensions.
> >
> > > 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
> > >
> >
> >
> > It's holiday time I know, but still, I did not get a single reply.
> > Is that because you all love it or you all hate it?  RSVP!
> >
> > I propose acceptance, modulo a few clarifications which I have posted
> > on the discussion thread.
> >
> > Please reply, yea or nay.
> >
> > Simon
> >
> > On Tue, 25 Jul 2023 at 15:58, Simon Peyton Jones
> > <simon.peytonjones at gmail.com> wrote:
> > > Dear GHC Steering Committee
> > >
> > > Proposal #601 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
> > > >
> > > >
> > > > _______________________________________________
> > > > 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/20230825/ca89e419/attachment-0001.html>

From mail at joachim-breitner.de  Fri Aug 25 14:38:43 2023
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Fri, 25 Aug 2023 16:38:43 +0200
Subject: [ghc-steering-committee] #605: visible forall to work without
 ScopedTypeVariables, rec: accept
Message-ID: <3629a3ed10bedf7ad4270276de1b345c5d24cca2.camel@joachim-breitner.de>

Dear committee,

Vladislav Zavialov in
https://github.com/ghc-proposals/ghc-proposals/pull/605
proposes a small fix to #281, namely that for

   f :: forall x -> Show x => x -> String
   f (type t) = show @t

to work, ExplicitNamespaces and RequiredTypeArguments is sufficient,
and we should not also require ScopedTypeVariables, which we are moving
away from.

I’ll shepherd this myself, and I suggest acceptance.


Cheers,
Joachim





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


From simon.peytonjones at gmail.com  Fri Aug 25 16:12:31 2023
From: simon.peytonjones at gmail.com (Simon Peyton Jones)
Date: Fri, 25 Aug 2023 17:12:31 +0100
Subject: [ghc-steering-committee] #605: visible forall to work without
 ScopedTypeVariables, rec: accept
In-Reply-To: <3629a3ed10bedf7ad4270276de1b345c5d24cca2.camel@joachim-breitner.de>
References: <3629a3ed10bedf7ad4270276de1b345c5d24cca2.camel@joachim-breitner.de>
Message-ID: <CAJKmMz9GYOM0vg3Z54eOf_X_ACzGA-AiLUmkzspyNsjHsE69Pg@mail.gmail.com>

I support this.

Simon

On Fri, 25 Aug 2023 at 15:39, Joachim Breitner <mail at joachim-breitner.de>
wrote:

> Dear committee,
>
> Vladislav Zavialov in
> https://github.com/ghc-proposals/ghc-proposals/pull/605
> proposes a small fix to #281, namely that for
>
>    f :: forall x -> Show x => x -> String
>    f (type t) = show @t
>
> to work, ExplicitNamespaces and RequiredTypeArguments is sufficient,
> and we should not also require ScopedTypeVariables, which we are moving
> away from.
>
> I’ll shepherd this myself, and I suggest acceptance.
>
>
> 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/20230825/7ba2afe4/attachment.html>

From lists at richarde.dev  Fri Aug 25 19:32:31 2023
From: lists at richarde.dev (Richard Eisenberg)
Date: Fri, 25 Aug 2023 19:32:31 +0000
Subject: [ghc-steering-committee] #605: visible forall to work without
 ScopedTypeVariables, rec: accept
In-Reply-To: <CAJKmMz9GYOM0vg3Z54eOf_X_ACzGA-AiLUmkzspyNsjHsE69Pg@mail.gmail.com>
References: <3629a3ed10bedf7ad4270276de1b345c5d24cca2.camel@joachim-breitner.de>
 <CAJKmMz9GYOM0vg3Z54eOf_X_ACzGA-AiLUmkzspyNsjHsE69Pg@mail.gmail.com>
Message-ID: <010f018a2e2f11b0-aac09ed6-0c14-455f-b60f-5867192490a9-000000@us-east-2.amazonses.com>

Yes -- I'm in support.

> On Aug 25, 2023, at 12:12 PM, Simon Peyton Jones <simon.peytonjones at gmail.com> wrote:
> 
> I support this.
> 
> Simon
> 
> On Fri, 25 Aug 2023 at 15:39, Joachim Breitner <mail at joachim-breitner.de <mailto:mail at joachim-breitner.de>> wrote:
> Dear committee,
> 
> Vladislav Zavialov in
> https://github.com/ghc-proposals/ghc-proposals/pull/605 <https://github.com/ghc-proposals/ghc-proposals/pull/605>
> proposes a small fix to #281, namely that for
> 
>    f :: forall x -> Show x => x -> String
>    f (type t) = show @t
> 
> to work, ExplicitNamespaces and RequiredTypeArguments is sufficient,
> and we should not also require ScopedTypeVariables, which we are moving
> away from.
> 
> I’ll shepherd this myself, and I suggest acceptance.
> 
> 
> Cheers,
> Joachim
> 
> 
> 
> 
> 
> -- 
> Joachim Breitner
>   mail at joachim-breitner.de <mailto:mail at joachim-breitner.de>
>   http://www.joachim-breitner.de/ <http://www.joachim-breitner.de/>
> 
> _______________________________________________
> 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/20230825/8c86e221/attachment.html>

From adam at well-typed.com  Fri Aug 25 19:54:25 2023
From: adam at well-typed.com (Adam Gundry)
Date: Fri, 25 Aug 2023 20:54:25 +0100
Subject: [ghc-steering-committee] #605: visible forall to work without
 ScopedTypeVariables, rec: accept
In-Reply-To: <010f018a2e2f11b0-aac09ed6-0c14-455f-b60f-5867192490a9-000000@us-east-2.amazonses.com>
References: <3629a3ed10bedf7ad4270276de1b345c5d24cca2.camel@joachim-breitner.de>
 <CAJKmMz9GYOM0vg3Z54eOf_X_ACzGA-AiLUmkzspyNsjHsE69Pg@mail.gmail.com>
 <010f018a2e2f11b0-aac09ed6-0c14-455f-b60f-5867192490a9-000000@us-east-2.amazonses.com>
Message-ID: <840303f0-30ab-b3c5-12cb-3bbe206760d4@well-typed.com>

Agreed, we shouldn't require ScopedTypeVariables here.

Adam


On 25/08/2023 20:32, Richard Eisenberg wrote:
> Yes -- I'm in support.
> 
>> On Aug 25, 2023, at 12:12 PM, Simon Peyton Jones 
>> <simon.peytonjones at gmail.com <mailto:simon.peytonjones at gmail.com>> wrote:
>>
>> I support this.
>>
>> Simon
>>
>> On Fri, 25 Aug 2023 at 15:39, Joachim Breitner 
>> <mail at joachim-breitner.de <mailto:mail at joachim-breitner.de>> wrote:
>>
>>     Dear committee,
>>
>>     Vladislav Zavialov in
>>     https://github.com/ghc-proposals/ghc-proposals/pull/605
>>     <https://github.com/ghc-proposals/ghc-proposals/pull/605>
>>     proposes a small fix to #281, namely that for
>>
>>        f :: forall x -> Show x => x -> String
>>        f (type t) = show @t
>>
>>     to work, ExplicitNamespaces and RequiredTypeArguments is sufficient,
>>     and we should not also require ScopedTypeVariables, which we are
>>     moving
>>     away from.
>>
>>     I’ll shepherd this myself, and I suggest acceptance.
>>
>>
>>     Cheers,
>>     Joachim
>>
>>
>>
>>
>>
>>     -- 
>>     Joachim Breitner
>>     mail at joachim-breitner.de <mailto:mail at joachim-breitner.de>
>>     http://www.joachim-breitner.de/ <http://www.joachim-breitner.de/>
>>


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

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


From lists at richarde.dev  Fri Aug 25 20:53:06 2023
From: lists at richarde.dev (Richard Eisenberg)
Date: Fri, 25 Aug 2023 20:53:06 +0000
Subject: [ghc-steering-committee] Please review #601: Extension
 lifecycle, Shepherd: Simon PJ
In-Reply-To: <CAGwnsnkn=Yn+mz-rw=v79MBir+eSjgdu01nycb7oAnALzEVYXQ@mail.gmail.com>
References: <1357869695964d4f88703711ca1efbe9e611d252.camel@joachim-breitner.de>
 <CAJKmMz9R0pbuZxFeNdWb+v4bF7vgoUF8AKZcVQ6DPNTat+hc+A@mail.gmail.com>
 <CAJKmMz_hP1M9LmVaboxQN7bOUH5qYDFQfZ1if6Gf6uVy-CdWeg@mail.gmail.com>
 <363d3648dc545bf2ef897c7f571b4c3ac450d895.camel@joachim-breitner.de>
 <CAGwnsnkn=Yn+mz-rw=v79MBir+eSjgdu01nycb7oAnALzEVYXQ@mail.gmail.com>
Message-ID: <010f018a2e78d9ab-cf4afd2d-63cb-4e98-9322-e8c8bcdc7e28-000000@us-east-2.amazonses.com>

I've posted on the proposal. I won't stand in the way of a proposal that has generated positive feedback such as this one, but I worry we've missed the head of the nail here by a little bit. And adopting this proposal has a very real cost, in that it adds another layer of bureaucracy for Haskellers.

Richard

> On Aug 25, 2023, at 3:39 AM, Arnaud Spiwack <arnaud.spiwack at tweag.io> wrote:
> 
> I'm rather agnostic on the proposal. I'm actually not convinced it solves a real problem for users (though I can see how this categorisation would inform our stance on backward compatibility, so it can be very useful for us steering committee), on the other hand, the proposal seems to be received with a lot of enthusiasm.
> 
> On Thu, 24 Aug 2023 at 22:21, Joachim Breitner <mail at joachim-breitner.de <mailto:mail at joachim-breitner.de>> wrote:
> Hi,
> 
> I am lukewarm on the proposal. Of course it would be nice to have such
> clear signal. But it’s going to be a lot of work to categorize all
> extensions initially, and then update this categorization as we go.
> Given that even defining a subset of “very stable and mature” (AKA
> GHC20xx) is something that was quite some effort, I am not fully
> optimistic that we’ll be able to deliver.
> 
> But we can at least say we’d like to try, and then see how the
> categorization goes, so yea from me.
> 
> Cheers,
> Joachim
> 
> 
> 
> Am Donnerstag, dem 24.08.2023 um 16:42 +0100 schrieb Simon Peyton
> Jones:
> > Dear GHC steering committee
> > 
> > A month ago I wrote to you concerning GHC Proposal 601 about GHC
> > extensions.
> > 
> > > 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 
> > > 
> > 
> > 
> > It's holiday time I know, but still, I did not get a single reply. 
> > Is that because you all love it or you all hate it?  RSVP!
> > 
> > I propose acceptance, modulo a few clarifications which I have posted
> > on the discussion thread.
> > 
> > Please reply, yea or nay.
> > 
> > Simon
> > 
> > On Tue, 25 Jul 2023 at 15:58, Simon Peyton Jones
> > <simon.peytonjones at gmail.com <mailto:simon.peytonjones at gmail.com>> wrote:
> > > Dear GHC Steering Committee
> > > 
> > > Proposal #601 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 <mailto: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/ghc-proposals/ghc-proposals/pull/601>
> > > > https://github.com/david-christiansen/ghc-proposals/blob/extension-lifecycle-proposal/proposals/0000-extension-lifecycle-framework.md <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 <https://github.com/ghc-proposals/ghc-proposals#committee-process>
> > > > 
> > > > 
> > > > Cheers,
> > > > Joachim
> > > > 
> > > > 
> > > > _______________________________________________
> > > > 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>
> 
> -- 
> Joachim Breitner
>   mail at joachim-breitner.de <mailto:mail at joachim-breitner.de>
>   http://www.joachim-breitner.de/ <http://www.joachim-breitner.de/>
> 
> _______________________________________________
> 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
> 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/20230825/83d41d30/attachment-0001.html>

From arnaud.spiwack at tweag.io  Mon Aug 28 07:45:38 2023
From: arnaud.spiwack at tweag.io (Arnaud Spiwack)
Date: Mon, 28 Aug 2023 09:45:38 +0200
Subject: [ghc-steering-committee] #605: visible forall to work without
 ScopedTypeVariables, rec: accept
In-Reply-To: <840303f0-30ab-b3c5-12cb-3bbe206760d4@well-typed.com>
References: <3629a3ed10bedf7ad4270276de1b345c5d24cca2.camel@joachim-breitner.de>
 <CAJKmMz9GYOM0vg3Z54eOf_X_ACzGA-AiLUmkzspyNsjHsE69Pg@mail.gmail.com>
 <010f018a2e2f11b0-aac09ed6-0c14-455f-b60f-5867192490a9-000000@us-east-2.amazonses.com>
 <840303f0-30ab-b3c5-12cb-3bbe206760d4@well-typed.com>
Message-ID: <CAGwnsnn62DeTSSxN9Pr84Pqn5BTCrG3HKT21ARaRGN5YAr6gOA@mail.gmail.com>

I don't remember the details, but I assume that -XRequiredTypeArguments is
essentially useless without this sort of patterns, isn't it? Plus this is
the only occurrence of -XScopedTypeVariables in the text (well, there's one
just below, but it's about what -XScopedTypeVariables *doesn't* do). It
sounds like the right choice.

On Fri, 25 Aug 2023 at 21:54, Adam Gundry <adam at well-typed.com> wrote:

> Agreed, we shouldn't require ScopedTypeVariables here.
>
> Adam
>
>
> On 25/08/2023 20:32, Richard Eisenberg wrote:
> > Yes -- I'm in support.
> >
> >> On Aug 25, 2023, at 12:12 PM, Simon Peyton Jones
> >> <simon.peytonjones at gmail.com <mailto:simon.peytonjones at gmail.com>>
> wrote:
> >>
> >> I support this.
> >>
> >> Simon
> >>
> >> On Fri, 25 Aug 2023 at 15:39, Joachim Breitner
> >> <mail at joachim-breitner.de <mailto:mail at joachim-breitner.de>> wrote:
> >>
> >>     Dear committee,
> >>
> >>     Vladislav Zavialov in
> >>     https://github.com/ghc-proposals/ghc-proposals/pull/605
> >>     <https://github.com/ghc-proposals/ghc-proposals/pull/605>
> >>     proposes a small fix to #281, namely that for
> >>
> >>        f :: forall x -> Show x => x -> String
> >>        f (type t) = show @t
> >>
> >>     to work, ExplicitNamespaces and RequiredTypeArguments is sufficient,
> >>     and we should not also require ScopedTypeVariables, which we are
> >>     moving
> >>     away from.
> >>
> >>     I’ll shepherd this myself, and I suggest acceptance.
> >>
> >>
> >>     Cheers,
> >>     Joachim
> >>
> >>
> >>
> >>
> >>
> >>     --
> >>     Joachim Breitner
> >>     mail at joachim-breitner.de <mailto:mail at joachim-breitner.de>
> >>     http://www.joachim-breitner.de/ <http://www.joachim-breitner.de/>
> >>
>
>
> --
> Adam Gundry, Haskell Consultant
> Well-Typed LLP, https://www.well-typed.com/
>
> Registered in England & Wales, OC335890
> 27 Old Gloucester Street, London WC1N 3AX, England
>
> _______________________________________________
> 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/20230828/15ff5939/attachment.html>

From vlad.z.4096 at gmail.com  Tue Aug 29 06:48:06 2023
From: vlad.z.4096 at gmail.com (Vladislav)
Date: Tue, 29 Aug 2023 08:48:06 +0200
Subject: [ghc-steering-committee] #607: Amend #281 (visible forall) and #378
 (Design of DH) to clarify treatment of term variables in types (rec:
 accept)
Message-ID: <68450S.HDBN7L22NASR1@gmail.com>

Dear Committee,

Jakob Brünker has proposed #607, an amendment to proposals #281 
(visible forall) and #378 (Design of DH).
See the diff here: 
<https://github.com/ghc-proposals/ghc-proposals/pull/607/files>

The amendment concerns type checking of term-level variables appearing 
in types, for example:

  f :: forall (a :: Bool) -> ...   -- visible forall, `f` expects a 
type-level Bool
  g :: Bool -> ...  -- ordinary arrow, `g` expects a term-level Bool
  g x = f x

What should happen to `x`, bound as a term variable but used as a type? 
#378 "Design for Dependent Types" already has an answer to this 
question: treat `x` as a skolem. But there are two problems

1. #378 does not explain this design decision in sufficient detail. 
This led Simon to question its inclusion: "Does it have any value, 
really? Why not just reject?"
2. #281 follows this design in one section, saying "treated as a fresh 
skolem constant"; and rejects it in another section, saying "any uses 
of terms in types are ill-typed". There is a contradiction.

The amendment addresses both issues as follows:

1. A new example is added to #378, explaining how treating `x` as a 
skolem is useful, but only if `foreach` is available (a retained 
quantifier that allows dependent pattern matching)
2. Contradiction in #281 is resolved in favor of rejecting any uses of 
terms in types as ill-typed, saving this feature for a future proposal.

I recommend to accept. Please share your thoughts either here or 
directly on GitHub.

Vlad

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

From arnaud.spiwack at tweag.io  Tue Aug 29 07:43:33 2023
From: arnaud.spiwack at tweag.io (Arnaud Spiwack)
Date: Tue, 29 Aug 2023 09:43:33 +0200
Subject: [ghc-steering-committee] #607: Amend #281 (visible forall) and
 #378 (Design of DH) to clarify treatment of term variables in types (rec:
 accept)
In-Reply-To: <68450S.HDBN7L22NASR1@gmail.com>
References: <68450S.HDBN7L22NASR1@gmail.com>
Message-ID: <CAGwnsn=jkApY3h6M5uWPcu_mJVgdvKG6cbJUoNWGN88uD4TtdQ@mail.gmail.com>

This seems highly uncontroversial to me. I'm happy to support the amendment.

On Tue, 29 Aug 2023 at 08:48, Vladislav <vlad.z.4096 at gmail.com> wrote:

> Dear Committee,
>
> Jakob Brünker has proposed #607, an amendment to proposals #281 (visible
> forall) and #378 (Design of DH).
> See the diff here:
> https://github.com/ghc-proposals/ghc-proposals/pull/607/files
>
> The amendment concerns type checking of term-level variables appearing in
> types, for example:
>
>   f :: forall (a :: Bool) -> ...   -- visible forall, `f` expects a
> type-level Bool
>   g :: Bool -> ...  -- ordinary arrow, `g` expects a term-level Bool
>   g x = f x
>
> What should happen to `x`, bound as a term variable but used as a type?
> #378 "Design for Dependent Types" already has an answer to this question:
> treat `x` as a skolem. But there are two problems
>
> 1. #378 does not explain this design decision in sufficient detail. This
> led Simon to question its inclusion: "Does it have any value, really? Why
> not just reject?"
> 2. #281 follows this design in one section, saying "treated as a fresh
> skolem constant"; and rejects it in another section, saying "any uses of
> terms in types are ill-typed". There is a contradiction.
>
> The amendment addresses both issues as follows:
>
> 1. A new example is added to #378, explaining how treating `x` as a skolem
> is useful, but only if `foreach` is available (a retained quantifier that
> allows dependent pattern matching)
> 2. Contradiction in #281 is resolved in favor of rejecting any uses of
> terms in types as ill-typed, saving this feature for a future proposal.
>
> I recommend to accept. Please share your thoughts either here or directly
> on GitHub.
>
> Vlad
> _______________________________________________
> 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/20230829/aeee6420/attachment.html>

From simon.peytonjones at gmail.com  Tue Aug 29 07:56:21 2023
From: simon.peytonjones at gmail.com (Simon Peyton Jones)
Date: Tue, 29 Aug 2023 08:56:21 +0100
Subject: [ghc-steering-committee] #607: Amend #281 (visible forall) and
 #378 (Design of DH) to clarify treatment of term variables in types (rec:
 accept)
In-Reply-To: <68450S.HDBN7L22NASR1@gmail.com>
References: <68450S.HDBN7L22NASR1@gmail.com>
Message-ID: <CAJKmMz-nRToziTutArD5bKbbXZuTdbkVNpKw1BVm_RxYLoumTg@mail.gmail.com>

I support.

Simon

On Tue, 29 Aug 2023 at 07:48, Vladislav <vlad.z.4096 at gmail.com> wrote:

> Dear Committee,
>
> Jakob Brünker has proposed #607, an amendment to proposals #281 (visible
> forall) and #378 (Design of DH).
> See the diff here:
> https://github.com/ghc-proposals/ghc-proposals/pull/607/files
>
> The amendment concerns type checking of term-level variables appearing in
> types, for example:
>
>   f :: forall (a :: Bool) -> ...   -- visible forall, `f` expects a
> type-level Bool
>   g :: Bool -> ...  -- ordinary arrow, `g` expects a term-level Bool
>   g x = f x
>
> What should happen to `x`, bound as a term variable but used as a type?
> #378 "Design for Dependent Types" already has an answer to this question:
> treat `x` as a skolem. But there are two problems
>
> 1. #378 does not explain this design decision in sufficient detail. This
> led Simon to question its inclusion: "Does it have any value, really? Why
> not just reject?"
> 2. #281 follows this design in one section, saying "treated as a fresh
> skolem constant"; and rejects it in another section, saying "any uses of
> terms in types are ill-typed". There is a contradiction.
>
> The amendment addresses both issues as follows:
>
> 1. A new example is added to #378, explaining how treating `x` as a skolem
> is useful, but only if `foreach` is available (a retained quantifier that
> allows dependent pattern matching)
> 2. Contradiction in #281 is resolved in favor of rejecting any uses of
> terms in types as ill-typed, saving this feature for a future proposal.
>
> I recommend to accept. Please share your thoughts either here or directly
> on GitHub.
>
> Vlad
> _______________________________________________
> 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/20230829/8ff6a28b/attachment.html>

From mail at joachim-breitner.de  Tue Aug 29 08:36:33 2023
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Tue, 29 Aug 2023 10:36:33 +0200
Subject: [ghc-steering-committee] #607: Amend #281 (visible forall) and
 #378 (Design of DH) to clarify treatment of term variables in types (rec:
 accept)
In-Reply-To: <68450S.HDBN7L22NASR1@gmail.com>
References: <68450S.HDBN7L22NASR1@gmail.com>
Message-ID: <c750317060ba5bef600c8a5e344fe4c73fc1e391.camel@joachim-breitner.de>

Hi,

Am Dienstag, dem 29.08.2023 um 08:48 +0200 schrieb Vladislav:
> 2. Contradiction in #281 is resolved in favor of rejecting any uses
> of terms in types as ill-typed, saving this feature for a future
> proposal.

clearly a safe and conversative path forward; in support.

Cheers,
Joachim

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


From moritz.angermann at gmail.com  Tue Aug 29 08:40:15 2023
From: moritz.angermann at gmail.com (Moritz Angermann)
Date: Tue, 29 Aug 2023 16:40:15 +0800
Subject: [ghc-steering-committee] #607: Amend #281 (visible forall) and
 #378 (Design of DH) to clarify treatment of term variables in types (rec:
 accept)
In-Reply-To: <68450S.HDBN7L22NASR1@gmail.com>
References: <68450S.HDBN7L22NASR1@gmail.com>
Message-ID: <CAKfdd-wijin+auVgMNYhNsd45h7zKnUyTDXoWtOCCTjiWoaCmA@mail.gmail.com>

Looks like an overall improvement to me. I’m in support.

On Tue, 29 Aug 2023 at 2:48 PM, Vladislav <vlad.z.4096 at gmail.com> wrote:

> Dear Committee,
>
> Jakob Brünker has proposed #607, an amendment to proposals #281 (visible
> forall) and #378 (Design of DH).
> See the diff here:
> https://github.com/ghc-proposals/ghc-proposals/pull/607/files
>
> The amendment concerns type checking of term-level variables appearing in
> types, for example:
>
>   f :: forall (a :: Bool) -> ...   -- visible forall, `f` expects a
> type-level Bool
>   g :: Bool -> ...  -- ordinary arrow, `g` expects a term-level Bool
>   g x = f x
>
> What should happen to `x`, bound as a term variable but used as a type?
> #378 "Design for Dependent Types" already has an answer to this question:
> treat `x` as a skolem. But there are two problems
>
> 1. #378 does not explain this design decision in sufficient detail. This
> led Simon to question its inclusion: "Does it have any value, really? Why
> not just reject?"
> 2. #281 follows this design in one section, saying "treated as a fresh
> skolem constant"; and rejects it in another section, saying "any uses of
> terms in types are ill-typed". There is a contradiction.
>
> The amendment addresses both issues as follows:
>
> 1. A new example is added to #378, explaining how treating `x` as a skolem
> is useful, but only if `foreach` is available (a retained quantifier that
> allows dependent pattern matching)
> 2. Contradiction in #281 is resolved in favor of rejecting any uses of
> terms in types as ill-typed, saving this feature for a future proposal.
>
> I recommend to accept. Please share your thoughts either here or directly
> on GitHub.
>
> Vlad
> _______________________________________________
> 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/20230829/924a3bf8/attachment-0001.html>

From lists at richarde.dev  Tue Aug 29 22:57:31 2023
From: lists at richarde.dev (Richard Eisenberg)
Date: Tue, 29 Aug 2023 22:57:31 +0000
Subject: [ghc-steering-committee] #607: Amend #281 (visible forall) and
 #378 (Design of DH) to clarify treatment of term variables in types (rec:
 accept)
In-Reply-To: <CAKfdd-wijin+auVgMNYhNsd45h7zKnUyTDXoWtOCCTjiWoaCmA@mail.gmail.com>
References: <68450S.HDBN7L22NASR1@gmail.com>
 <CAKfdd-wijin+auVgMNYhNsd45h7zKnUyTDXoWtOCCTjiWoaCmA@mail.gmail.com>
Message-ID: <010f018a43842ffe-3535dce0-f3aa-4079-8add-522f5472ab18-000000@us-east-2.amazonses.com>

Yes, in support. Thanks for the nice summary.

Richard

> On Aug 29, 2023, at 4:40 AM, Moritz Angermann <moritz.angermann at gmail.com> wrote:
> 
> Looks like an overall improvement to me. I’m in support. 
> 
> On Tue, 29 Aug 2023 at 2:48 PM, Vladislav <vlad.z.4096 at gmail.com <mailto:vlad.z.4096 at gmail.com>> wrote:
> Dear Committee,
> 
> Jakob Brünker has proposed #607, an amendment to proposals #281 (visible forall) and #378 (Design of DH). 
> See the diff here: https://github.com/ghc-proposals/ghc-proposals/pull/607/files <https://github.com/ghc-proposals/ghc-proposals/pull/607/files>
> 
> The amendment concerns type checking of term-level variables appearing in types, for example:
> 
>   f :: forall (a :: Bool) -> ...   -- visible forall, `f` expects a type-level Bool
>   g :: Bool -> ...  -- ordinary arrow, `g` expects a term-level Bool
>   g x = f x
> 
> What should happen to `x`, bound as a term variable but used as a type? #378 "Design for Dependent Types" already has an answer to this question: treat `x` as a skolem. But there are two problems
> 
> 1. #378 does not explain this design decision in sufficient detail. This led Simon to question its inclusion: "Does it have any value, really? Why not just reject?"
> 2. #281 follows this design in one section, saying "treated as a fresh skolem constant"; and rejects it in another section, saying "any uses of terms in types are ill-typed". There is a contradiction.
> 
> The amendment addresses both issues as follows:
> 
> 1. A new example is added to #378, explaining how treating `x` as a skolem is useful, but only if `foreach` is available (a retained quantifier that allows dependent pattern matching)
> 2. Contradiction in #281 is resolved in favor of rejecting any uses of terms in types as ill-typed, saving this feature for a future proposal.
> 
> I recommend to accept. Please share your thoughts either here or directly on GitHub.
> 
> Vlad
> _______________________________________________
> 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/20230829/2772545d/attachment.html>

From marlowsd at gmail.com  Wed Aug 30 10:43:19 2023
From: marlowsd at gmail.com (Simon Marlow)
Date: Wed, 30 Aug 2023 11:43:19 +0100
Subject: [ghc-steering-committee] =?utf-8?q?Language_Extension_Policy_?=
	=?utf-8?b?4oCTIFJvdW5kIDM=?=
In-Reply-To: <1d123540-8d0e-0574-7ee1-f66882d04c65@well-typed.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>
 <CAGwnsnkVp3zSxi7OvKJ80Qn=xXrciXaXt5LVR-Tb1Nx6scJgVA@mail.gmail.com>
 <1d123540-8d0e-0574-7ee1-f66882d04c65@well-typed.com>
Message-ID: <CANsrgPKdr89tTPDpdP4RZoEz9RBQcOPepU13mBcB5GF-8iHzkQ@mail.gmail.com>

Apologies also from me, I took the whole 6-week school holidays off work
and I'm only just getting back into it.

On Tue, 1 Aug 2023 at 08:17, Adam Gundry <adam at well-typed.com> wrote:

>
>   * I think it would be a good idea for someone to rewrite the user's
> guide so that it represents the latest GHC20xx as the base language
>

I think even if we do nothing else, this would be a great step forwards.

Right now, extensions are the first-class mechanism, and GHC20xx is
expressed as a group of extensions. Ideally it should be the other way
around.

If we made a few changes to documentation and error messages to steer
people towards GHC20xx and away from extensions, in the long term that
would have the effect of making explicit extensions less common and more of
an experimental/advanced feature. GHC20xx would be the norm, and code that
people encounter would often be in one of the (few) GHC20xx dialects. That
would simplify things from the user's perspective, with zero impact on the
implementation. We seem to be more worried by the user-facing impact of
extension-fatigue rather than the implementation complexity of making 2^n
combinations work (going by Simon's comments, the implementation impact
isn't really a problem).

Cheers
Simon




> (e.g. so BangPatterns are documented as a feature of the language, with
> a brief mention that -XNoBangPatterns exists). We could rename chapter 6
> "Language extensions" to be "The language GHC supports". I suspect it's
> probably better to keep it organised by topic rather than bifurcating it
> into GHC20xx vs non-GHC20xx features, not least because in some cases it
> may need to document the fact that the extension's status changed over
> time.
>
>   * Error message recommendations can surely be improved to be more
> sensible (not telling users to enable certain extensions).
>
>   * I'm sceptical that reducing choice (e.g. GHC2024 mandating certain
> extensions but prohibiting others, or making it impossible to disable
> certain extensions) is really valuable. We can certainly forbid actually
> problematic interactions (by making it an error to enable two features
> that don't make sense together). But I'm unconvinced that we get any
> real conceptual or implementation benefit from a general prohibition.
>
> Cheers,
>
> Adam
>
>
> On 31/07/2023 09:41, Arnaud Spiwack wrote:
> > 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
> > <mailto: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 <mailto: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. 2^n - 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
> >>     <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
> >     <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
> > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>
>
> --
> Adam Gundry, Haskell Consultant
> Well-Typed LLP, https://www.well-typed.com/
>
> Registered in England & Wales, OC335890
> 27 Old Gloucester Street, London WC1N 3AX, England
> _______________________________________________
> 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/20230830/9b257e45/attachment-0001.html>

From arnaud.spiwack at tweag.io  Wed Aug 30 15:08:46 2023
From: arnaud.spiwack at tweag.io (Arnaud Spiwack)
Date: Wed, 30 Aug 2023 17:08:46 +0200
Subject: [ghc-steering-committee] #583: HasField redesign, rec: accept
Message-ID: <CAGwnsn=sMx6_Z2hZk4wrxs8Ry0p4kTTQYKiX+kpFXe+T2rVbfQ@mail.gmail.com>

Dear all,

[ Proposal #583 https://github.com/ghc-proposals/ghc-proposals/pull/583 ]

Our own Adam proposes to amend the design of the highly experimental
OverloadedRecordUpdate extension as had been designed in proposal #158 [
https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0158-record-set-field.rst
] and #405 [ https://github.com/ghc-proposals/ghc-proposals/pull/405 ].

Specifically, Adam proposes a modification of the type classes that would
back the extension.

In the previous design the HasField class is defined as a lens:

class HasField (n :: k) r a | r n -> a
  hasField :: r -> (a -> r, a)

The proposal is to replace it by two classes (slightly simplified)

class HasField (n :: k) r a | r n -> a
  hasField :: r -> a

class SetField (n::k) r a | r n -> a
  modifyField :: (a -> a) -> r -> a
  setField :: a -> r -> a

This is originally motivated by some performance consideration: the
prototype implementation of HasField as a lens can be very time consuming
because instances of HasFields are generated eagerly at record definition
sites, whereas the simple HasField instances can simply reuse the selectors
already generated by GHC. But a lot of thoughts have been put into the new
design, and my summary can certainly not do it justice: the proposal is
very well argumented.

A point I'll make here is that the new design is actually parametric in the
data representation of the field type. Something that wasn't possible in
the original design.

This proposal is not technically backward compatible, because the order of
argument in which OverloadedRecordUpdate expects the argument of setField
is changed. This is not essential to the proposal, but this is a more
consistent order argument with the rest of Haskell. And considering that
OverloadedRecordUpdate is very loudly advertised as experimental, I
recommend accepting this breakage.

Overall the proposal is actually more backward compatible with GHC 9.8 than
the original design, as the HasField class is left unchanged.

Overall, the proposal looks quite reasonable to me, and well-argued. I
recommend acceptance.

-- 
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/20230830/920a2019/attachment.html>

From adam at well-typed.com  Wed Aug 30 20:15:47 2023
From: adam at well-typed.com (Adam Gundry)
Date: Wed, 30 Aug 2023 21:15:47 +0100
Subject: [ghc-steering-committee] #607: Amend #281 (visible forall) and
 #378 (Design of DH) to clarify treatment of term variables in types (rec:
 accept)
In-Reply-To: <010f018a43842ffe-3535dce0-f3aa-4079-8add-522f5472ab18-000000@us-east-2.amazonses.com>
References: <68450S.HDBN7L22NASR1@gmail.com>
 <CAKfdd-wijin+auVgMNYhNsd45h7zKnUyTDXoWtOCCTjiWoaCmA@mail.gmail.com>
 <010f018a43842ffe-3535dce0-f3aa-4079-8add-522f5472ab18-000000@us-east-2.amazonses.com>
Message-ID: <a2a31094-680c-7ea2-7c5c-1d9bc252590c@well-typed.com>

Agreed, this looks sensible to me.

Adam


On 29/08/2023 23:57, Richard Eisenberg wrote:
> Yes, in support. Thanks for the nice summary.
> 
> Richard
> 
>> On Aug 29, 2023, at 4:40 AM, Moritz Angermann 
>> <moritz.angermann at gmail.com <mailto:moritz.angermann at gmail.com>> wrote:
>>
>> Looks like an overall improvement to me. I’m in support.
>>
>> On Tue, 29 Aug 2023 at 2:48 PM, Vladislav <vlad.z.4096 at gmail.com 
>> <mailto:vlad.z.4096 at gmail.com>> wrote:
>>
>>     Dear Committee,
>>
>>     Jakob Brünker has proposed #607, an amendment to proposals #281
>>     (visible forall) and #378 (Design of DH).
>>     See the diff here:
>>     https://github.com/ghc-proposals/ghc-proposals/pull/607/files
>>     <https://github.com/ghc-proposals/ghc-proposals/pull/607/files>
>>
>>     The amendment concerns type checking of term-level variables
>>     appearing in types, for example:
>>
>>       f :: forall (a :: Bool) -> ...   -- visible forall, `f` expects
>>     a type-level Bool
>>       g :: Bool -> ...  -- ordinary arrow, `g` expects a term-level Bool
>>       g x = f x
>>
>>     What should happen to `x`, bound as a term variable but used as a
>>     type? #378 "Design for Dependent Types" already has an answer to
>>     this question: treat `x` as a skolem. But there are two problems
>>
>>     1. #378 does not explain this design decision in sufficient
>>     detail. This led Simon to question its inclusion: "Does it have
>>     any value, really? Why not just reject?"
>>     2. #281 follows this design in one section, saying "treated as a
>>     fresh skolem constant"; and rejects it in another section, saying
>>     "any uses of terms in types are ill-typed". There is a contradiction.
>>
>>     The amendment addresses both issues as follows:
>>
>>     1. A new example is added to #378, explaining how treating `x` as
>>     a skolem is useful, but only if `foreach` is available (a retained
>>     quantifier that allows dependent pattern matching)
>>     2. Contradiction in #281 is resolved in favor of rejecting any
>>     uses of terms in types as ill-typed, saving this feature for a
>>     future proposal.
>>
>>     I recommend to accept. Please share your thoughts either here or
>>     directly on GitHub.
>>
>>     Vlad

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

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


From simon.peytonjones at gmail.com  Wed Aug 30 23:03:12 2023
From: simon.peytonjones at gmail.com (Simon Peyton Jones)
Date: Thu, 31 Aug 2023 00:03:12 +0100
Subject: [ghc-steering-committee] #583: HasField redesign, rec: accept
In-Reply-To: <CAGwnsn=sMx6_Z2hZk4wrxs8Ry0p4kTTQYKiX+kpFXe+T2rVbfQ@mail.gmail.com>
References: <CAGwnsn=sMx6_Z2hZk4wrxs8Ry0p4kTTQYKiX+kpFXe+T2rVbfQ@mail.gmail.com>
Message-ID: <CAJKmMz_dHKn81RdL=4WiVtHy=sA-4=E8_Ljykx+GeOOdyyMK7A@mail.gmail.com>

I support acceptance.

Simon

On Wed, 30 Aug 2023 at 16:09, Arnaud Spiwack <arnaud.spiwack at tweag.io>
wrote:

> Dear all,
>
> [ Proposal #583 https://github.com/ghc-proposals/ghc-proposals/pull/583 ]
>
> Our own Adam proposes to amend the design of the highly experimental
> OverloadedRecordUpdate extension as had been designed in proposal #158 [
> https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0158-record-set-field.rst
> ] and #405 [ https://github.com/ghc-proposals/ghc-proposals/pull/405 ].
>
> Specifically, Adam proposes a modification of the type classes that would
> back the extension.
>
> In the previous design the HasField class is defined as a lens:
>
> class HasField (n :: k) r a | r n -> a
>   hasField :: r -> (a -> r, a)
>
> The proposal is to replace it by two classes (slightly simplified)
>
> class HasField (n :: k) r a | r n -> a
>   hasField :: r -> a
>
> class SetField (n::k) r a | r n -> a
>   modifyField :: (a -> a) -> r -> a
>   setField :: a -> r -> a
>
> This is originally motivated by some performance consideration: the
> prototype implementation of HasField as a lens can be very time consuming
> because instances of HasFields are generated eagerly at record definition
> sites, whereas the simple HasField instances can simply reuse the selectors
> already generated by GHC. But a lot of thoughts have been put into the new
> design, and my summary can certainly not do it justice: the proposal is
> very well argumented.
>
> A point I'll make here is that the new design is actually parametric in
> the data representation of the field type. Something that wasn't possible
> in the original design.
>
> This proposal is not technically backward compatible, because the order of
> argument in which OverloadedRecordUpdate expects the argument of setField
> is changed. This is not essential to the proposal, but this is a more
> consistent order argument with the rest of Haskell. And considering that
> OverloadedRecordUpdate is very loudly advertised as experimental, I
> recommend accepting this breakage.
>
> Overall the proposal is actually more backward compatible with GHC 9.8
> than the original design, as the HasField class is left unchanged.
>
> Overall, the proposal looks quite reasonable to me, and well-argued. I
> recommend acceptance.
>
> --
> 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/20230831/ee8c1ea4/attachment.html>