<div dir="ltr"><div class="gmail_default" style="font-family:tahoma,sans-serif">I agree with this. <br></div><div class="gmail_default" style="font-family:tahoma,sans-serif"><br></div><div class="gmail_default" style="font-family:tahoma,sans-serif">Simon<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, 13 Jan 2024 at 21:19, Adam Gundry <<a href="mailto:adam@well-typed.com">adam@well-typed.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">It's certainly unfortunate that this proposal has been stalled for so long.<br>
<br>
I think there is rough consensus that modifiers-style syntax would be <br>
preferable to the pragma syntax suggested in the proposal. That's <br>
slightly different from requiring Modifiers in its full glory to be <br>
implemented prior to this proposal, because one could implement the <br>
proposal more directly (e.g. having the parser recognise <br>
%NoFieldSelectors just as it could recognise {-# NoFieldSelectors #-}). <br>
Thus we don't need a synchronisation point: if necessary the amended <br>
NoFieldSelectors proposal can be implemented first and then the <br>
Modifiers implementation can generalise it.<br>
<br>
So I'd suggest we "conditionally accept" the proposal, on the basis that <br>
it is amended to use modifier syntax, giving a clear signal to the <br>
author that the proposal isn't going to get stuck again. By <br>
"conditionally accept" I mean we wouldn't insist on another full round <br>
of committee review once the revisions are made.<br>
<br>
Also, given the delays, I think it would be best if one of us offers to <br>
take care of the work of revising the proposal, rather than requiring <br>
the author to do it (but of course asking their opinion on this proposed <br>
approach).<br>
<br>
Does this sound reasonable? Some of this may be what Vlad means by <br>
"Revise the proposal to use modifiers-based syntax and then accept", I'm <br>
not sure.<br>
<br>
Cheers,<br>
<br>
Adam<br>
<br>
<br>
On 18/12/2023 08:59, Arnaud Spiwack wrote:<br>
> Here's my thought.<br>
> <br>
> If the modifiers implementation arrives before #512 is implemented, then <br>
> it's fair to amend the proposal. If the modifiers implementation arrives <br>
> after #512 is implemented, then it will be time to amend the proposal, <br>
> add the modifier version of #512, and deprecate the pragma. If there <br>
> hasn't been a release of the pragma version, then it can be deleted <br>
> entirely. I don't really feel there needs to be additional <br>
> synchronisation points imposed onto contributors.<br>
> <br>
> On Thu, 14 Dec 2023 at 13:35, Richard Eisenberg <<a href="mailto:rae@richarde.dev" target="_blank">rae@richarde.dev</a> <br>
> <mailto:<a href="mailto:rae@richarde.dev" target="_blank">rae@richarde.dev</a>>> wrote:<br>
> <br>
> Concur. Let's boldly go into the future with modifiers. :)<br>
> <br>
> Thanks, Vlad.<br>
> <br>
> Richard<br>
> <br>
>> On Dec 11, 2023, at 4:31 PM, Simon Peyton Jones<br>
>> <<a href="mailto:simon.peytonjones@gmail.com" target="_blank">simon.peytonjones@gmail.com</a> <mailto:<a href="mailto:simon.peytonjones@gmail.com" target="_blank">simon.peytonjones@gmail.com</a>>><br>
>> wrote:<br>
>><br>
>> If we choose to revise, I volunteer to implement Modifiers in<br>
>> time for GHC 9.12 <br>
>><br>
>><br>
>> Like Joachim, this changes the situation a lot. Thank you for<br>
>> offering. You are an excellent implementor, and if you say you'll<br>
>> do it, I'm sure you will. Don't forget that, to be useful for the<br>
>> author, the modifiers need to be in Template-Haskell-generated<br>
>> syntax too.<br>
>><br>
>> With that in mind:<br>
>><br>
>> * [ x] Revise the proposal to use modifiers-based syntax and then<br>
>> accept<br>
>><br>
>> I'm sure the author will be happy to use modifier syntax -- he<br>
>> just needs to be sure that doing so won't block the feature and<br>
>> your offer gives him that surety.<br>
>><br>
>> Simon<br>
>><br>
>> On Mon, 11 Dec 2023 at 12:40, Vladislav Zavialov<br>
>> <<a href="mailto:vlad.z.4096@gmail.com" target="_blank">vlad.z.4096@gmail.com</a> <mailto:<a href="mailto:vlad.z.4096@gmail.com" target="_blank">vlad.z.4096@gmail.com</a>>> wrote:<br>
>><br>
>> Dear Committee Members,<br>
>><br>
>> Our previous discussion regarding #512 was inconclusive.<br>
>><br>
>> Thread 1:<br>
>> <a href="https://mail.haskell.org/pipermail/ghc-steering-committee/2022-November/002991.html" rel="noreferrer" target="_blank">https://mail.haskell.org/pipermail/ghc-steering-committee/2022-November/002991.html</a> <<a href="https://mail.haskell.org/pipermail/ghc-steering-committee/2022-November/002991.html" rel="noreferrer" target="_blank">https://mail.haskell.org/pipermail/ghc-steering-committee/2022-November/002991.html</a>><br>
>> Thread 2:<br>
>> <a href="https://mail.haskell.org/pipermail/ghc-steering-committee/2022-December/003015.html" rel="noreferrer" target="_blank">https://mail.haskell.org/pipermail/ghc-steering-committee/2022-December/003015.html</a> <<a href="https://mail.haskell.org/pipermail/ghc-steering-committee/2022-December/003015.html" rel="noreferrer" target="_blank">https://mail.haskell.org/pipermail/ghc-steering-committee/2022-December/003015.html</a>><br>
>><br>
>> #512 is the proposal that introduces per-declaration,<br>
>> per-constructor, and per-field NoFieldSelectors annotations.<br>
>><br>
>> I'm not quite sure how to summarize the discussion because<br>
>> everyone seems to have a unique view. But it all revolves<br>
>> around a syntactic issue: should the proposal use pragma-based<br>
>> syntax or modifiers-based syntax?<br>
>><br>
>> Here are two facts to inform your opinion:<br>
>><br>
>> 1. The Modifiers proposal is accepted, and it makes sense to<br>
>> use it for the proposed feature<br>
>> 2. The Modifiers proposal is, however, unimplemented<br>
>><br>
>> So at the moment #512 says that we'd first introduce the<br>
>> pragma-based syntax, and when Modifiers are implemented we<br>
>> could deprecate the pragma-based syntax in favor of Modifiers.<br>
>><br>
>> I am *strongly* opposed to introducing a feature that we know<br>
>> is destined for deprecation. But not everyone shares this<br>
>> attitude, apparently, so let's vote.<br>
>><br>
>> Here are the options. Select all that you find acceptable<br>
>> (multiple-choice):<br>
>> * [ ] Accept the proposal with pragma-based syntax, then<br>
>> deprecate it and switch to modifiers-based syntax<br>
>> * [ ] Accept the proposal with pragma-based syntax, do not<br>
>> switch to modifiers-based syntax<br>
>> * [ ] Revise the proposal to use modifiers-based syntax and<br>
>> then accept<br>
>> * [ ] Reject the proposal regardless of syntax<br>
>><br>
>> Before you vote, let me try to sway you towards the "revise"<br>
>> option. If we choose to revise, I volunteer to implement<br>
>> Modifiers in time for GHC 9.12. I believe Modifiers are a<br>
>> splendid idea and I envision many good uses for them.<br>
>><br>
>> Vlad<br>
<br>
<br>
-- <br>
Adam Gundry, Haskell Consultant<br>
Well-Typed LLP, <a href="https://www.well-typed.com/" rel="noreferrer" target="_blank">https://www.well-typed.com/</a><br>
<br>
Registered in England & Wales, OC335890<br>
27 Old Gloucester Street, London WC1N 3AX, England<br>
<br>
_______________________________________________<br>
ghc-steering-committee mailing list<br>
<a href="mailto:ghc-steering-committee@haskell.org" target="_blank">ghc-steering-committee@haskell.org</a><br>
<a href="https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee" rel="noreferrer" target="_blank">https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee</a><br>
</blockquote></div>