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

[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
>
>
>
> --
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20221212/2ca77f5d/attachment.html>