[ghc-steering-committee] Modifiers (Was: #512: NoFieldSelectors as datatype annotation)

[Arnaud Spiwack]

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.

In the prior art in this space, there are also Rust's attributes, which are
at the definition granularity (they are essentially just strings).

On Thu, 15 Dec 2022 at 13:04, Simon Peyton Jones <
simon.peytonjones at gmail.com> wrote:

> Hmm.
>
>    - We have an accepted proposal for modifiers.
>    - As of today we have a willing implementer, Georgi:
>    https://gitlab.haskell.org/ghc/ghc/-/issues/22624
>
> And yet some doubt is being expressed in this thread about whether the
> accepted proposal is the one we really want.
>
> @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?
>
> Simon
>
>
>
> On Thu, 15 Dec 2022 at 09:43, Joachim Breitner <mail at joachim-breitner.de>
> wrote:
>
>> Hi Richard,
>>
>> thanks, comparing Modifiers to the annotations and attributes in other
>> languages indeed puts this into a perspective that makes more sense to
>> me. It seems I have assumed a broader scope for modifiers (maybe
>> because “modify” sounds much stronger than “annotate” or
>> “attribut…ize”). So I conclude the goal is not to necessarily to remove
>> _all_ kind of  pragmas, but only maybe those that fit the pattern (e.g.
>> don’t affect parsing and renaming). Is that right?
>>
>> So my straw man “could qualified imports be modifiers” is simply out of
>> scope (heh).
>>
>> Especially the potential use case for plugins (which do benefit from an
>> extensible, namespaced scheme that does not require changes to parsing)
>> – essentially a variant of the ANN pragma – is convincing.
>>
>> Turning back to NoFieldSelectors, however, I notice that
>> NoFieldSelectors _does_ affect renaming already, because it affects
>> whether a symbol with the field’s name is in scope (which, in
>> particular, has further effects with implicit binders etc…), doesn't
>> it? So would modifiers, if we had them, even work here?
>>
>>
>> Cheers,
>> Joachim
>> --
>> Joachim Breitner
>>   mail at joachim-breitner.de
>>   http://www.joachim-breitner.de/
>>
>> _______________________________________________
>> ghc-steering-committee mailing list
>> ghc-steering-committee at haskell.org
>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>>
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20221216/76d24035/attachment.html>