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

[Joachim Breitner]

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/