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

[Joachim Breitner]

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

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