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

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 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 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@haskell.org mailto:ghc-steering-committee@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@joachim-breitner.de mailto:mail@joachim-breitner.de http://www.joachim-breitner.de/ http://www.joachim-breitner.de/

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org mailto:ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee