<html><head><meta http-equiv="Content-Type" content="text/html; charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">Let's call this one accepted. I've merged the MR.<div class=""><br class=""></div><div class="">Richard<br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On Feb 26, 2024, at 8:42 AM, Richard Eisenberg <<a href="mailto:rae@richarde.dev" class="">rae@richarde.dev</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html; charset=us-ascii" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">I've been on the fence, as have others here. Simon PJ describes himself as being far from the fence -- and in the same place as Vlad, our proposer and intrepid implementer. So while I'm not deeply convinced in my soul about this, I think the right choice as a committee is to go with option (2) in this thread (which is what the proposer is asking for).<div class=""><br class=""></div><div class="">I don't see much of a reason to keep extending this debate (everyone who is saying they care strongly is getting their way), but out of courtesy let's extend this to the end of the month (one extra day this year!). If I don't hear further comments, I'll accept this on Thursday.</div><div class=""><br class=""></div><div class="">Thanks!</div><div class="">Richard</div><div class=""><div class=""><br class=""><blockquote type="cite" class=""><div class="">On Jan 25, 2024, at 7:07 AM, Simon Peyton Jones <<a href="mailto:simon.peytonjones@gmail.com" class="">simon.peytonjones@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class=""><div class="gmail_default" style="font-family:tahoma,sans-serif">I vote (2), fairly strongly<br class=""></div><div class="gmail_default" style="font-family:tahoma,sans-serif"><br class=""></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 class=""></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 class="gmail-user-mention gmail-notranslate" href="https://github.com/phadej">@phadej</a> For what it's worth, this was my initial thinking when I put <code class="gmail-notranslate">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 class="gmail-notranslate"><b class="">fn (type Int -> [a])</b></code> and had to double check the specification if it was supposed to be <code class="gmail-notranslate">fn ((type Int) -> [a])</code> or <code class="gmail-notranslate">fn (type (Int -> [a]))</code>.</blockquote>
</div><div class="gmail_default" style="font-family:tahoma,sans-serif"><br class=""></div><div class="gmail_default" style="font-family:tahoma,sans-serif">The point is that the `type` namespace changer can appear <b class="">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 class="gmail-notranslate">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 class="">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 class=""></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 class="gmail-notranslate">fn (type K -> [a])</code></div><div class="gmail_default" style="font-family:tahoma,sans-serif;margin-left:40px"><code class="gmail-notranslate"><br class=""></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 class="gmail-notranslate" 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 class=""></code></div><div class="gmail_default"><code class="gmail-notranslate" style="font-family:tahoma,sans-serif"><br class=""></code>
</div></div><div class="gmail_default" style="margin-left:40px">
</div><div class="gmail_default" style="font-family:tahoma,sans-serif"><code class="gmail-notranslate" 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 class="gmail-notranslate"><br class=""></code></div><div class="gmail_default" style="font-family:tahoma,sans-serif"><code class="gmail-notranslate">Simon<br class=""></code>
</div>
</div></div>
_______________________________________________<br class="">ghc-steering-committee mailing list<br class=""><a href="mailto:ghc-steering-committee@haskell.org" class="">ghc-steering-committee@haskell.org</a><br class=""><a href="https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee" class="">https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee</a><br class=""></div></blockquote></div><br class=""></div></div></div></blockquote></div><br class=""></div></body></html>