<div dir="ltr"><div>I keep going back and forth. But</div><div><br></div><div>I vote 1</div><div><br></div><div>On the grounds that:</div><div>- The extra parentheses would almost always be needed, 2 is probably an unreasonable amount of syntactic noise</div><div>- We write `type Maybe a = …` not `type (Maybe a) = …`. So there's more symmetry with the declaration in 1.</div><div><br></div><div>Yet, like Simon and Joachim, it took me a second to parse `f (type Maybe Int)` correctly.<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, 25 Jan 2024 at 07:14, Moritz Angermann <<a href="mailto:moritz.angermann@gmail.com">moritz.angermann@gmail.com</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"><div dir="ltr">Maybe I'm misreading this, but this can potentially break existing code, can it not?</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, 25 Jan 2024 at 02:47, Richard Eisenberg <<a href="mailto:rae@richarde.dev" target="_blank">rae@richarde.dev</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"><div><a href="https://github.com/ghc-proposals/ghc-proposals/pull/606" target="_blank">Proposal #606</a> has been submitted to the committee, by Vlad.<div><br></div><div>This proposal makes a tiny change. Suppose we have `f :: forall (x :: Type) -> x -> ...` (this is part of -XRequiredTypeArguments). Then (as proposed) we can write `y = f (type Int -> Int) abs ...`. The `type` keyword here is to signal that what comes is a type: it should be parsed as a type and name-resolved as a type. This might matter if there is, say, a constructor Int in scope. The proposal at hand is whether to accept the above program or to require extra parentheses, thusly: `y = f (type (Int -> Int)) abs ...`. That's it -- that's the entire proposal. (It says we should _not_ accept the former, without parentheses.)</div><div><br></div><div>The motivation is to avoid surprising users. Normally when we have `word1 word2 -> word3`, word1 and word2 will associate more closely than the arrow. Yet the first example has `type Int -> Int` where the arrow binds more tightly. Because `type` is a keyword, this is no challenge to parse and is not ambiguous -- it's just perhaps confusing to users.</div><div><br></div><div>There was some debate in the proposal, but in my perusal, not a clear indication toward any particular direction. The most rigorous statement I could find is that the new syntax is a subset of the original, and so we can easily reverse this decision later.</div><div><br></div><div>I propose we vote on the matter. We have two choices:</div><div><br></div><div>1. Original syntax: allow `(type Int -> Int)` as an argument.</div><div>2. Amended syntax: require `(type (Int -> Int))` as an argument.</div><div><br></div><div>--------------------------------</div><div><br></div><div>My vote: 1.</div><div><br></div><div>There are many keywords in Haskell, and we are used to parsing these differently. For example, if we have `f (do x <- blah ...)`, we know quite well that the <- is within the `do`, not the other way around. Ditto `case`: we don't require scrutinees to be parenthesized. I posit that the strangeness some have felt around `(type Int -> Int)` is (understandable) confusion in the face of novelty. But the `type` herald will not be novel forever, and I think we'll enjoy having fewer parentheses in our code in the long run. (I might be arguing for "2 today, then 1 tomorrow". But let's just skip the intermediate step and do 1 now.)</div><div><br></div><div>I welcome your opinions and votes. It would be great to conclude this in the next 2 weeks, by Feb 7.</div><div><br></div><div>Thanks!</div><div>Richard</div></div>_______________________________________________<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>
_______________________________________________<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><br clear="all"><br><span class="gmail_signature_prefix">-- </span><br><div dir="ltr" class="gmail_signature"><div dir="ltr">Arnaud Spiwack<br>Director, Research at <a href="https://moduscreate.com" rel="noopener noreferrer" target="_blank">https://moduscreate.com</a> and <a href="https://tweag.io" rel="noopener noreferrer" target="_blank">https://tweag.io</a>.</div></div>