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

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 https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

-- Joachim Breitner mail@joachim-breitner.de http://www.joachim-breitner.de/