<div dir="ltr"><div class="gmail_default" style="font-family:tahoma,sans-serif">Hmm.  <br></div><div class="gmail_default" style="font-family:tahoma,sans-serif"><ul><li>We have an accepted proposal for modifiers.  <br></li><li>As of today we have a willing implementer, Georgi: <a href="https://gitlab.haskell.org/ghc/ghc/-/issues/22624">https://gitlab.haskell.org/ghc/ghc/-/issues/22624</a></li></ul><div>And yet some doubt is being expressed in this thread about whether the accepted proposal is the one we really want.  <br></div><div><br></div><div>@rae Georgi says you are going to mentor him.  Do you feel able to help us converge on a design we are all content with; quite possibly just reaffirming the current accepted proposal?</div><div><br></div><div>Simon<br></div></div><div class="gmail_default" style="font-family:tahoma,sans-serif"><br></div><div class="gmail_default" style="font-family:tahoma,sans-serif"><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, 15 Dec 2022 at 09:43, Joachim Breitner <<a href="mailto:mail@joachim-breitner.de" target="_blank">mail@joachim-breitner.de</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">Hi Richard,<br>
<br>
thanks, comparing Modifiers to the annotations and attributes in other<br>
languages indeed puts this into a perspective that makes more sense to<br>
me. It seems I have assumed a broader scope for modifiers (maybe<br>
because “modify” sounds much stronger than “annotate” or<br>
“attribut…ize”). So I conclude the goal is not to necessarily to remove<br>
_all_ kind of  pragmas, but only maybe those that fit the pattern (e.g.<br>
don’t affect parsing and renaming). Is that right?<br>
<br>
So my straw man “could qualified imports be modifiers” is simply out of<br>
scope (heh).<br>
<br>
Especially the potential use case for plugins (which do benefit from an<br>
extensible, namespaced scheme that does not require changes to parsing)<br>
– essentially a variant of the ANN pragma – is convincing.<br>
<br>
Turning back to NoFieldSelectors, however, I notice that<br>
NoFieldSelectors _does_ affect renaming already, because it affects<br>
whether a symbol with the field’s name is in scope (which, in<br>
particular, has further effects with implicit binders etc…), doesn't<br>
it? So would modifiers, if we had them, even work here?<br>
<br>
<br>
Cheers,<br>
Joachim<br>
-- <br>
Joachim Breitner<br>
  <a href="mailto:mail@joachim-breitner.de" target="_blank">mail@joachim-breitner.de</a><br>
  <a href="http://www.joachim-breitner.de/" rel="noreferrer" target="_blank">http://www.joachim-breitner.de/</a><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>