<html><head><meta http-equiv="Content-Type" content="text/html; charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">Concur. Let's boldly go into the future with modifiers. :)<div class=""><br class=""></div><div class="">Thanks, Vlad.</div><div class=""><br class=""></div><div class="">Richard<br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On Dec 11, 2023, at 4:31 PM, Simon Peyton Jones <<a href="mailto:simon.peytonjones@gmail.com" class="">simon.peytonjones@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class=""><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="gmail_default" style="font-family:tahoma,sans-serif">
If we choose to revise, I volunteer to implement Modifiers in time for GHC 9.12
</div></blockquote><div class=""><br class=""></div><div style="font-family:tahoma,sans-serif" class="gmail_default">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.<br class=""></div><div style="font-family:tahoma,sans-serif" class="gmail_default"><br class=""></div><div style="font-family:tahoma,sans-serif" class="gmail_default">With that in mind:</div><div style="font-family:tahoma,sans-serif" class="gmail_default"><br class=""></div><div style="font-family:tahoma,sans-serif" class="gmail_default">
<div class="">* [ x] Revise the proposal to use modifiers-based syntax and then accept</div>
</div><div style="font-family:tahoma,sans-serif" class="gmail_default"><br class=""></div><div style="font-family:tahoma,sans-serif" class="gmail_default">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.</div><div style="font-family:tahoma,sans-serif" class="gmail_default"><br class=""></div><div style="font-family:tahoma,sans-serif" class="gmail_default">Simon<br class=""></div></div><br class=""><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, 11 Dec 2023 at 12:40, Vladislav Zavialov <<a href="mailto:vlad.z.4096@gmail.com" class="">vlad.z.4096@gmail.com</a>> wrote:<br class=""></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr" class="">Dear Committee Members,<div class=""><br class=""></div><div class="">Our previous discussion regarding #512 was inconclusive.</div><div class=""><br class=""></div><div class="">Thread 1: <a href="https://mail.haskell.org/pipermail/ghc-steering-committee/2022-November/002991.html" target="_blank" class="">https://mail.haskell.org/pipermail/ghc-steering-committee/2022-November/002991.html</a></div><div class="">Thread 2: <a href="https://mail.haskell.org/pipermail/ghc-steering-committee/2022-December/003015.html" target="_blank" class="">https://mail.haskell.org/pipermail/ghc-steering-committee/2022-December/003015.html</a></div><div class=""><br class=""></div><div class="">#512 is the proposal that introduces per-declaration, per-constructor, and per-field NoFieldSelectors annotations.</div><div class=""><br class=""></div><div class="">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? </div><div class=""><br class=""></div><div class="">Here are two facts to inform your opinion:</div><div class=""><br class=""></div><div class="">1. The Modifiers proposal is accepted, and it makes sense to use it for the proposed feature</div><div class="">2. The Modifiers proposal is, however, unimplemented</div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">Here are the options. Select all that you find acceptable (multiple-choice):</div><div class="">* [ ] Accept the proposal with pragma-based syntax, then deprecate it and switch to modifiers-based syntax</div><div class="">* [ ] Accept the proposal with pragma-based syntax, do not switch to modifiers-based syntax</div><div class="">* [ ] Revise the proposal to use modifiers-based syntax and then accept</div><div class="">* [ ] Reject the proposal regardless of syntax</div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">Vlad</div></div>
_______________________________________________<br class="">
ghc-steering-committee mailing list<br class="">
<a href="mailto:ghc-steering-committee@haskell.org" target="_blank" class="">ghc-steering-committee@haskell.org</a><br class="">
<a href="https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee" rel="noreferrer" target="_blank" class="">https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee</a><br class="">
</blockquote></div>
_______________________________________________<br class="">ghc-steering-committee mailing list<br class=""><a href="mailto:ghc-steering-committee@haskell.org" class="">ghc-steering-committee@haskell.org</a><br class="">https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee<br class=""></div></blockquote></div><br class=""></div></body></html>