Here's my thought. If the modifiers implementation arrives before #512 is implemented, then it's fair to amend the proposal. If the modifiers implementation arrives after #512 is implemented, then it will be time to amend the proposal, add the modifier version of #512, and deprecate the pragma. If there hasn't been a release of the pragma version, then it can be deleted entirely. I don't really feel there needs to be additional synchronisation points imposed onto contributors. On Thu, 14 Dec 2023 at 13:35, Richard Eisenberg wrote:

Concur. Let's boldly go into the future with modifiers. :)

Thanks, Vlad.

Richard

On Dec 11, 2023, at 4:31 PM, Simon Peyton Jones < simon.peytonjones@gmail.com> wrote:

If we choose to revise, I volunteer to implement Modifiers in time for GHC

...

9.12

Like Joachim, this changes the situation a lot. Thank you for offering. You are an excellent implementor, and if you say you'll do it, I'm sure you will. Don't forget that, to be useful for the author, the modifiers need to be in Template-Haskell-generated syntax too.

With that in mind:

* [ x] Revise the proposal to use modifiers-based syntax and then accept

I'm sure the author will be happy to use modifier syntax -- he just needs to be sure that doing so won't block the feature and your offer gives him that surety.

Simon

On Mon, 11 Dec 2023 at 12:40, Vladislav Zavialov wrote:

...

Dear Committee Members,

Our previous discussion regarding #512 was inconclusive.

Thread 1: https://mail.haskell.org/pipermail/ghc-steering-committee/2022-November/0029... Thread 2: https://mail.haskell.org/pipermail/ghc-steering-committee/2022-December/0030...

#512 is the proposal that introduces per-declaration, per-constructor, and per-field NoFieldSelectors annotations.

I'm not quite sure how to summarize the discussion because everyone seems to have a unique view. But it all revolves around a syntactic issue: should the proposal use pragma-based syntax or modifiers-based syntax?

Here are two facts to inform your opinion:

1. The Modifiers proposal is accepted, and it makes sense to use it for the proposed feature 2. The Modifiers proposal is, however, unimplemented

So at the moment #512 says that we'd first introduce the pragma-based syntax, and when Modifiers are implemented we could deprecate the pragma-based syntax in favor of Modifiers.

I am *strongly* opposed to introducing a feature that we know is destined for deprecation. But not everyone shares this attitude, apparently, so let's vote.

Here are the options. Select all that you find acceptable (multiple-choice): * [ ] Accept the proposal with pragma-based syntax, then deprecate it and switch to modifiers-based syntax * [ ] Accept the proposal with pragma-based syntax, do not switch to modifiers-based syntax * [ ] Revise the proposal to use modifiers-based syntax and then accept * [ ] Reject the proposal regardless of syntax

Before you vote, let me try to sway you towards the "revise" option. If we choose to revise, I volunteer to implement Modifiers in time for GHC 9.12. I believe Modifiers are a splendid idea and I envision many good uses for them.

Vlad _______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@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.

I agree with this. Simon On Sat, 13 Jan 2024 at 21:19, Adam Gundry wrote:

It's certainly unfortunate that this proposal has been stalled for so long.

I think there is rough consensus that modifiers-style syntax would be preferable to the pragma syntax suggested in the proposal. That's slightly different from requiring Modifiers in its full glory to be implemented prior to this proposal, because one could implement the proposal more directly (e.g. having the parser recognise %NoFieldSelectors just as it could recognise {-# NoFieldSelectors #-}). Thus we don't need a synchronisation point: if necessary the amended NoFieldSelectors proposal can be implemented first and then the Modifiers implementation can generalise it.

So I'd suggest we "conditionally accept" the proposal, on the basis that it is amended to use modifier syntax, giving a clear signal to the author that the proposal isn't going to get stuck again. By "conditionally accept" I mean we wouldn't insist on another full round of committee review once the revisions are made.

Also, given the delays, I think it would be best if one of us offers to take care of the work of revising the proposal, rather than requiring the author to do it (but of course asking their opinion on this proposed approach).

Does this sound reasonable? Some of this may be what Vlad means by "Revise the proposal to use modifiers-based syntax and then accept", I'm not sure.

Cheers,

Adam

On 18/12/2023 08:59, Arnaud Spiwack wrote:

...

Here's my thought.

If the modifiers implementation arrives before #512 is implemented, then it's fair to amend the proposal. If the modifiers implementation arrives after #512 is implemented, then it will be time to amend the proposal, add the modifier version of #512, and deprecate the pragma. If there hasn't been a release of the pragma version, then it can be deleted entirely. I don't really feel there needs to be additional synchronisation points imposed onto contributors.

On Thu, 14 Dec 2023 at 13:35, Richard Eisenberg mailto:rae@richarde.dev> wrote:

Concur. Let's boldly go into the future with modifiers. :)

Thanks, Vlad.

Richard

...

On Dec 11, 2023, at 4:31 PM, Simon Peyton Jones mailto:simon.peytonjones@gmail.com> wrote:

If we choose to revise, I volunteer to implement Modifiers in time for GHC 9.12

Like Joachim, this changes the situation a lot. Thank you for offering. You are an excellent implementor, and if you say you'll do it, I'm sure you will. Don't forget that, to be useful for the author, the modifiers need to be in Template-Haskell-generated syntax too.

With that in mind:

* [ x] Revise the proposal to use modifiers-based syntax and then accept

I'm sure the author will be happy to use modifier syntax -- he just needs to be sure that doing so won't block the feature and your offer gives him that surety.

Simon

On Mon, 11 Dec 2023 at 12:40, Vladislav Zavialov mailto:vlad.z.4096@gmail.com> wrote:

Dear Committee Members,

Our previous discussion regarding #512 was inconclusive.

Thread 1:

https://mail.haskell.org/pipermail/ghc-steering-committee/2022-November/0029... < https://mail.haskell.org/pipermail/ghc-steering-committee/2022-November/0029...

...

Thread 2:

https://mail.haskell.org/pipermail/ghc-steering-committee/2022-December/0030... < https://mail.haskell.org/pipermail/ghc-steering-committee/2022-December/0030...

...

#512 is the proposal that introduces per-declaration, per-constructor, and per-field NoFieldSelectors annotations.

I'm not quite sure how to summarize the discussion because everyone seems to have a unique view. But it all revolves around a syntactic issue: should the proposal use pragma-based syntax or modifiers-based syntax?

Here are two facts to inform your opinion:

1. The Modifiers proposal is accepted, and it makes sense to use it for the proposed feature 2. The Modifiers proposal is, however, unimplemented

So at the moment #512 says that we'd first introduce the pragma-based syntax, and when Modifiers are implemented we could deprecate the pragma-based syntax in favor of Modifiers.

I am *strongly* opposed to introducing a feature that we know is destined for deprecation. But not everyone shares this attitude, apparently, so let's vote.

Here are the options. Select all that you find acceptable (multiple-choice): * [ ] Accept the proposal with pragma-based syntax, then deprecate it and switch to modifiers-based syntax * [ ] Accept the proposal with pragma-based syntax, do not switch to modifiers-based syntax * [ ] Revise the proposal to use modifiers-based syntax and then accept * [ ] Reject the proposal regardless of syntax

Before you vote, let me try to sway you towards the "revise" option. If we choose to revise, I volunteer to implement Modifiers in time for GHC 9.12. I believe Modifiers are a splendid idea and I envision many good uses for them.

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

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee