From mail at joachim-breitner.de  Wed Jan  5 09:47:15 2022
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Wed, 05 Jan 2022 10:47:15 +0100
Subject: [ghc-steering-committee] Please review #454: custom type warnings
 Shepherd: Tom
Message-ID: <922438e93771c92175b7445bf5ed5e74f54d264a.camel@joachim-breitner.de>

Dear Committee,

this is your secretary speaking (who is back from travels):

Custom type warnings
has been proposed by Adam

https://github.com/ghc-proposals/ghc-proposals/pull/460
https://github.com/adamgundry/ghc-proposals/blob/custom-type-warnings/proposals/0000-custom-type-warnings.rst

This was extracted from #433, so I suggest that Tom shepherds this one
too.

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

Thanks,
Joachim



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


From mail at joachim-breitner.de  Fri Jan  7 12:15:14 2022
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Fri, 07 Jan 2022 13:15:14 +0100
Subject: [ghc-steering-committee] Please review #448: Modern Scoped Type
 Variables, Shepherd: Arnaud
Message-ID: <7359ee5f8dd75350a41df8c878f1093db0c8714d.camel@joachim-breitner.de>

Dear Committee,

this is your secretary speaking:

We had a bunch of proposals related to scoping and type variables, and
complained about that confusion. Richard built a unified proposal (or
he volunteered), which is now up for consideration:

https://github.com/ghc-proposals/ghc-proposals/pull/448
https://github.com/goldfirere/ghc-proposals/blob/type-variables/proposals/0000-type-variable-scoping.rst

I propose that Arnaud shepherds this.

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

Thanks,
Joachim

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


From trupill at gmail.com  Sat Jan  8 16:26:10 2022
From: trupill at gmail.com (Alejandro Serrano Mena)
Date: Sat, 8 Jan 2022 08:26:10 -0800
Subject: [ghc-steering-committee] Please review #319: NoFallibleDo
 proposal, Shepherd: Eric Seidel
In-Reply-To: <CAHnFXOtXwqgv3H9cVaVvTyuzU_PqDpr+rGQytE0PqJsic4bYPQ@mail.gmail.com>
References: <ec85dbcf4d736b38d80f42b9f402ee5a55eb6e80.camel@joachim-breitner.de>
 <80FD825A-1E63-4807-9DF0-AAF3FBDA4BA5@seidel.io>
 <3c19e58d154f41e2c98979eab095aec2f12094c4.camel@joachim-breitner.de>
 <CAHnFXOug7-WbNhPbTPUAAmnn9KToqKgaCj2m_s=cUuhZOL7SbQ@mail.gmail.com>
 <CAHnFXOvwocM+RD9PnsEHicrbwJbe0grRcGP77CqvJ-Jb6ROz9Q@mail.gmail.com>
 <VI1PR83MB04298CB423A244823A7EF54EAD730@VI1PR83MB0429.EURPRD83.prod.outlook.com>
 <CAHnFXOtEa_zgULprgROvRNY8N=DQ8uqk13oSyjGm3jXpwMDKng@mail.gmail.com>
 <VI1PR83MB042948CB0E42835F84C74A93AD730@VI1PR83MB0429.EURPRD83.prod.outlook.com>
 <CAHnFXOsqJ22PhmS7U1+DUz-navks-FNFdNaeGNUw8+4N077naA@mail.gmail.com>
 <VI1PR83MB042940A6AE90EF6B1B64FB96AD730@VI1PR83MB0429.EURPRD83.prod.outlook.com>
 <CAHnFXOuvnEphLiuHeAceY0vNHs9QnVomHsPZ+VTQnDEpVyPx7A@mail.gmail.com>
 <CAHnFXOsc5goOTwLNV20=RCrmrzyZcj09oa1+JYALMGKCkTYb5g@mail.gmail.com>
 <CAHnFXOt9XrwAyfYp41KUo99nGHp5iQxYfA6haRCceXWHXpzrvA@mail.gmail.com>
 <CAH6fHQnxrKyML0oaqUwYKBR9KTrTSha1MwXdWpVsa9zopiiA1g@mail.gmail.com>
 <CAHnFXOsP+pptTsWcNRNBHch39dvUfM=czBCxEXp8juNnCGXdgA@mail.gmail.com>
 <010f017dca07fbaf-2e06be66-bb15-415c-a09d-0df16c7ede0b-000000@us-east-2.amazonses.com>
 <CAHnFXOtXwqgv3H9cVaVvTyuzU_PqDpr+rGQytE0PqJsic4bYPQ@mail.gmail.com>
Message-ID: <CAHnFXOvZJ8p7WG=U09GvH=_-QS9Hmo0CWfs_9Rxj0T=+19bHxw@mail.gmail.com>

As I see no message on this matter, I’ll go on with the chosen outcome, and
notify the authors about it.

Regards,
Alejandro

El 23 dic 2021 13:51:40, Alejandro Serrano Mena <trupill at gmail.com>
escribió:

