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

[Richard Eisenberg]

It's true that making modifiers type-based may be wrong. I wanted to have some way to e.g. import names, etc., for use in modifiers. But maybe that makes them less useful. Despite this potential flaw, I really think that keeping modifiers around in some form is the right idea. Indeed, perhaps modifiers allow us to have a way forward toward new ideas in the language: new ideas are born as modifiers, and the popular ones get reified with better syntax once we discover usage patterns.

One strong argument in favor of modifiers is their success in other languages. I know Java has annotations (which are quite similar -- and type-based) but OCaml also has "attributes", which are quite like modifiers. OCaml attributes are not type-based: they're just strings attached to a parsed payload (such as an expression or a few other syntactic categories). This extra room in the syntax allows for a rich ecosystem of so-called ppxes (the plural of ppx), which Haskellers would call source plugins. Some attributes are interpreted by the OCaml compiler itself, but the rest are just for consumption and manipulation by ppxes -- including OCaml's entire "deriving" mechanism. Yes, the concrete syntax is pretty ugly, but the syntactic space has allowed for a wealth of growth and creativity that would not otherwise be possible. I conjecture modifiers can offer a similar wellspring for GHC.

Richard

> On Dec 12, 2022, at 11:22 AM, Joachim Breitner <mail at joachim-breitner.de> wrote:
> 
> Hi,
> 
> it’s not “in the light of experience”, and there is nothing in here
> that I couldn’t have brought up when it was originally discussed, and
> when I should have (but didn’t for reasons I don’t quite remember; I
> think it was a time of limited bandwidth on my side, and I had the
> impression that there was a lot of enthusiasm). So I’d feel bad to
> actively suggest to unaccept it now – at least not unless it happens
> that my worries are more widely shared.
> 
> Cheers,
> Joachim
> 
> 
> 
> Am Montag, dem 12.12.2022 um 16:04 +0000 schrieb Simon Peyton Jones:
>> Joachim
>> 
>> Are you arguing to un-accept the modifiers proposal?  I think that's
>> a legitimate thing to do but, well, it needs a proposal.  (A kind of
>> drastic modification to an existing proposal, namely withdrawing it.)
>> 
>> We should feel free to change our view in the light of experience --
>> and it is much easier to do so before the feature is implemented and
>> in use.  But I think it is not good to have a proposal that is
>> accepted-but-with-doubt-cast-upon-it.
>> 
>> Simon
>> 
>> On Fri, 9 Dec 2022 at 18:47, Joachim Breitner
>> <mail at joachim-breitner.de> wrote:
>>> Hi,
>>> 
>>> Am Freitag, dem 09.12.2022 um 12:38 +0000 schrieb Simon Peyton
>>> Jones:
>>>> 
>>>> We can always re-open an accepted proposal, especially if it is
>>>> not
>>>> yet implemented!
>>>> 
>>>> The motivations for modifiers I see are:
>>>> * We have modifiers for linear types
>>>> * It seem wrong to use pragmas (in {-# #-} comments) for things
>>>> that
>>>> are semantically meaningful like overlapping instances.
>>>> We definitely want modifiers in some form.  We currently use them
>>>> a
>>>> lot for {-# OVERLAPPABLE #-} etc.  We could stick with the {-#
>>>> prag
>>>> #-} syntax.  But it's a bit noisy, and it really isn't a
>>>> comment. 
>>>> And (unlike the modifier) the pragma stuff doesn't have internal
>>>> structure -- we could not use it for linear annotations.
>>>> 
>>>> But I think we should decide what syntax we want for modifier-
>>>> like
>>>> things, and get it implemented, else it'll keep blocking other
>>>> proposals, like this one from Matthew.
>>> 
>>> I was more quiet during the modifier discussion than I should have,
>>> but
>>> if we are opening this box again, I can share why I don’t feel to
>>> confident about it:
>>> 
>>> * Tying modifiers to types rules out their use for every feature
>>> that
>>> is relevant before type-checking (parsing, renaming…)
>>> For example, imagine we only had unqualified imports, and now
>>> want
>>> to add qualified imports. This feels like a “modification” to
>>> me,
>>> and a good “modifier syntax” scheme should be able to
>>> accommodate 
>>> it. But it affects renaming, and thus wouldn’t work with a type-
>>> based thing.
>>> 
>>> * The syntax might be too clumsy. Consider, again, adding
>>> qualified
>>> imports to the syntax: We’d have to specify an optional
>>> parameter
>>> (for the `qualified as Foo` part). How would that look like in
>>> Type
>>> syntax? Would the qualifier be
>>> data Quantified = Quantified (Maybe String)
>>> and you need to write Nothing or Just? And quote the name?
>>> 
>>> Even linear types, listed as one of the motivations, really
>>> wants to
>>> have a nice syntax for the linear arrow, doesn’t it?
>>> 
>>> I expect that many future modifiers on syntax benefit from
>>> custom
>>> syntax to be ergonomic and preserve the aesthetics of Haskell
>>> code.
>>> 
>>> TL;DR: I doubt that a one-scheme-fits all, type-based modifier
>>> syntax
>>> covers enough use-cases to pay its weight, and am leaning towards
>>> “just” coming up with custom syntax for new features (likely with
>>> new
>>> context-dependent keywords where possible – as in deriving via). 
>>> 
>>> 
>>> Cheers,
>>> Joachim
>>> 
>>> 
>>> 
>>> _______________________________________________
>>> ghc-steering-committee mailing list
>>> ghc-steering-committee at haskell.org <mailto:ghc-steering-committee at haskell.org>
>>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee <https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee>
> 
> -- 
> Joachim Breitner
> mail at joachim-breitner.de <mailto:mail at joachim-breitner.de>
> http://www.joachim-breitner.de/ <http://www.joachim-breitner.de/>
> 
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org <mailto:ghc-steering-committee at haskell.org>
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee <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/20221215/d12fc382/attachment-0001.html>