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/