> Any further comments? Otherwise my plan is to write back to the authors
> next Wednesday with (C) as the outcome: reject the proposal, and direct the
> authors to proposal #327.
>
> Alejandro
>
> El 17 dic 2021 21:14:20, Richard Eisenberg <lists at richarde.dev> escribió:
>
>> I vote C > B > A, where the further changes requested are to make this
>> decision more locally than at the module level.
>>
>> I will write more directly on the GitHub thread, because I actually think
>> this proposal is essentially subsumed already.
>>
>> Richard
>>
>> On Dec 17, 2021, at 11:55 AM, Alejandro Serrano Mena <trupill at gmail.com>
>> wrote:
>>
>> Thanks for your great summary, Arnaud!
>>
>> These are the possible outcomes I see here: could you add your opinions /
>> vote?
>>
>> A. Accept the proposal as-is,
>> B. Request further changes,
>> C. Reject the proposal and direct the authors towards proposal #327.
>>
>> Regards,
>> Alejandro
>>
>> El 17 dic 2021 14:35:22, "Spiwack, Arnaud" <arnaud.spiwack at tweag.io>
>> escribió:
>>
>>> To recapitulate, this proposal remarks that GHC does a
>>> pre-pattern-matching-exhaustiveness check during the renaming phase to
>>> figure out how whether it needs to insert fail in do-notation
>>> statements of the form C x1… xn <- u. It notes that this precheck is
>>> heuristic, and decides whether a MonadFail constraint will be required
>>> during type checking. It argues that this is bad because you may end up
>>> being asked for a MonadFail constraint when you were careful to write
>>> an exhaustive pattern dependent on a GADT’s argument. And that it is a
>>> fundamental limitation of the current desugaring scheme.
>>>
>>> All these observations look correct (and were validated, in the PR’s
>>> discussion by Sebastian Graf who is quite well-versed in the relevant parts
>>> of the code). The argument that it is a bad thing is relatable (heuristic
>>> in type checking are generally undesirable).
>>>
>>> The proposal’s solution is to add an extension which would switch the
>>> desugaring of C x1… xn <- u statements to never use fail (instead throw
>>> an imprecise exception like regular case expressions). And have
>>> incomplete-pattern-matching warnings. Basically treating <- like a let
>>> in this context. I think.
>>>
>>> The problem I see with this solution is that, while it can be argued
>>> that it would have been desirable to do just that at the inception of
>>> Haskell, it is quite unlikely that we can ever make this the default
>>> (considering how much code exists that rely on the current fail-based
>>> desugaring, and how hard it would be to track). So such an extension would
>>> remain as a switch forever. And I don’t find that it’s particularly worth
>>> it.
>>> ------------------------------
>>>
>>> John Ericsson, who is one of the co-author of the proposal, also wrote a
>>> companion proposal
>>> https://github.com/ghc-proposals/ghc-proposals/pull/327
>>> In this second proposal, he introduces a new statement form for the do
>>> notation: case C x1 … xn <- u of { alts }, such that
>>>
>>> do
>>>   { case C x1 … xn <- u of { alts }
>>>   ; stmts }
>>>
>>> desugars to
>>>
>>> do
>>>   case u of
>>>   { C x1 … xn -> do { stmts }
>>>   ; alts }
>>>
>>> The proposal is still marked as WIP, but the general idea is reasonable.
>>> This is intended as a replacement of the fail desugaring, by inserting
>>> fail (or whatever you see fit) manually: case C x1 … xn <- u of { _ ->
>>> fail }.
>>>
>>> But, from my point of view, this proposal could just as well serve as a
>>> replacement of the NoFailibleDo proposal being discussed in this thread.
>>> Since you could force a fail-free pattern-matching as case C x1 … xn <-
>>> u of {}.
>>>
>>> I personally find this direction much more compelling.
>>>
>>> /Arnaud
>>>
>>> On Fri, Dec 17, 2021 at 10:48 AM Alejandro Serrano Mena <
>>> trupill at gmail.com> wrote:
>>>
>>>> Dear all,
>>>> I missed it back then, but the authors of the “NoFallibleDo” proposal
>>>> have re-submitted to the Committee.
>>>>
>>>> It seems though that we are still in some form of impasse, without
>>>> leaning towards acceptance or rejection. From the discussion, I think that
>>>> the feeling is that this is a desirable feature, but there are different
>>>> opinions about whether this should be per-module or per-block. It would be
>>>> great if all of us would discuss this matter (either here or in the GitHub
>>>> thread) and try to come to a conclusion (or ultimately cast a vote to
>>>> decide).
>>>>
>>>> The proposal itself is about being able to tweak whether an incomplete
>>>> pattern match in a ‘do’ block generates a call to ‘fail’ — as it does now,
>>>> leading to an additional MonadFail constraint — or works as any other
>>>> pattern match — leading to a PatternMatchFail exception when a non-matching
>>>> value comes there.
>>>>
>>>> Once again, I would love to hear your opinions :)
>>>>
>>>> Regards,
>>>> Alejandro
>>>>
>>>>
>>>> El 23 jul 2021 13:40:26, Alejandro Serrano Mena <trupill at gmail.com>
>>>> escribió:
>>>>
>>>>> I’ve been made aware that the “NoFallibleDo” proposal has been
>>>>> re-submitted to the Committee. My current recommendation is “reject”, as
>>>>> outlined in the following comment
>>>>> https://github.com/ghc-proposals/ghc-proposals/pull/319#issuecomment-885580010 (TL;DR,
>>>>> you’d often like to enable this for a particular “do” block, not for an
>>>>> entire file).
>>>>>
>>>>> Regards,
>>>>> Alejandro
>>>>>
>>>>>
>>>>> El 28 jul 2020 11:33:02, Alejandro Serrano Mena <trupill at gmail.com>
>>>>> escribió:
>>>>>
>>>>>> Done. Once again, sorry for the confusion.
>>>>>>
>>>>>> Alejandro
>>>>>>
>>>>>> El mar., 28 jul. 2020 a las 11:30, Simon Peyton Jones (<
>>>>>> simonpj at microsoft.com>) escribió:
>>>>>>
>>>>>>> OK, so to summarise
>>>>>>>
>>>>>>>    - We are waiting for the author
>>>>>>>    - You are encouraging us to comment anyway
>>>>>>>
>>>>>>>
>>>>>>> Correct?  Does the author know this?   Why encourage only us?
>>>>>>> Maybe post on Github to clarify the status, and encourage everyone to
>>>>>>> contribute.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> S
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> *From:* Alejandro Serrano Mena <trupill at gmail.com>
>>>>>>> *Sent:* 28 July 2020 10:25
>>>>>>> *To:* Simon Peyton Jones <simonpj at microsoft.com>
>>>>>>> *Cc:* ghc-steering-committee at haskell.org
>>>>>>> *Subject:* Re: [ghc-steering-committee] Please review #319:
>>>>>>> NoFallibleDo proposal, Shepherd: Eric Seidel
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> I mean the last status, push back to the author for revision.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Alejandro
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> El mar., 28 jul. 2020 a las 11:24, Simon Peyton Jones (<
>>>>>>> simonpj at microsoft.com>) escribió:
>>>>>>>
>>>>>>> So I’m still confused.  “We went back to GIthub”… does that mean
>>>>>>> that we invited the author to revise and resubmit?  I don’t know what else
>>>>>>> “back to github” means.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> If it’s in committee-decision status, then our process says  should
>>>>>>> either accept, reject, or push back to the author for revision, in a timely
>>>>>>> way (guided by the shepherd)
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Simon
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> *From:* Alejandro Serrano Mena <trupill at gmail.com>
>>>>>>> *Sent:* 28 July 2020 10:22
>>>>>>> *To:* Simon Peyton Jones <simonpj at microsoft.com>
>>>>>>> *Cc:* ghc-steering-committee at haskell.org
>>>>>>> *Subject:* Re: [ghc-steering-committee] Please review #319:
>>>>>>> NoFallibleDo proposal, Shepherd: Eric Seidel
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Eric was initially in charge, but I took over his duties. He thought
>>>>>>> that a bit more discussion was needed, something I agree with, so we went
>>>>>>> back to GitHub.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Sorry about the stale status, I feel that my back-and-forth was not
>>>>>>> very clear.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Alejandro
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> El mar., 28 jul. 2020 a las 11:17, Simon Peyton Jones (<
>>>>>>> simonpj at microsoft.com>) escribió:
>>>>>>>
>>>>>>> Alejandro, this one hasn’t been on my radar.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Are you the shepherd?   Have you made a recommendation?  Is the
>>>>>>> proposal in its final form  -- ie having absorbed all discussion etc?
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Simon
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> *From:* ghc-steering-committee <
>>>>>>> ghc-steering-committee-bounces at haskell.org> *On Behalf Of *Alejandro
>>>>>>> Serrano Mena
>>>>>>> *Sent:* 28 July 2020 09:22
>>>>>>> *To:* Joachim Breitner <mail at joachim-breitner.de>
>>>>>>> *Cc:* ghc-steering-committee <ghc-steering-committee at haskell.org>
>>>>>>> *Subject:* Re: [ghc-steering-committee] Please review #319:
>>>>>>> NoFallibleDo proposal, Shepherd: Eric Seidel
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Dear Committee,
>>>>>>>
>>>>>>> I would like to kindly ask for your input in the NoFallibleDo
>>>>>>> proposal -> https://github.com/ghc-proposals/ghc-proposals/pull/319
>>>>>>> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fghc-proposals%2Fghc-proposals%2Fpull%2F319&data=02%7C01%7Csimonpj%40microsoft.com%7C250fdb186a4a41772fe908d832d82b6c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637315251305340206&sdata=DHvjx8qWwjNaa9jn1mdfyBBOqMLJAXdozi3otokRKbk%3D&reserved=0>
>>>>>>>
>>>>>>> This was submitted, then there was some discussion, but the
>>>>>>> conversation has stalled.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Regards,
>>>>>>>
>>>>>>> Alejandro
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> El jue., 14 may. 2020 a las 17:30, Alejandro Serrano Mena (<
>>>>>>> trupill at gmail.com>) escribió:
>>>>>>>
>>>>>>> @Eric congratulations! enjoy! :)
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> @Joachim I can take care of this, I think the direction Eric was
>>>>>>> pushing this is a good one.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> El jue., 14 may. 2020 a las 12:16, Joachim Breitner (<
>>>>>>> mail at joachim-breitner.de>) escribió:
>>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>> Am Mittwoch, den 13.05.2020, 15:19 -0500 schrieb Eric Seidel:
>>>>>>> > My wife and I just checked into the hospital to have our second
>>>>>>> child
>>>>>>>
>>>>>>> Congrats, and all the best!
>>>>>>>
>>>>>>> > , so I’m going to be short on time for committee duties for a few
>>>>>>> > weeks. I think it would be best to reassign this proposal so we
>>>>>>> don’t
>>>>>>> > keep the authors waiting.
>>>>>>>
>>>>>>> Any volunteers?
>>>>>>>
>>>>>>> Cheers,
>>>>>>> Joachim
>>>>>>> --
>>>>>>> Joachim Breitner
>>>>>>>   mail at joachim-breitner.de
>>>>>>>   http://www.joachim-breitner.de/
>>>>>>> <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.joachim-breitner.de%2F&data=02%7C01%7Csimonpj%40microsoft.com%7C250fdb186a4a41772fe908d832d82b6c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637315251305340206&sdata=Xf0HrXmVOPpftJaGUUXQo2ztLCjz1sRhN4nJPP%2Fbshg%3D&reserved=0>
>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> ghc-steering-committee mailing list
>>>>>>> ghc-steering-committee at haskell.org
>>>>>>>
>>>>>>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>>>>>>> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-committee&data=02%7C01%7Csimonpj%40microsoft.com%7C250fdb186a4a41772fe908d832d82b6c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637315251305350196&sdata=P2ISFU6yTiEJkwsF0HmSiGnKUKZCJ0CpLOhGZkDLBpI%3D&reserved=0>
>>>>>>>
>>>>>>> _______________________________________________
>>>> ghc-steering-committee mailing list
>>>> ghc-steering-committee at haskell.org
>>>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>>>>
>>> _______________________________________________
>> ghc-steering-committee mailing list
>> ghc-steering-committee at haskell.org
>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>>
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20220108/faee1eb1/attachment-0001.html>

From trupill at gmail.com  Sat Jan  8 16:32:31 2022
From: trupill at gmail.com (Alejandro Serrano Mena)
Date: Sat, 8 Jan 2022 08:32:31 -0800
Subject: [ghc-steering-committee] #392: Clarify modifiers design
 principle (recommendation: acceptance)
In-Reply-To: <CAHnFXOsgCowHH5q0LJEUyC6mwHE6vO61qVM0JAO15WgednWXrg@mail.gmail.com>
References: <c87b3321b41b7ecbcbf462464e08bdec3e025edf.camel@joachim-breitner.de>
 <CAHnFXOusUdc=H3wQAqdYh=UGrePvjtJKj8be_bZbZBe-TH1VwA@mail.gmail.com>
 <CAH6fHQm1_r7do+bCF4zQHA-L-URyp-0nff8R34LaBiuqLuL_NA@mail.gmail.com>
 <CAH6fHQmFrHn5=JeDaVmEwQjFwuSyUf4hTkP+yP0n0EhfAnVj-g@mail.gmail.com>
 <CAHnFXOs_abSt5oUJOG93bWW3dqXxMswon12CdSgkTkOqAA=K+w@mail.gmail.com>
 <CAH6fHQkTygq4zu1os2oGdunpUOmP9y_YA8zzZ1H0tn2fFFuFzQ@mail.gmail.com>
 <CAHnFXOtCtEfBFFUV-SrqpW8xnGENvT6yytjzoQeRZPGg-ns1JQ@mail.gmail.com>
 <CAHnFXOvQpFmHdjOLW_driaSNesvx15njetWmtL3_7EV8BmeCJA@mail.gmail.com>
 <010f017ae3eba679-439db1cd-5f72-450f-83d3-bd8a2890f5a5-000000@us-east-2.amazonses.com>
 <010f017dca79bbdb-1c52b81a-e020-4971-887b-b1de12e9fba8-000000@us-east-2.amazonses.com>
 <CAHnFXOsgCowHH5q0LJEUyC6mwHE6vO61qVM0JAO15WgednWXrg@mail.gmail.com>
Message-ID: <CAHnFXOs7K1UdKDZG4UNvtPvxVuA3jyMoLJY7LSWXeT9XCmNs2w@mail.gmail.com>

 Dear Committee,
There has been no movement about this proposal (even after the New Year
holidays). If there’s nothing against it, I’ll accept the proposal next
Saturday (so there’s still one week to think about it).

