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@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@joachim-breitner.de
  http://www.joachim-breitner.de/

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