<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">Some collected thoughts on modifiers (which I have spent quite a bit of time mulling on over the past week):<div class=""><br class=""></div><div class="">- Yes, the current design struggles with changes affecting early stages.</div><div class=""><br class=""></div><div class="">- Modifiers affecting renaming are not entirely impossible though; they're just different. Normal, type-based modifiers allow the full expressiveness of the type system, including import/export, synonyms, and even computation via type families. However, even during renaming, we have identifiers with original names (that is, we can know the actual module where an identifier was initially declared, ignoring re-exports). So we could say that, in `%NoFieldSelectors data Rec = MkRec { field :: Int }`, NoFieldSelectors must be the actual modifier, not via any type synonym. That's unfortunate, but it's far from impossible.</div><div class=""><br class=""></div><div class="">- The key part of the design, for me, is uniform syntax. We use % to introduce a modifier. And it appears before the thing modified. Other aspects are nice-to-have, and so I decided to piggy-back on our expressive types to allow for some abstraction.</div><div class=""><br class=""></div><div class="">- One possibility is to have % introduce type-based modifiers, using some other symbol (possibly %%) to introduce string-y modifiers. Or we could say that e.g. %(of blah) is string-y -- note that it begins with a keyword.</div><div class=""><br class=""></div><div class="">Regardless of these design aspects, I think the initial roll-out can proceed, and then we can embellish as we learn from experience.</div><div class=""><br class=""></div><div class="">Richard<br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On Dec 16, 2022, at 9:54 AM, Arnaud Spiwack <<a href="mailto:arnaud.spiwack@tweag.io" class="">arnaud.spiwack@tweag.io</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class=""><div class="">To be frank, my initial reaction to the modifiers proposal was not dissimilar to Joachim's. But I mellowed up to the type-based approach because of things like linear types (which need to be type-level values) and matchability (which also needs to for inference). As I understand it, adding arguments to the functional arrow (and, correspondingly, to binders) was one of the prime motivations for the design of modifiers. And as long as you annotate within expression, it seems to be a pretty reasonable design. Where maybe the proposal is overly enthusiastic (and I say “maybe” quite honestly: I don't really have an opinion) is to apply type-based modifiers to whole declarations (overlappable instance, or deactivating warnings), where the benefits of types are less clear, and we run into situation like Joachim's pointing out where we want to change the behaviour of the renamer. We may very well want to treat the definition granularity and the expression granularity very differently.</div><div class=""><br class=""></div><div class="">In the prior art in this space, there are also Rust's attributes, which are at the definition granularity (they are essentially just strings).<br class=""></div></div><br class=""><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, 15 Dec 2022 at 13:04, Simon Peyton Jones <<a href="mailto:simon.peytonjones@gmail.com" class="">simon.peytonjones@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=""><div class="gmail_default" style="font-family:tahoma,sans-serif">Hmm. <br class=""></div><div class="gmail_default" style="font-family:tahoma,sans-serif"><ul class=""><li class="">We have an accepted proposal for modifiers. <br class=""></li><li class="">As of today we have a willing implementer, Georgi: <a href="https://gitlab.haskell.org/ghc/ghc/-/issues/22624" target="_blank" class="">https://gitlab.haskell.org/ghc/ghc/-/issues/22624</a></li></ul><div class="">And yet some doubt is being expressed in this thread about whether the accepted proposal is the one we really want. <br class=""></div><div class=""><br class=""></div><div class="">@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 class=""><br class=""></div><div class="">Simon<br class=""></div></div><div class="gmail_default" style="font-family:tahoma,sans-serif"><br class=""></div><div class="gmail_default" style="font-family:tahoma,sans-serif"><br class=""></div></div><br class=""><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" class="">mail@joachim-breitner.de</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">Hi Richard,<br class="">
<br class="">
thanks, comparing Modifiers to the annotations and attributes in other<br class="">
languages indeed puts this into a perspective that makes more sense to<br class="">
me. It seems I have assumed a broader scope for modifiers (maybe<br class="">
because “modify” sounds much stronger than “annotate” or<br class="">
“attribut…ize”). So I conclude the goal is not to necessarily to remove<br class="">
_all_ kind of pragmas, but only maybe those that fit the pattern (e.g.<br class="">
don’t affect parsing and renaming). Is that right?<br class="">
<br class="">
So my straw man “could qualified imports be modifiers” is simply out of<br class="">
scope (heh).<br class="">
<br class="">
Especially the potential use case for plugins (which do benefit from an<br class="">
extensible, namespaced scheme that does not require changes to parsing)<br class="">
– essentially a variant of the ANN pragma – is convincing.<br class="">
<br class="">
Turning back to NoFieldSelectors, however, I notice that<br class="">
NoFieldSelectors _does_ affect renaming already, because it affects<br class="">
whether a symbol with the field’s name is in scope (which, in<br class="">
particular, has further effects with implicit binders etc…), doesn't<br class="">
it? So would modifiers, if we had them, even work here?<br class="">
<br class="">
<br class="">
Cheers,<br class="">
Joachim<br class="">
-- <br class="">
Joachim Breitner<br class="">
<a href="mailto:mail@joachim-breitner.de" target="_blank" class="">mail@joachim-breitner.de</a><br class="">
<a href="http://www.joachim-breitner.de/" rel="noreferrer" target="_blank" class="">http://www.joachim-breitner.de/</a><br class="">
<br class="">
_______________________________________________<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" 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>