Regards,
Alejandro

El 23 dic 2021 15:41:26, Alejandro Serrano Mena <trupill at gmail.com>
escribió:

> Dear Committee,
>
> As far as I understand, the proposal now allows annotations before
> classes/instances/types/… to appear either in its own line or before the
> thing, by making semicolons optional (which would be introduced during
> parsing if we use a newline).
>
> I think the proposal is ready for acceptance, if no more problems pop up.
>
> Regards,
> Alejandro
>
>
> El 17 dic 2021 23:18:35, Richard Eisenberg <lists at richarde.dev> escribió:
>
>> I've updated the proposal to include an optional semicolon:
>> https://github.com/goldfirere/ghc-proposals/blob/clarify-modifiers/proposals/0370-modifiers.rst
>>
>> Richard
>>
>> On Jul 26, 2021, at 1:45 PM, Richard Eisenberg <lists at richarde.dev>
>> wrote:
>>
>> I like the idea of allowing the semicolon, but I believe it should be
>> optional, as I stated on GitHub:
>> https://github.com/ghc-proposals/ghc-proposals/pull/390#issuecomment-878296938
>>
>> I'm content to add the (optional) semicolon to #392.
>>
>> I don't know about the practical ramifications. Vlad may be best
>> positioned to answer that.
>>
>> Richard
>>
>> On Jul 23, 2021, at 3:53 AM, Alejandro Serrano Mena <trupill at gmail.com>
>> wrote:
>>
>> Dear all,
>> Richard has now updated the proposal, but only Arnaud has commented on
>> it. I think this requires a few more eyes, since it will permeate the
>> language once people start using linear types, and we are already thinking
>> about introducing modifiers in other parts.
>>
>> In fact, I’ve realised that there’s a (grammar) conflict between this
>> proposal and https://github.com/ghc-proposals/ghc-proposals/pull/390 (the
>> fine-grained pragmas for type classes and instances). This proposal defines
>>
>> topdecl ::= {modifier} 'type' simpletype '=' type
>> | {modifier} 'data' [context '=>'] simpletype ['=' constrs] [deriving]
>> | {modifier} 'newtype' [context '=>'] simpletype = newconstr [deriving]
>> | {modifier} 'class' [scontext '=>'] tycls tyvar ['where' cdecls]
>> | {modifier} 'instance' [scontext '=>'] qtycls inst ['where' idecls]
>>
>> But #390 defines (note the ; at the end of the modifiers block):
>>
>> modifiers : {- empty -} | ('%' qtycon)* ';'
>> cl_decl : modifiers 'class' tycl_hdr fds where_cls
>>
>> I guess we should sort this out before accepting any of them.
>>
>> Alejandro
>>
>> El 28 jun 2021 21:26:45, Alejandro Serrano Mena <trupill at gmail.com>
>> escribió:
>>
>>> Richard, will you take care of making those small changes to the
>>> proposal? That way we could mark this as accepted.
>>>
>>> Regards,
>>> Alejandro
>>>
>>> El 28 jun 2021 9:01:28, Spiwack, Arnaud <arnaud.spiwack at tweag.io>
>>> escribió:
>>>
>>>> Yes, I believe that Richard and I are in agreement now. I don't think
>>>> all the conclusions have been added to the proposal yet, though; but
>>>> whatever's left, it's fairly minor.
>>>>
>>>> On Thu, Jun 24, 2021 at 1:29 PM Alejandro Serrano Mena <
>>>> trupill at gmail.com> wrote:
>>>>
>>>>> Dear all,
>>>>> This discussion has been dormant for some time, but it’s time to
>>>>> revive it!
>>>>>
>>>>> Richard, Arnaud, did you manage to reach conclusion about the
>>>>> modification to the proposal?
>>>>>
>>>>> Apart from that, is there any other concern about the proposal? As I
>>>>> said in my original message, this is a very small amendment to an
>>>>> already-existing proposal, so if we accepted the previous one I see no
>>>>> problem in this one. I’ll wait until Richard and Arnaud get back on the
>>>>> issue, and then assume that silence for a week is acceptance.
>>>>>
>>>>> Regards,
>>>>> Alejandro
>>>>>
>>>>> El 11 jun 2021 14:55:41, Spiwack, Arnaud <arnaud.spiwack at tweag.io>
>>>>> escribió:
>>>>>
>>>>>> I think that my discussion with Richard has come to a conclusion (it
>>>>>> should incur a small modification to the proposal).
>>>>>>
>>>>>> It is a very small (amendment to a) proposal, let's find a consensus
>>>>>> on this one quickly.
>>>>>>
>>>>>>
>>>>>> On Wed, May 12, 2021 at 11:26 AM Spiwack, Arnaud <
>>>>>> arnaud.spiwack at tweag.io> wrote:
>>>>>>
>>>>>>> I've commented on the PR [
>>>>>>> https://github.com/ghc-proposals/ghc-proposals/pull/392#pullrequestreview-657652189
>>>>>>> ] the changes on the syntax of lambda expressions are not motivated at all,
>>>>>>> I think at the very least there should be a discussion in the Alternatives
>>>>>>> section.
>>>>>>>
>>>>>>> But mostly, I'm worried about the implications/interactions that
>>>>>>> these changes have with linear types.
>>>>>>>
>>>>>>> (I'll be off for the rest of the week starting tonight, so I'll be
>>>>>>> back on this conversation on Monday, most likely)
>>>>>>>
>>>>>>> On Tue, May 11, 2021 at 10:10 AM Alejandro Serrano Mena <
>>>>>>> trupill at gmail.com> wrote:
>>>>>>>
>>>>>>>> Dear Committee,
>>>>>>>> This proposal seems a natural extension of #370, covering some
>>>>>>>> additional cases (modifiers to classes and other declarations) that we’ve
>>>>>>>> found along the way. My recommendation is acceptance.
>>>>>>>>
>>>>>>>> Regards,
>>>>>>>> Alejandro
>>>>>>>>
>>>>>>>> On 4 May 2021 at 09:41:56, Joachim Breitner <
>>>>>>>> mail at joachim-breitner.de> wrote:
>>>>>>>>
>>>>>>>>> Dear Committe,
>>>>>>>>>
>>>>>>>>> Clarify modifiers design principle
>>>>>>>>> has been proposed by Richard
>>>>>>>>> https://github.com/ghc-proposals/ghc-proposals/pull/392
>>>>>>>>>
>>>>>>>>> This is an amendmend to #370, see the PR description for links to
>>>>>>>>> diffs
>>>>>>>>> etc.
>>>>>>>>>
>>>>>>>>> I propose Alejandro as the shepherd, as he shepherded #370 before.
>>>>>>>>>
>>>>>>>>> Please guide us to a conclusion as outlined in
>>>>>>>>> https://github.com/ghc-proposals/ghc-proposals#committee-process
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>> Joachim
>>>>>>>>> --
>>>>>>>>> --
>>>>>>>>> Joachim Breitner
>>>>>>>>>  mail at joachim-breitner.de
>>>>>>>>>  http://www.joachim-breitner.de/
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> ghc-steering-committee mailing list
>>>>>>>>> ghc-steering-committee at haskell.org
>>>>>>>>>
>>>>>>>>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> ghc-steering-committee mailing list
>>>>>>>> ghc-steering-committee at haskell.org
>>>>>>>>
>>>>>>>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>>>>>>>>
>>>>>>> _______________________________________________
>> ghc-steering-committee mailing list
>> ghc-steering-committee at haskell.org
>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>>
>>
>> _______________________________________________
>> ghc-steering-committee mailing list
>> ghc-steering-committee at haskell.org
>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>>
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20220108/7a065a0b/attachment.html>

From mail at joachim-breitner.de  Mon Jan 10 11:29:38 2022
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Mon, 10 Jan 2022 12:29:38 +0100
Subject: [ghc-steering-committee] Please review #270: Support pun-free code,
 Shepherd: Vitaly
Message-ID: <e6e5f64d71c9f8ef8922cb8199b69d768ba4dd20.camel@joachim-breitner.de>

Dear Committee,

Support pun-free code
has been resubmitted by Artyom Kuznetsov


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

https://github.com/hithroc/ghc-proposals/blob/master/proposals/0000-support-pun-free-code.md

This was previously shepherded by Iavor. I suggest that Vitaly takes over.

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

Thanks,
Joachim




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


From bravit111 at gmail.com  Mon Jan 10 11:42:36 2022
From: bravit111 at gmail.com (Vitaly Bragilevsky)
Date: Mon, 10 Jan 2022 14:42:36 +0300
Subject: [ghc-steering-committee] Please review #270: Support pun-free
 code, Shepherd: Vitaly
In-Reply-To: <e6e5f64d71c9f8ef8922cb8199b69d768ba4dd20.camel@joachim-breitner.de>
References: <e6e5f64d71c9f8ef8922cb8199b69d768ba4dd20.camel@joachim-breitner.de>
Message-ID: <CALpVSmM1kj66OwsW9C0TkuvHEn9OQQkD2Vg3N-NqVHz6JqdiWA@mail.gmail.com>

Thank you, Joachim! I'm on it.

Vitaly

пн, 10 янв. 2022 г. в 14:30, Joachim Breitner <mail at joachim-breitner.de>:

> Dear Committee,
>
> Support pun-free code
> has been resubmitted by Artyom Kuznetsov
>
>
> https://github.com/ghc-proposals/ghc-proposals/pull/270
>
>
> https://github.com/hithroc/ghc-proposals/blob/master/proposals/0000-support-pun-free-code.md
>
> This was previously shepherded by Iavor. I suggest that Vitaly takes over.
>
> Please guide us to a conclusion as outlined in
> https://github.com/ghc-proposals/ghc-proposals#committee-process
>
> Thanks,
> Joachim
>
>
>
>
> --
> Joachim Breitner
>   mail at joachim-breitner.de
>   http://www.joachim-breitner.de/
>
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20220110/342752c5/attachment.html>

