<div dir="ltr"><div class="gmail_default" style="font-family:tahoma,sans-serif">Joachim</div><div class="gmail_default" style="font-family:tahoma,sans-serif"><br></div><div class="gmail_default" style="font-family:tahoma,sans-serif">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.)</div><div class="gmail_default" style="font-family:tahoma,sans-serif"><br></div><div class="gmail_default" style="font-family:tahoma,sans-serif">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.</div><div class="gmail_default" style="font-family:tahoma,sans-serif"><br></div><div class="gmail_default" style="font-family:tahoma,sans-serif">Simon<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, 9 Dec 2022 at 18:47, Joachim Breitner <<a href="mailto:mail@joachim-breitner.de">mail@joachim-breitner.de</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi,<br>
<br>
Am Freitag, dem 09.12.2022 um 12:38 +0000 schrieb Simon Peyton Jones:<br>
> <br>
> We can always re-open an accepted proposal, especially if it is not<br>
> yet implemented!<br>
> <br>
> The motivations for modifiers I see are:<br>
> * We have modifiers for linear types<br>
> * It seem wrong to use pragmas (in {-# #-} comments) for things that<br>
> are semantically meaningful like overlapping instances.<br>
> We definitely want modifiers in some form. We currently use them a<br>
> lot for {-# OVERLAPPABLE #-} etc. We could stick with the {-# prag<br>
> #-} syntax. But it's a bit noisy, and it really isn't a comment. <br>
> And (unlike the modifier) the pragma stuff doesn't have internal<br>
> structure -- we could not use it for linear annotations.<br>
> <br>
> But I think we should decide what syntax we want for modifier-like<br>
> things, and get it implemented, else it'll keep blocking other<br>
> proposals, like this one from Matthew.<br>
<br>
I was more quiet during the modifier discussion than I should have, but<br>
if we are opening this box again, I can share why I don’t feel to<br>
confident about it:<br>
<br>
* Tying modifiers to types rules out their use for every feature that<br>
is relevant before type-checking (parsing, renaming…)<br>
For example, imagine we only had unqualified imports, and now want<br>
to add qualified imports. This feels like a “modification” to me,<br>
and a good “modifier syntax” scheme should be able to accommodate <br>
it. But it affects renaming, and thus wouldn’t work with a type-<br>
based thing.<br>
<br>
* The syntax might be too clumsy. Consider, again, adding qualified<br>
imports to the syntax: We’d have to specify an optional parameter<br>
(for the `qualified as Foo` part). How would that look like in Type<br>
syntax? Would the qualifier be<br>
data Quantified = Quantified (Maybe String)<br>
and you need to write Nothing or Just? And quote the name?<br>
<br>
Even linear types, listed as one of the motivations, really wants to<br>
have a nice syntax for the linear arrow, doesn’t it?<br>
<br>
I expect that many future modifiers on syntax benefit from custom<br>
syntax to be ergonomic and preserve the aesthetics of Haskell code.<br>
<br>
TL;DR: I doubt that a one-scheme-fits all, type-based modifier syntax<br>
covers enough use-cases to pay its weight, and am leaning towards<br>
“just” coming up with custom syntax for new features (likely with new<br>
context-dependent keywords where possible – as in deriving via). <br>
<br>
<br>
Cheers,<br>
Joachim<br>
<br>
<br>
<br>
-- <br>
Joachim Breitner<br>
<a href="mailto:mail@joachim-breitner.de" target="_blank">mail@joachim-breitner.de</a><br>
<a href="http://www.joachim-breitner.de/" rel="noreferrer" target="_blank">http://www.joachim-breitner.de/</a><br>
<br>
_______________________________________________<br>
ghc-steering-committee mailing list<br>
<a href="mailto:ghc-steering-committee@haskell.org" target="_blank">ghc-steering-committee@haskell.org</a><br>
<a href="https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee" rel="noreferrer" target="_blank">https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee</a><br>
</blockquote></div>