<div dir="ltr">I remain unmoved by Simon's example. The status quo is already simple: `type` extends as far to the right as possible. Just like \. And just like `do`, `else`, and `in`.<div><br></div><div>The hope is that people using this will tend to avoid punning, and so the matter will be moot, anyway.</div><div><br></div><div>Richard</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Jan 25, 2024 at 7:08 AM Simon Peyton Jones <<a href="mailto:simon.peytonjones@gmail.com">simon.peytonjones@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"><div class="gmail_default" style="font-family:tahoma,sans-serif">I vote (2), fairly strongly<br></div><div class="gmail_default" style="font-family:tahoma,sans-serif"><br></div><div class="gmail_default" style="font-family:tahoma,sans-serif">Remember this comment from Vlad:</div><div class="gmail_default" style="font-family:tahoma,sans-serif"><br></div><div class="gmail_default" style="font-family:tahoma,sans-serif">
<blockquote dir="auto" class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><a href="https://github.com/phadej" target="_blank">@phadej</a> For what it's worth, this was my initial thinking when I put <code>ktype</code> there, so past me agrees with you. What changed my opinion is that two years later (i.e. now) I looked at the examples like <code><b>fn (type Int -> [a])</b></code> and had to double check the specification if it was supposed to be <code>fn ((type Int) -> [a])</code> or <code>fn (type (Int -> [a]))</code>.</blockquote>

</div><div class="gmail_default" style="font-family:tahoma,sans-serif"><br></div><div class="gmail_default" style="font-family:tahoma,sans-serif">The point is that the `type` namespace changer can appear <b>deep within a type</b>.  It's not like "@"!    For exmaple</div><div class="gmail_default" style="font-family:tahoma,sans-serif;margin-left:40px">
<code>fn ((type K) -> [a])</code>

</div><div class="gmail_default" style="font-family:tahoma,sans-serif">makes perfect sense.  fn has a required type argument, but in the (type K) <b>sub-part </b>of the type do we switch to the type namespace.  (Maybe K is in scope also as a data constructor.)  Without the parens, do you really want to wonder about how this parses?<br></div><div class="gmail_default" style="font-family:tahoma,sans-serif">
<div class="gmail_default" style="font-family:tahoma,sans-serif;margin-left:40px">
<code>fn (type K -> [a])</code></div><div class="gmail_default" style="font-family:tahoma,sans-serif;margin-left:40px"><code><br></code></div><div class="gmail_default" style="font-family:tahoma,sans-serif;margin-left:40px">
</div><div class="gmail_default" style="font-family:tahoma,sans-serif"><div class="gmail_default" style="font-family:tahoma,sans-serif"><code style="font-family:tahoma,sans-serif">I
 prefer code that is slightly longer, but much clearer, than saving two 
characters but requiring reference to the user manual to parse.<br></code></div><div class="gmail_default"><code style="font-family:tahoma,sans-serif"><br></code>

</div></div><div class="gmail_default" style="margin-left:40px">

</div><div class="gmail_default" style="font-family:tahoma,sans-serif"><code style="font-family:tahoma,sans-serif">Let's make it simple and unambiguous for now.  If it seems painful in practice we can debate liberalising it.</code></div><div class="gmail_default" style="font-family:tahoma,sans-serif"><code><br></code></div><div class="gmail_default" style="font-family:tahoma,sans-serif"><code>Simon<br></code>

</div>

</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>