From marlowsd at gmail.com  Tue Jan 11 10:28:26 2022
From: marlowsd at gmail.com (Simon Marlow)
Date: Tue, 11 Jan 2022 10:28:26 +0000
Subject: [ghc-steering-committee] Please review #451: Sized literals
	proposal; Shepherd: Simon M
In-Reply-To: <010f017d39ad63fd-db81ebeb-38ee-4325-bbf7-e7e8941d2f79-000000@us-east-2.amazonses.com>
References: <010f017d39ad63fd-db81ebeb-38ee-4325-bbf7-e7e8941d2f79-000000@us-east-2.amazonses.com>
Message-ID: <CANsrgPK94BkPCm4CeoWpjCS+iuqnGtm_XzicTog+U6pSeLCW8g@mail.gmail.com>

Dear committee,

Proposal #451 is about adding syntax for sized unboxed literals. That is,
constants of type `Int8#`, `Word64#` and so on. The proposed syntax is
`123#i8` and `123#u64` for `Int8#` and `Word64#` respectively.

I think we should accept the proposal, but in my opinion this might not be
the best choice of syntax. It was chosen to be consistent with Rust, but
it's a bit of an outlier in Haskell/GHC. I would probably choose `123#Int8`
and `123#Word64`.

Feel free to comment on the github thread
https://github.com/ghc-proposals/ghc-proposals/pull/451

Cheers
Simon

On Fri, 19 Nov 2021 at 19:30, Richard Eisenberg <lists at richarde.dev> wrote:

> Dear Committee,
>
> This is your interim secretary speaking:
>
> Sized literals proposal, proposing syntax for literals for the new sized
> primitive numeric types, has been proposed by Sylvain Henry.
>
> https://github.com/ghc-proposals/ghc-proposals/pull/451
>
> https://github.com/hsyl20/ghc-proposals/blob/sized-literals/proposals/0000-sized-literals.rst
>
> I propose Simon M as the shepherd.
>
> Please guide us to a conclusion as outlined in
> https://github.com/ghc-proposals/ghc-proposals#committee-process
>
> Thanks,
> Richard
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20220111/4b38932a/attachment.html>

From arnaud.spiwack at tweag.io  Thu Jan 13 09:05:07 2022
From: arnaud.spiwack at tweag.io (Spiwack, Arnaud)
Date: Thu, 13 Jan 2022 10:05:07 +0100
Subject: [ghc-steering-committee] Please review #451: Sized literals
 proposal; Shepherd: Simon M
In-Reply-To: <CANsrgPK94BkPCm4CeoWpjCS+iuqnGtm_XzicTog+U6pSeLCW8g@mail.gmail.com>
References: <010f017d39ad63fd-db81ebeb-38ee-4325-bbf7-e7e8941d2f79-000000@us-east-2.amazonses.com>
 <CANsrgPK94BkPCm4CeoWpjCS+iuqnGtm_XzicTog+U6pSeLCW8g@mail.gmail.com>
Message-ID: <CAH6fHQmMLqmEbu_dBfkzwZs7pOAHtRJY7cGtHd6+s06c2QwwWA@mail.gmail.com>

The proposal looks quite sensible to me. On the other hand, I have no
opinion regarding `123#u64` vs `123#Word64`.

On Tue, Jan 11, 2022 at 11:28 AM Simon Marlow <marlowsd at gmail.com> wrote:

> Dear committee,
>
> Proposal #451 is about adding syntax for sized unboxed literals. That is,
> constants of type `Int8#`, `Word64#` and so on. The proposed syntax is
> `123#i8` and `123#u64` for `Int8#` and `Word64#` respectively.
>
> I think we should accept the proposal, but in my opinion this might not be
> the best choice of syntax. It was chosen to be consistent with Rust, but
> it's a bit of an outlier in Haskell/GHC. I would probably choose `123#Int8`
> and `123#Word64`.
>
> Feel free to comment on the github thread
> https://github.com/ghc-proposals/ghc-proposals/pull/451
>
> Cheers
> Simon
>
> On Fri, 19 Nov 2021 at 19:30, Richard Eisenberg <lists at richarde.dev>
> wrote:
>
>> Dear Committee,
>>
>> This is your interim secretary speaking:
>>
>> Sized literals proposal, proposing syntax for literals for the new sized
>> primitive numeric types, has been proposed by Sylvain Henry.
>>
>> https://github.com/ghc-proposals/ghc-proposals/pull/451
>>
>> https://github.com/hsyl20/ghc-proposals/blob/sized-literals/proposals/0000-sized-literals.rst
>>
>> I propose Simon M as the shepherd.
>>
>> Please guide us to a conclusion as outlined in
>> https://github.com/ghc-proposals/ghc-proposals#committee-process
>>
>> Thanks,
>> Richard
>
> _______________________________________________
> 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/20220113/980f4795/attachment.html>

From i.am.tom.harding at gmail.com  Thu Jan 13 16:19:16 2022
From: i.am.tom.harding at gmail.com (Tom Harding)
Date: Thu, 13 Jan 2022 16:19:16 +0000
Subject: [ghc-steering-committee] Please review: #454 Custom type warnings
Message-ID: <F33133C3-FF32-42B2-ADC7-E02F202277D4@gmail.com>

Hi all,

As Joachim noted, #454 <https://github.com/ghc-proposals/ghc-proposals/pull/454> is extracted from Adam’s previous efforts with the Unsatisfiable constraint <https://github.com/ghc-proposals/ghc-proposals/pull/433> proposal (which has since been accepted). In short, it covers an interface for custom warnings, and I can already think of plenty of ways I’d use it. I’d therefore like to recommend acceptance, and discuss any issues or changes.

Thanks,
Tom
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20220113/67aa01af/attachment.html>

From lists at richarde.dev  Thu Jan 13 21:47:32 2022
From: lists at richarde.dev (Richard Eisenberg)
Date: Thu, 13 Jan 2022 21:47:32 +0000
Subject: [ghc-steering-committee] Please review: #454 Custom type
	warnings
In-Reply-To: <F33133C3-FF32-42B2-ADC7-E02F202277D4@gmail.com>
References: <F33133C3-FF32-42B2-ADC7-E02F202277D4@gmail.com>
Message-ID: <010f017e5569032d-97a2902a-b938-4137-b9a7-70a1ead09852-000000@us-east-2.amazonses.com>

I vote to accept.

Thanks,
Richard

> On Jan 13, 2022, at 11:19 AM, Tom Harding <i.am.tom.harding at gmail.com> wrote:
> 
> Hi all,
> 
> As Joachim noted, #454 <https://github.com/ghc-proposals/ghc-proposals/pull/454> is extracted from Adam’s previous efforts with the Unsatisfiable constraint <https://github.com/ghc-proposals/ghc-proposals/pull/433> proposal (which has since been accepted). In short, it covers an interface for custom warnings, and I can already think of plenty of ways I’d use it. I’d therefore like to recommend acceptance, and discuss any issues or changes.
> 
> Thanks,
> Tom
> _______________________________________________
> 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/20220113/aabd1597/attachment.html>

From vlad.z.4096 at gmail.com  Thu Jan 13 21:56:26 2022
From: vlad.z.4096 at gmail.com (Vladislav Zavialov (int-index))
Date: Fri, 14 Jan 2022 00:56:26 +0300
Subject: [ghc-steering-committee] Please review: #454 Custom type
	warnings
In-Reply-To: <010f017e5569032d-97a2902a-b938-4137-b9a7-70a1ead09852-000000@us-east-2.amazonses.com>
References: <F33133C3-FF32-42B2-ADC7-E02F202277D4@gmail.com>
 <010f017e5569032d-97a2902a-b938-4137-b9a7-70a1ead09852-000000@us-east-2.amazonses.com>
Message-ID: <53E9ABAB-B660-477A-83AE-9D3BD6B0FAB7@gmail.com>

Can we guarantee erasure? Is `Warning flag msg => t` the same operationally as just `t`?

The proposal does not say that. And it’s not what I would’ve expected from a constraint. Yet it’s something I expect from a warning.

I am not comfortable with a design where adding a custom warning, the purpose of which is to improve developer experience, comes at a cost of potential performance regression.

This isn’t a trade off that users of GHC should be facing.

- Vlad

> On 14 Jan 2022, at 00:47, Richard Eisenberg <lists at richarde.dev> wrote:
> 
> I vote to accept.
> 
> Thanks,
> Richard
> 
>> On Jan 13, 2022, at 11:19 AM, Tom Harding <i.am.tom.harding at gmail.com> wrote:
>> 
>> Hi all,
>> 
>> As Joachim noted, #454 is extracted from Adam’s previous efforts with the Unsatisfiable constraint proposal (which has since been accepted). In short, it covers an interface for custom warnings, and I can already think of plenty of ways I’d use it. I’d therefore like to recommend acceptance, and discuss any issues or changes.
>> 
>> Thanks,
>> Tom
>> _______________________________________________
>> ghc-steering-committee mailing list
>> ghc-steering-committee at haskell.org
>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
> 
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee


From lists at richarde.dev  Thu Jan 13 22:50:59 2022
From: lists at richarde.dev (Richard Eisenberg)
Date: Thu, 13 Jan 2022 22:50:59 +0000
Subject: [ghc-steering-committee] Please review: #454 Custom type
	warnings
In-Reply-To: <53E9ABAB-B660-477A-83AE-9D3BD6B0FAB7@gmail.com>
References: <F33133C3-FF32-42B2-ADC7-E02F202277D4@gmail.com>
 <010f017e5569032d-97a2902a-b938-4137-b9a7-70a1ead09852-000000@us-east-2.amazonses.com>
 <53E9ABAB-B660-477A-83AE-9D3BD6B0FAB7@gmail.com>
