<div dir="ltr">As the author of the proposal and extension, I'd like to clarify that the change was abandoned per se because of how controversial the change was. [0] [1] [2]<div><br></div><div>This is not to say that we should not continue to discuss this change, but if we do so, make sure that you first read through the previous discussion -- it was quite extensive!<br><div><br></div><div>Specifically, I became unconvinced that it was worth the effort to make as an extension, given the reasons against it (mainly, extra work for GHC, hindent, haskell-src-exts, etc etc); I think this along with a few other things (trailing commas!) could make a significant improvement to cosmetic Haskell syntax, but perhaps one extension per character is a bit much for that. That said I have no idea how else a mythical Haskell' could get a cleaned up syntax if not through first being implemented as a GHC extension.</div><div><br></div><div>Finally, you may be interested in ghc-reskin [3], which was a (slightly tongue-in-cheek) response to a lot of the discussion caused by this extension last time, and could potentially be made into a production-ready tool / Haskell' syntax if anyone cared strongly to do so.</div><div><div><br></div><div>[0] <a href="https://www.reddit.com/r/haskell/comments/447bnw/does_argument_do_have_a_future/">https://www.reddit.com/r/haskell/comments/447bnw/does_argument_do_have_a_future/</a></div><div>[1] <a href="https://mail.haskell.org/pipermail/haskell-cafe/2015-September/121217.html">https://mail.haskell.org/pipermail/haskell-cafe/2015-September/121217.html</a></div><div>[2] <a href="https://ghc.haskell.org/trac/ghc/ticket/10843">https://ghc.haskell.org/trac/ghc/ticket/10843</a></div><div>[3] <a href="https://github.com/gibiansky/ghc-reskin">https://github.com/gibiansky/ghc-reskin</a><br><div><br></div><div>Best,</div><div>Andrew</div><div><br><div class="gmail_quote"><div dir="ltr">On Wed, Jun 1, 2016 at 3:26 PM Akio Takano <<a href="mailto:tkn.akio@gmail.com" target="_blank">tkn.akio@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Bardur,<br>
<br>
On 2 June 2016 at 00:09, Bardur Arantsson <<a href="mailto:spam@scientician.net" target="_blank">spam@scientician.net</a>> wrote:<br>
> On 06/01/2016 01:48 PM, Akio Takano wrote:<br>
>> Hi,<br>
>><br>
>> Ticket #10843 [0] proposes an extension, ArgumentsDo, which I would<br>
>> love to see in GHC. It's a small syntactic extension that allows do,<br>
>> case, if and lambda blocks as function arguments, without parentheses.<br>
>> However, its differential revision [1] has been abandoned, citing a<br>
>> mixed response from the community. A message [2] on the ticket<br>
>> summarizes a thread in haskell-cafe on this topic.<br>
>><br>
>> I, for one, think adding this extension is worthwhile, because a<br>
>> significant number of people support it. Also, given how some people<br>
>> seem to feel ambivalent about this change, I believe actually allowing<br>
>> people to try it makes it clearer whether it is a good idea.<br>
>><br>
>> Thus I'm wondering: is there any chance that this gets merged? If so,<br>
>> I'm willing to work on whatever is remaining to get the change merged.<br>
>><br>
><br>
> What's changed since it was last discussed?<br>
<br>
Nothing has really changed. I'm just trying to argue that the current<br>
level of community support is good enough to justify an<br>
implementation.<br>
<br>
Please note that the previous Differential revision was abandoned by<br>
the author. It was *not* rejected due to a lack of support. Hence my<br>
question: if properly implemented, does this feature have any chance<br>
of getting merged in, or is it regarded too controversial?<br>
<br>
> I don't think the objections<br>
> were centered in the implementation, so I don't see what "whatever is<br>
> remaining to get the change merged" would be.<br>
<br>
I'm referring the points mentioned in the review comments in the<br>
Differential revision. For example this change needs an update to the<br>
User's Guide.<br>
<br>
><br>
> AFAICT at best it's a *very* small improvement[1] and fractures Haskell<br>
> syntax even more around extensions -- tooling etc. will need to<br>
> understand even *more* syntax extensions[2].<br>
<br>
I disagree that this is a small improvement, but I don't intend to<br>
debate this here. As you said, nothing has really changed since it was<br>
discussed before, and a lot of reasons for implementing this extension<br>
have been already pointed out. I don't have anything to add.<br>
<br>
Regarding tooling, my understanding is that most tools that need to<br>
understand Haskell (this includes ghc-mod and hdevtools) use either<br>
the GHC API or haskell-src-exts, so I don't think this extension would<br>
need changes in many places.<br>
<br>
Regards,<br>
Takano Akio<br>
<br>
><br>
> Regards,<br>
><br>
> [1] If you grant that it is indeed an improvment, which I, personally,<br>
> don't think it is.<br>
><br>
> [2] I think most people agree that this is something that should perhaps<br>
> be handled by something like<br>
> <a href="https://github.com/haskell/haskell-ide-engine" rel="noreferrer" target="_blank">https://github.com/haskell/haskell-ide-engine</a> so that it would only need<br>
> to be implemented once, but there's not even an alpha release yet, so<br>
> that particular objection stands, AFAICT.<br>
><br>
><br>
> _______________________________________________<br>
> ghc-devs mailing list<br>
> <a href="mailto:ghc-devs@haskell.org" target="_blank">ghc-devs@haskell.org</a><br>
> <a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs</a><br>
_______________________________________________<br>
ghc-devs mailing list<br>
<a href="mailto:ghc-devs@haskell.org" target="_blank">ghc-devs@haskell.org</a><br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs</a><br>
</blockquote></div></div></div></div></div></div><div dir="ltr">-- <br></div><div data-smartmail="gmail_signature"><p dir="ltr">– Andrew</p>
</div>