Message-ID: <010f017e55a3195b-b551e32d-6ee6-4a12-86f8-92d3a8085ade-000000@us-east-2.amazonses.com>

That's a really good point. Do you want to raise it on the PR?

Richard

> On Jan 13, 2022, at 4:56 PM, Vladislav Zavialov (int-index) <vlad.z.4096 at gmail.com> wrote:
> 
> Can we guarantee erasure? Is `Warning flag msg => t` the same operationally as just `t`?
> 
> The proposal does not say that. And it’s not what I would’ve expected from a constraint. Yet it’s something I expect from a warning.
> 
> I am not comfortable with a design where adding a custom warning, the purpose of which is to improve developer experience, comes at a cost of potential performance regression.
> 
> This isn’t a trade off that users of GHC should be facing.
> 
> - Vlad
> 
>> On 14 Jan 2022, at 00:47, Richard Eisenberg <lists at richarde.dev> wrote:
>> 
>> I vote to accept.
>> 
>> Thanks,
>> Richard
>> 
>>> On Jan 13, 2022, at 11:19 AM, Tom Harding <i.am.tom.harding at gmail.com> wrote:
>>> 
>>> Hi all,
>>> 
>>> As Joachim noted, #454 is extracted from Adam’s previous efforts with the Unsatisfiable constraint proposal (which has since been accepted). In short, it covers an interface for custom warnings, and I can already think of plenty of ways I’d use it. I’d therefore like to recommend acceptance, and discuss any issues or changes.
>>> 
>>> Thanks,
>>> Tom
>>> _______________________________________________
>>> ghc-steering-committee mailing list
>>> ghc-steering-committee at haskell.org
>>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>> 
>> _______________________________________________
>> ghc-steering-committee mailing list
>> ghc-steering-committee at haskell.org
>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
> 


From simon.peytonjones at gmail.com  Fri Jan 14 09:36:02 2022
From: simon.peytonjones at gmail.com (Simon Peyton Jones)
Date: Fri, 14 Jan 2022 09:36:02 +0000
Subject: [ghc-steering-committee] Please review #452: Articulate
 principles for GHC evolution; Shepherd: Simon PJ
In-Reply-To: <CAJKmMz8vn2AcoKMuD1a8mAG0h7TLPJrj4EKWWAg40kENL0V2Hg@mail.gmail.com>
References: <010f017d39a6cada-4348acaa-e469-432b-a4c3-7a2e1c23b6ff-000000@us-east-2.amazonses.com>
 <CAJKmMz8vn2AcoKMuD1a8mAG0h7TLPJrj4EKWWAg40kENL0V2Hg@mail.gmail.com>
Message-ID: <CAJKmMz-OJViXa8_1sSw8G6U1OF4nAiz8As-XXK62LExwcFy4HQ@mail.gmail.com>

I have had only positive reactions to this, so I declare it accepted.

Joachim, could you merge it?

Sorry to have been slow -- I intended to do this before Christmas.

best wishes

Simon

On Fri, 10 Dec 2021 at 16:51, Simon Peyton Jones <
simon.peytonjones at gmail.com> wrote:

> Dear Steering Committee
>
> I'd like to propose that we accept Proposal #452: Articulate principles
> for GHC evolution
>
>    - Discussion: https://github.com/ghc-proposals/ghc-proposals/pull/452
>    - Proposal:
>    https://github.com/goldfirere/ghc-proposals/blob/principles/principles.rst
>
> Remember, we are not debating the principles themselves, all of which are
> embodied in earlier proposals.  Rather we are discussing
>
>    - the usefulness of having  a place where we articulate the
>    principles, and
>    - a process for updating them over time, namely by PRs against this
>    proposal
>
> The idea is that the latest incarnation of the proposal is always the
> current set of agreed principles.
>
> Please respond by Friday 17 Dec. Because it seems uncontroversial, I'll
> take silence as assent, unless a big discussion arises.
>
> Thanks
>
> Simon
>
> On Fri, 19 Nov 2021 at 19:23, Richard Eisenberg <lists at richarde.dev>
> wrote:
>
>> Dear Committee,
>>
>> This is your interim secretary speaking:
>>
>> Articulate principles for GHC evolution, proposing a new "principles"
>> document to be added to the proposals repo, has been proposed by me.
>> https://github.com/ghc-proposals/ghc-proposals/pull/452
>> https://github.com/goldfirere/ghc-proposals/blob/principles/principles.rst
>>
>> I propose Simon PJ as the shepherd, as this is something of a
>> meta-proposal, appropriate for shepherding by our chair.
>>
>> Please guide us to a conclusion as outlined in
>> https://github.com/ghc-proposals/ghc-proposals#committee-process
>>
>> Thanks,
>> Richard
>> _______________________________________________
>> 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/20220114/0dde4016/attachment-0001.html>

From mail at joachim-breitner.de  Fri Jan 14 15:20:56 2022
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Fri, 14 Jan 2022 16:20:56 +0100
Subject: [ghc-steering-committee] Please review #452: Articulate
 principles for GHC evolution; Shepherd: Simon PJ
In-Reply-To: <CAJKmMz-OJViXa8_1sSw8G6U1OF4nAiz8As-XXK62LExwcFy4HQ@mail.gmail.com>
References: <010f017d39a6cada-4348acaa-e469-432b-a4c3-7a2e1c23b6ff-000000@us-east-2.amazonses.com>
 <CAJKmMz8vn2AcoKMuD1a8mAG0h7TLPJrj4EKWWAg40kENL0V2Hg@mail.gmail.com>
 <CAJKmMz-OJViXa8_1sSw8G6U1OF4nAiz8As-XXK62LExwcFy4HQ@mail.gmail.com>
Message-ID: <667f47238f0eb9366f8bba67f6849ce2fd95931f.camel@joachim-breitner.de>

Am Freitag, dem 14.01.2022 um 09:36 +0000 schrieb Simon Peyton Jones:
> Joachim, could you merge it?

✓

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


From trupill at gmail.com  Thu Jan 27 13:28:59 2022
From: trupill at gmail.com (Alejandro Serrano Mena)
Date: Thu, 27 Jan 2022 13:28:59 +0000
Subject: [ghc-steering-committee] #392: Clarify modifiers design
 principle (recommendation: acceptance)
In-Reply-To: <CAHnFXOs7K1UdKDZG4UNvtPvxVuA3jyMoLJY7LSWXeT9XCmNs2w@mail.gmail.com>
References: <c87b3321b41b7ecbcbf462464e08bdec3e025edf.camel@joachim-breitner.de>
 <CAHnFXOusUdc=H3wQAqdYh=UGrePvjtJKj8be_bZbZBe-TH1VwA@mail.gmail.com>
 <CAH6fHQm1_r7do+bCF4zQHA-L-URyp-0nff8R34LaBiuqLuL_NA@mail.gmail.com>
 <CAH6fHQmFrHn5=JeDaVmEwQjFwuSyUf4hTkP+yP0n0EhfAnVj-g@mail.gmail.com>
 <CAHnFXOs_abSt5oUJOG93bWW3dqXxMswon12CdSgkTkOqAA=K+w@mail.gmail.com>
 <CAH6fHQkTygq4zu1os2oGdunpUOmP9y_YA8zzZ1H0tn2fFFuFzQ@mail.gmail.com>
 <CAHnFXOtCtEfBFFUV-SrqpW8xnGENvT6yytjzoQeRZPGg-ns1JQ@mail.gmail.com>
 <CAHnFXOvQpFmHdjOLW_driaSNesvx15njetWmtL3_7EV8BmeCJA@mail.gmail.com>
 <010f017ae3eba679-439db1cd-5f72-450f-83d3-bd8a2890f5a5-000000@us-east-2.amazonses.com>
 <010f017dca79bbdb-1c52b81a-e020-4971-887b-b1de12e9fba8-000000@us-east-2.amazonses.com>
 <CAHnFXOsgCowHH5q0LJEUyC6mwHE6vO61qVM0JAO15WgednWXrg@mail.gmail.com>
 <CAHnFXOs7K1UdKDZG4UNvtPvxVuA3jyMoLJY7LSWXeT9XCmNs2w@mail.gmail.com>
Message-ID: <CAHnFXOtqJj2pDL830DRDnrVsRHc1yyd5ye80mRLTkSQokqtidg@mail.gmail.com>

 Two weeks instead of one have passed, and nobody has raised objections.

@Joachim: should I merge it, or are you the one doing that?

Regards,
Alejandro

El 8 ene 2022 17:32:31, Alejandro Serrano Mena <trupill at gmail.com> escribió:

> Dear Committee,
> There has been no movement about this proposal (even after the New Year
> holidays). If there’s nothing against it, I’ll accept the proposal next
> Saturday (so there’s still one week to think about it).
>
> Regards,
> Alejandro
>
> El 23 dic 2021 15:41:26, Alejandro Serrano Mena <trupill at gmail.com>
> escribió:
>
>> Dear Committee,
>>
>> As far as I understand, the proposal now allows annotations before
>> classes/instances/types/… to appear either in its own line or before the
>> thing, by making semicolons optional (which would be introduced during
>> parsing if we use a newline).
>>
>> I think the proposal is ready for acceptance, if no more problems pop up.
>>
>> Regards,
>> Alejandro
>>
>>
>> El 17 dic 2021 23:18:35, Richard Eisenberg <lists at richarde.dev> escribió:
>>
>>> I've updated the proposal to include an optional semicolon:
>>> https://github.com/goldfirere/ghc-proposals/blob/clarify-modifiers/proposals/0370-modifiers.rst
>>>
>>> Richard
>>>
>>> On Jul 26, 2021, at 1:45 PM, Richard Eisenberg <lists at richarde.dev>
>>> wrote:
>>>
>>> I like the idea of allowing the semicolon, but I believe it should be
>>> optional, as I stated on GitHub:
>>> https://github.com/ghc-proposals/ghc-proposals/pull/390#issuecomment-878296938
>>>
>>> I'm content to add the (optional) semicolon to #392.
>>>
>>> I don't know about the practical ramifications. Vlad may be best
>>> positioned to answer that.
>>>
>>> Richard
>>>
>>> On Jul 23, 2021, at 3:53 AM, Alejandro Serrano Mena <trupill at gmail.com>
>>> wrote:
>>>
>>> Dear all,
>>> Richard has now updated the proposal, but only Arnaud has commented on
>>> it. I think this requires a few more eyes, since it will permeate the
>>> language once people start using linear types, and we are already thinking
>>> about introducing modifiers in other parts.
>>>
>>> In fact, I’ve realised that there’s a (grammar) conflict between this
>>> proposal and https://github.com/ghc-proposals/ghc-proposals/pull/390 (the
>>> fine-grained pragmas for type classes and instances). This proposal defines
>>>
>>> topdecl ::= {modifier} 'type' simpletype '=' type
>>> | {modifier} 'data' [context '=>'] simpletype ['=' constrs] [deriving]
>>> | {modifier} 'newtype' [context '=>'] simpletype = newconstr [deriving]
>>> | {modifier} 'class' [scontext '=>'] tycls tyvar ['where' cdecls]
>>> | {modifier} 'instance' [scontext '=>'] qtycls inst ['where' idecls]
>>>
>>> But #390 defines (note the ; at the end of the modifiers block):
>>>
>>> modifiers : {- empty -} | ('%' qtycon)* ';'
>>> cl_decl : modifiers 'class' tycl_hdr fds where_cls
>>>
>>> I guess we should sort this out before accepting any of them.
>>>
>>> Alejandro
>>>
>>> El 28 jun 2021 21:26:45, Alejandro Serrano Mena <trupill at gmail.com>
>>> escribió:
>>>
>>>> Richard, will you take care of making those small changes to the
>>>> proposal? That way we could mark this as accepted.
>>>>
>>>> Regards,
>>>> Alejandro
>>>>
>>>> El 28 jun 2021 9:01:28, Spiwack, Arnaud <arnaud.spiwack at tweag.io>
>>>> escribió:
>>>>
>>>>> Yes, I believe that Richard and I are in agreement now. I don't think
>>>>> all the conclusions have been added to the proposal yet, though; but
>>>>> whatever's left, it's fairly minor.
>>>>>
>>>>> On Thu, Jun 24, 2021 at 1:29 PM Alejandro Serrano Mena <
>>>>> trupill at gmail.com> wrote:
>>>>>
>>>>>> Dear all,
>>>>>> This discussion has been dormant for some time, but it’s time to
>>>>>> revive it!
>>>>>>
>>>>>> Richard, Arnaud, did you manage to reach conclusion about the
>>>>>> modification to the proposal?
>>>>>>
>>>>>> Apart from that, is there any other concern about the proposal? As I
>>>>>> said in my original message, this is a very small amendment to an
>>>>>> already-existing proposal, so if we accepted the previous one I see no
>>>>>> problem in this one. I’ll wait until Richard and Arnaud get back on the
>>>>>> issue, and then assume that silence for a week is acceptance.
>>>>>>
>>>>>> Regards,
>>>>>> Alejandro
>>>>>>
>>>>>> El 11 jun 2021 14:55:41, Spiwack, Arnaud <arnaud.spiwack at tweag.io>
>>>>>> escribió:
>>>>>>
>>>>>>> I think that my discussion with Richard has come to a conclusion (it
>>>>>>> should incur a small modification to the proposal).
>>>>>>>
>>>>>>> It is a very small (amendment to a) proposal, let's find a consensus
>>>>>>> on this one quickly.
>>>>>>>
>>>>>>>
>>>>>>> On Wed, May 12, 2021 at 11:26 AM Spiwack, Arnaud <
>>>>>>> arnaud.spiwack at tweag.io> wrote:
>>>>>>>
>>>>>>>> I've commented on the PR [
>>>>>>>> https://github.com/ghc-proposals/ghc-proposals/pull/392#pullrequestreview-657652189
>>>>>>>> ] the changes on the syntax of lambda expressions are not motivated at all,
>>>>>>>> I think at the very least there should be a discussion in the Alternatives
>>>>>>>> section.
>>>>>>>>
>>>>>>>> But mostly, I'm worried about the implications/interactions that
>>>>>>>> these changes have with linear types.
>>>>>>>>
>>>>>>>> (I'll be off for the rest of the week starting tonight, so I'll be
>>>>>>>> back on this conversation on Monday, most likely)
>>>>>>>>
>>>>>>>> On Tue, May 11, 2021 at 10:10 AM Alejandro Serrano Mena <
>>>>>>>> trupill at gmail.com> wrote:
>>>>>>>>
>>>>>>>>> Dear Committee,
>>>>>>>>> This proposal seems a natural extension of #370, covering some
>>>>>>>>> additional cases (modifiers to classes and other declarations) that we’ve
>>>>>>>>> found along the way. My recommendation is acceptance.
>>>>>>>>>
>>>>>>>>> Regards,
>>>>>>>>> Alejandro
>>>>>>>>>
>>>>>>>>> On 4 May 2021 at 09:41:56, Joachim Breitner <
>>>>>>>>> mail at joachim-breitner.de> wrote:
>>>>>>>>>
>>>>>>>>>> Dear Committe,
>>>>>>>>>>
>>>>>>>>>> Clarify modifiers design principle
>>>>>>>>>> has been proposed by Richard
>>>>>>>>>> https://github.com/ghc-proposals/ghc-proposals/pull/392
>>>>>>>>>>
>>>>>>>>>> This is an amendmend to #370, see the PR description for links to
>>>>>>>>>> diffs
>>>>>>>>>> etc.
>>>>>>>>>>
>>>>>>>>>> I propose Alejandro as the shepherd, as he shepherded #370 before.
>>>>>>>>>>
>>>>>>>>>> Please guide us to a conclusion as outlined in
>>>>>>>>>> https://github.com/ghc-proposals/ghc-proposals#committee-process
>>>>>>>>>>
>>>>>>>>>> Thanks,
>>>>>>>>>> Joachim
>>>>>>>>>> --
>>>>>>>>>> --
>>>>>>>>>> Joachim Breitner
>>>>>>>>>>  mail at joachim-breitner.de
>>>>>>>>>>  http://www.joachim-breitner.de/
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> _______________________________________________
>>>>>>>>>> ghc-steering-committee mailing list
>>>>>>>>>> ghc-steering-committee at haskell.org
>>>>>>>>>>
>>>>>>>>>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> ghc-steering-committee mailing list
>>>>>>>>> ghc-steering-committee at haskell.org
>>>>>>>>>
>>>>>>>>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>>>>>>>>>
>>>>>>>> _______________________________________________
>>> ghc-steering-committee mailing list
>>> ghc-steering-committee at haskell.org
>>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>>>
>>>
>>> _______________________________________________
>>> ghc-steering-committee mailing list
>>> ghc-steering-committee at haskell.org
>>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>>>
>>>
>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20220127/d19a3166/attachment.html>

From mail at joachim-breitner.de  Thu Jan 27 19:34:16 2022
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Thu, 27 Jan 2022 20:34:16 +0100
Subject: [ghc-steering-committee] #392: Clarify modifiers design
 principle (recommendation: acceptance)
In-Reply-To: <CAHnFXOtqJj2pDL830DRDnrVsRHc1yyd5ye80mRLTkSQokqtidg@mail.gmail.com>
References: <c87b3321b41b7ecbcbf462464e08bdec3e025edf.camel@joachim-breitner.de>
 <CAHnFXOusUdc=H3wQAqdYh=UGrePvjtJKj8be_bZbZBe-TH1VwA@mail.gmail.com>
 <CAH6fHQm1_r7do+bCF4zQHA-L-URyp-0nff8R34LaBiuqLuL_NA@mail.gmail.com>
 <CAH6fHQmFrHn5=JeDaVmEwQjFwuSyUf4hTkP+yP0n0EhfAnVj-g@mail.gmail.com>
 <CAHnFXOs_abSt5oUJOG93bWW3dqXxMswon12CdSgkTkOqAA=K+w@mail.gmail.com>
 <CAH6fHQkTygq4zu1os2oGdunpUOmP9y_YA8zzZ1H0tn2fFFuFzQ@mail.gmail.com>
 <CAHnFXOtCtEfBFFUV-SrqpW8xnGENvT6yytjzoQeRZPGg-ns1JQ@mail.gmail.com>
 <CAHnFXOvQpFmHdjOLW_driaSNesvx15njetWmtL3_7EV8BmeCJA@mail.gmail.com>
 <010f017ae3eba679-439db1cd-5f72-450f-83d3-bd8a2890f5a5-000000@us-east-2.amazonses.com>
 <010f017dca79bbdb-1c52b81a-e020-4971-887b-b1de12e9fba8-000000@us-east-2.amazonses.com>
 <CAHnFXOsgCowHH5q0LJEUyC6mwHE6vO61qVM0JAO15WgednWXrg@mail.gmail.com>
 <CAHnFXOs7K1UdKDZG4UNvtPvxVuA3jyMoLJY7LSWXeT9XCmNs2w@mail.gmail.com>
 <CAHnFXOtqJj2pDL830DRDnrVsRHc1yyd5ye80mRLTkSQokqtidg@mail.gmail.com>
Message-ID: <619ca8b43edce0415a1de0c833fb4f2f99807709.camel@joachim-breitner.de>

Hi,

Am Donnerstag, dem 27.01.2022 um 13:28 +0000 schrieb Alejandro Serrano
Mena:
>  Two weeks instead of one have passed, and nobody has raised
> objections.
> 
> @Joachim: should I merge it, or are you the one doing that?
> 

just done.

Looks like you have successfully concluded the two PRs that were on
your plate when you announced your resignation. Is that still your plan
and we have to bid you farewell now?

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


From trupill at gmail.com  Fri Jan 28 13:07:24 2022
From: trupill at gmail.com (Alejandro Serrano Mena)
Date: Fri, 28 Jan 2022 05:07:24 -0800
Subject: [ghc-steering-committee] #392: Clarify modifiers design
 principle (recommendation: acceptance)
In-Reply-To: <619ca8b43edce0415a1de0c833fb4f2f99807709.camel@joachim-breitner.de>
References: <c87b3321b41b7ecbcbf462464e08bdec3e025edf.camel@joachim-breitner.de>
 <CAHnFXOusUdc=H3wQAqdYh=UGrePvjtJKj8be_bZbZBe-TH1VwA@mail.gmail.com>
 <CAH6fHQm1_r7do+bCF4zQHA-L-URyp-0nff8R34LaBiuqLuL_NA@mail.gmail.com>
 <CAH6fHQmFrHn5=JeDaVmEwQjFwuSyUf4hTkP+yP0n0EhfAnVj-g@mail.gmail.com>
 <CAHnFXOs_abSt5oUJOG93bWW3dqXxMswon12CdSgkTkOqAA=K+w@mail.gmail.com>
 <CAH6fHQkTygq4zu1os2oGdunpUOmP9y_YA8zzZ1H0tn2fFFuFzQ@mail.gmail.com>
 <CAHnFXOtCtEfBFFUV-SrqpW8xnGENvT6yytjzoQeRZPGg-ns1JQ@mail.gmail.com>
 <CAHnFXOvQpFmHdjOLW_driaSNesvx15njetWmtL3_7EV8BmeCJA@mail.gmail.com>
 <010f017ae3eba679-439db1cd-5f72-450f-83d3-bd8a2890f5a5-000000@us-east-2.amazonses.com>
 <010f017dca79bbdb-1c52b81a-e020-4971-887b-b1de12e9fba8-000000@us-east-2.amazonses.com>
 <CAHnFXOsgCowHH5q0LJEUyC6mwHE6vO61qVM0JAO15WgednWXrg@mail.gmail.com>
 <CAHnFXOs7K1UdKDZG4UNvtPvxVuA3jyMoLJY7LSWXeT9XCmNs2w@mail.gmail.com>
 <CAHnFXOtqJj2pDL830DRDnrVsRHc1yyd5ye80mRLTkSQokqtidg@mail.gmail.com>
 <619ca8b43edce0415a1de0c833fb4f2f99807709.camel@joachim-breitner.de>
Message-ID: <CAHnFXOsJCBL0HTf0UYBO-he7Z5CjX+weFthOFPfckxD24EufRg@mail.gmail.com>

El 27 ene 2022 20:34:16, Joachim Breitner <mail at joachim-breitner.de>
escribió:

> Hi,
>
> Am Donnerstag, dem 27.01.2022 um 13:28 +0000 schrieb Alejandro Serrano
> Mena:
>
>  Two weeks instead of one have passed, and nobody has raised
>
> objections.
>
>
> @Joachim: should I merge it, or are you the one doing that?
>
>
>
> just done.
>
> Looks like you have successfully concluded the two PRs that were on
> your plate when you announced your resignation. Is that still your plan
> and we have to bid you farewell now?
>

Unfortunately the world hasn’t changed enough in this time for me to have
the required free time, so I still think that’s the best outcome for me.
But hey, maybe in a few years time I’ll be asking to be part of the
Committee again!

Regards,
Alejandro


> 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/20220128/b804e050/attachment.html>

From mail at joachim-breitner.de  Sat Jan 29 11:25:56 2022
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Sat, 29 Jan 2022 12:25:56 +0100
Subject: [ghc-steering-committee] Farewell Alejandro
Message-ID: <aba0bde2563b11787ccfe6930c4120f3f2c7b15f.camel@joachim-breitner.de>

Hello all,

Alejandro has stepped down from the committee, after having finished
the PRs assigned to him (very honorable).

Thanks Alejandro for two years of service, shepherding 6 proposals,
four of which have been accepted, and your contributions to all the
other discussions.

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


From mail at joachim-breitner.de  Sat Jan 29 11:32:27 2022
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Sat, 29 Jan 2022 12:32:27 +0100
Subject: [ghc-steering-committee] Call for nominations coming up
Message-ID: <fa557407b10c130f9c443b4f4629497579548725.camel@joachim-breitner.de>

Dear Committee,

after Alejandro’s resignation I was checking if we have to do a new
call for nominations, and at first I thought no, because we are still
9, but then I noticed that we actually missed the end of Vitaly and
Eric’s three year terms, which started in Sep 2018 (time flies).

So as per our bylaws, I should put out a call for nominations. Vitaly
and Eric are of course welcome (and encouraged, if I may add) to re-
nominated themselves. Or each other, if they like :-)

Cheers,
Joachim

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


From mail at joachim-breitner.de  Sat Jan 29 11:36:59 2022
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Sat, 29 Jan 2022 12:36:59 +0100
Subject: [ghc-steering-committee] Request for Nominations to the GHC
	Steering Committee
Message-ID: <e9780b87201cc2ea04c89dc9069c9c54e7b95fb2.camel@joachim-breitner.de>

Dear Haskell community,

the GHC Steering committee is seeking nominations for at least two new
members.

The committee scrutinizes, nitpicks, improves, weights and eventually
accepts or rejects proposals that extend or change the language
supported by GHC and other (public-facing) aspects of GHC.
Our processes are described at
   https://github.com/ghc-proposals/ghc-proposals
which is also the GitHub repository where proposals are proposed. In
particular, please have a look at the bylaws at
   https://github.com/ghc-proposals/ghc-proposals/blob/master/committee.rst


We are looking for a member who has the ability 
 * to understand such language extension proposals,
 * to find holes and missing corner cases in the specifications,
 * foresee the interaction with other language features and 
   specifications,
 * comment constructively and improve the proposals,
 * judge the cost/benefit ratio and
 * finally come to a justifiable conclusion.

We look for committee members who have some of these properties:
 * have substantial experience in writing Haskell applications or
   libraries, which they can use to inform judgements about the
   utility or otherwise of proposed features,
 * have made active contributions to the Haskell community, for
   some time,
 * have expertise in language design and implementation, in either
   Haskell or related languages, which they can share with us.

The committee’s work requires a small, but non-trivial amount of time,
especially when you are assigned a proposal for shepherding. We
estimate the workload to be around 2 hours per week, and our process
works best if members usually respond to technical emails within 1-2
weeks (within days is even better). Please keep that in mind if your
email inbox is already overflowing.

There is no shortage of people who are eager to get fancy new
features into the language, both in the committee and the wider
community. But each new feature imposes a cost, to implement, to learn,
(particularly) through its unexpected interaction with other features.
We need to strike a balance, one that encourages innovation (as GHC
always has) while still making Haskell attractive for real-world
production use and for teaching. We therefore explicitly invite
“conservative” members of the community to join the committee.

To make a nomination, please send an email to me (as the committee
secretary) at mail at joachim-breitner.de until February 11th. I will
distribute the nominations among the committee, and we will keep the
nominations and our deliberations private.

We explicitly encourage self-nominations. You can nominate others, but
please obtain their explicit consent to do so. (We don’t want to choose
someone who turns out to be unable to serve.)

On behalf of the committee,
Joachim Breitner

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


From bravit111 at gmail.com  Sat Jan 29 15:41:05 2022
From: bravit111 at gmail.com (Vitaly Bragilevsky)
Date: Sat, 29 Jan 2022 18:41:05 +0300
Subject: [ghc-steering-committee] #270: Support pun-free code,
	recommendation: accept
Message-ID: <CALpVSmPE8waLOVf5NZeRWAqwH-U6EGFTOTKDffB78jAKVvi7GA@mail.gmail.com>

Dear Committee,

Proposal #270 "Support pun-free code" has been resubmitted by Artyom Kuznetsov.

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

https://github.com/hithroc/ghc-proposals/blob/master/proposals/0000-support-pun-free-code.md

This proposal was heavily revised since Iavor recommended rejection.
As of now, it is quite thin suggesting just a couple of things:
- warnings for the code with panning (understood as using same names
for both types and values)
- a syntax change for import declarations to reflect which names
(types or values) are actually imported when importing from libraries
relied on punning.

The first change promotes a new style of writing Haskell code without
distinguishing types and values and having a single unified namespace.
We are already on that road anyway and I don't see any reason not to
support this.

The second change allows using an old style with punning. It could
lead to doubling import declarations, but I don't think that this is
really a problem.

I think the proposal is mature enough so I recommend acceptance.

We can also decide on the actual word used in import declarations
(data, value, or pattern). I personally prefer value, but I don't see
this issue as something important.

Vitaly

From lists at richarde.dev  Sun Jan 30 01:41:38 2022
From: lists at richarde.dev (Richard Eisenberg)
Date: Sun, 30 Jan 2022 01:41:38 +0000
Subject: [ghc-steering-committee] #270: Support pun-free code,
 recommendation: accept
In-Reply-To: <CALpVSmPE8waLOVf5NZeRWAqwH-U6EGFTOTKDffB78jAKVvi7GA@mail.gmail.com>
References: <CALpVSmPE8waLOVf5NZeRWAqwH-U6EGFTOTKDffB78jAKVvi7GA@mail.gmail.com>
Message-ID: <010f017ea8a51730-ddfba576-ddab-4fa7-966d-3af0e6949571-000000@us-east-2.amazonses.com>

I support acceptance, but only if #475 <https://github.com/goldfirere/ghc-proposals/blob/tuple-syntax/proposals/0000-tuple-syntax.rst> is also accepted.

The current proposal (#270) affects the use of list and tuple syntax, as this syntax is punned between the term- and type-levels. This fact is illustrated in the examples of #270, but the text in the specification is terse on this front.

Note that this proposal dovetails nicely with our Syntactic Unification Principle <https://github.com/ghc-proposals/ghc-proposals/blob/master/principles.rst#21syntax>. That principle makes a claim about code that avoid puns, and this proposal enables users to meet that requirement.

Thanks,
Richard

> On Jan 29, 2022, at 10:41 AM, Vitaly Bragilevsky <bravit111 at gmail.com> wrote:
> 
> Dear Committee,
> 
> Proposal #270 "Support pun-free code" has been resubmitted by Artyom Kuznetsov.
> 
> https://github.com/ghc-proposals/ghc-proposals/pull/270
> 
> https://github.com/hithroc/ghc-proposals/blob/master/proposals/0000-support-pun-free-code.md
> 
> This proposal was heavily revised since Iavor recommended rejection.
> As of now, it is quite thin suggesting just a couple of things:
> - warnings for the code with panning (understood as using same names
> for both types and values)
> - a syntax change for import declarations to reflect which names
> (types or values) are actually imported when importing from libraries
> relied on punning.
> 
> The first change promotes a new style of writing Haskell code without
> distinguishing types and values and having a single unified namespace.
> We are already on that road anyway and I don't see any reason not to
> support this.
> 
> The second change allows using an old style with punning. It could
> lead to doubling import declarations, but I don't think that this is
> really a problem.
> 
> I think the proposal is mature enough so I recommend acceptance.
> 
> We can also decide on the actual word used in import declarations
> (data, value, or pattern). I personally prefer value, but I don't see
> this issue as something important.
> 
> Vitaly
> _______________________________________________
> 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/20220130/c2443dd3/attachment.html>

From mail at joachim-breitner.de  Sun Jan 30 09:14:04 2022
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Sun, 30 Jan 2022 10:14:04 +0100
Subject: [ghc-steering-committee] Please review #475: New tuple and list
 syntax, Shepherd: Vlad
Message-ID: <af92c1133ce30ddeff10562f8d73a38d5f4a0a1d.camel@joachim-breitner.de>

Dear Committee,

New syntax for tuples and lists to remove punning
has been resubmitted by Richard

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

https://github.com/goldfirere/ghc-proposals/blob/tuple-syntax/proposals/0000-tuple-syntax.rst


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

Thanks,
Joachim

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


From vlad.z.4096 at gmail.com  Sun Jan 30 10:23:48 2022
From: vlad.z.4096 at gmail.com (Vladislav Zavialov (int-index))
Date: Sun, 30 Jan 2022 13:23:48 +0300
Subject: [ghc-steering-committee] #475: New tuple and list syntax,
	rec: accept
In-Reply-To: <af92c1133ce30ddeff10562f8d73a38d5f4a0a1d.camel@joachim-breitner.de>
References: <af92c1133ce30ddeff10562f8d73a38d5f4a0a1d.camel@joachim-breitner.de>
Message-ID: <92A385C3-29EB-4A9B-9EA8-113F9814FEA1@gmail.com>

Dear Committee,

Richard has proposed #475 "New tuple and list syntax”. Read it here:

https://github.com/goldfirere/ghc-proposals/blob/tuple-syntax/proposals/0000-tuple-syntax.rst

Here’s some background:
Earlier we accepted #281 "Visible 'forall' in types of terms”, which introduced, among other things, the -X(No)ListTupleTypeSyntax extension. During implementation, I discovered that this part of the proposal required further design considerations. Richard has kindly agreed to take a stab at this problem, and #475 is the result.

Short summary of the proposal:
* Introduce Tuple2, Tuple3, Tuple4, and so on, as alternative ways to write the types of tuples.
* Introduce List as the alternative way to write the type of a list.
* Do the same for unboxed tuples, unboxed sums, and constraint tuples.

This is the core part of the proposal, for which I strongly urge acceptance.

There are also other minor additions:
* Rename -XListTupleTypeSyntax to -XListTuplePuns.
* Introduce Tuple [a, b, c] as a more convenient way of writing Tuple3 a b c (likewise for n/=3)
* Introduce Constraints [a, b, c] as a more convenient way of writing CTuple3 a b c (likewise for n/=3)
* Introduce TupleN a b c as another more convenient way of writing Tuple3 a b c (likewise for n/=3)
* Introduce CTupleN a b c as another more convenient way of writing CTuple3 a b c (likewise for n/=3)

I foresee that if we don’t include Tuple/Constraints, users will end up defining their own, with different libraries exporting conflicting definitions. TupleN/ConstraintN, on the other hand, seem weakly motivated.

Personally I’d drop TupleN/ConstraintN and accept the rest of the proposal, but I’d love to hear more opinions. Let me know what you think!

- Vlad

From simon.peytonjones at gmail.com  Mon Jan 31 12:25:38 2022
From: simon.peytonjones at gmail.com (Simon Peyton Jones)
Date: Mon, 31 Jan 2022 12:25:38 +0000
Subject: [ghc-steering-committee] #475: New tuple and list syntax,
	rec: accept
In-Reply-To: <92A385C3-29EB-4A9B-9EA8-113F9814FEA1@gmail.com>
References: <af92c1133ce30ddeff10562f8d73a38d5f4a0a1d.camel@joachim-breitner.de>
 <92A385C3-29EB-4A9B-9EA8-113F9814FEA1@gmail.com>
Message-ID: <CAJKmMz-iC1XL7x7xMRumoEewcMhey-88fY54m2szm+ObM66w8g@mail.gmail.com>

> Personally I’d drop TupleN/ConstraintN and accept the rest of the
proposal, but I’d love to hear more opinions. Let me know what you think!

I agree.

I'm also not sure if we should have `Tuple` and `Constraints` or `Tuple`
and `CTuple`.  I lean to the latter.

On Sun, 30 Jan 2022 at 10:24, Vladislav Zavialov (int-index) <
vlad.z.4096 at gmail.com> wrote:

> Dear Committee,
>
> Richard has proposed #475 "New tuple and list syntax”. Read it here:
>
>
> https://github.com/goldfirere/ghc-proposals/blob/tuple-syntax/proposals/0000-tuple-syntax.rst
>
> Here’s some background:
> Earlier we accepted #281 "Visible 'forall' in types of terms”, which
> introduced, among other things, the -X(No)ListTupleTypeSyntax extension.
> During implementation, I discovered that this part of the proposal required
> further design considerations. Richard has kindly agreed to take a stab at
> this problem, and #475 is the result.
>
> Short summary of the proposal:
> * Introduce Tuple2, Tuple3, Tuple4, and so on, as alternative ways to
> write the types of tuples.
> * Introduce List as the alternative way to write the type of a list.
> * Do the same for unboxed tuples, unboxed sums, and constraint tuples.
>
> This is the core part of the proposal, for which I strongly urge
> acceptance.
>
> There are also other minor additions:
> * Rename -XListTupleTypeSyntax to -XListTuplePuns.
> * Introduce Tuple [a, b, c] as a more convenient way of writing Tuple3 a b
> c (likewise for n/=3)
> * Introduce Constraints [a, b, c] as a more convenient way of writing
> CTuple3 a b c (likewise for n/=3)
> * Introduce TupleN a b c as another more convenient way of writing Tuple3
> a b c (likewise for n/=3)
> * Introduce CTupleN a b c as another more convenient way of writing
> CTuple3 a b c (likewise for n/=3)
>
> I foresee that if we don’t include Tuple/Constraints, users will end up
> defining their own, with different libraries exporting conflicting
> definitions. TupleN/ConstraintN, on the other hand, seem weakly motivated.
>
> Personally I’d drop TupleN/ConstraintN and accept the rest of the
> proposal, but I’d love to hear more opinions. Let me know what you think!
>
> - 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/20220131/87f496fd/attachment.html>

From simon.peytonjones at gmail.com  Mon Jan 31 12:44:23 2022
From: simon.peytonjones at gmail.com (Simon Peyton Jones)
Date: Mon, 31 Jan 2022 12:44:23 +0000
Subject: [ghc-steering-committee] #270: Support pun-free code,
 recommendation: accept
In-Reply-To: <CALpVSmPE8waLOVf5NZeRWAqwH-U6EGFTOTKDffB78jAKVvi7GA@mail.gmail.com>
References: <CALpVSmPE8waLOVf5NZeRWAqwH-U6EGFTOTKDffB78jAKVvi7GA@mail.gmail.com>
Message-ID: <CAJKmMz_zErQZG-1zmyaQLi8kemYtpd0Fw92qBKwqzyJEEEiYEQ@mail.gmail.com>

I'm ok with this proposal.  It's mainly about adding new warnings.

Simon

On Sat, 29 Jan 2022 at 15:41, Vitaly Bragilevsky <bravit111 at gmail.com>
wrote:

> Dear Committee,
>
> Proposal #270 "Support pun-free code" has been resubmitted by Artyom
> Kuznetsov.
>
> https://github.com/ghc-proposals/ghc-proposals/pull/270
>
>
> https://github.com/hithroc/ghc-proposals/blob/master/proposals/0000-support-pun-free-code.md
>
> This proposal was heavily revised since Iavor recommended rejection.
> As of now, it is quite thin suggesting just a couple of things:
> - warnings for the code with panning (understood as using same names
> for both types and values)
> - a syntax change for import declarations to reflect which names
> (types or values) are actually imported when importing from libraries
> relied on punning.
>
> The first change promotes a new style of writing Haskell code without
> distinguishing types and values and having a single unified namespace.
> We are already on that road anyway and I don't see any reason not to
> support this.
>
> The second change allows using an old style with punning. It could
> lead to doubling import declarations, but I don't think that this is
> really a problem.
>
> I think the proposal is mature enough so I recommend acceptance.
>
> We can also decide on the actual word used in import declarations
> (data, value, or pattern). I personally prefer value, but I don't see
> this issue as something important.
>
> Vitaly
> _______________________________________________
> 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/20220131/df8e06ca/attachment.html>