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]

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!

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.

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.

[0] https://www.reddit.com/r/haskell/comments/447bnw/does_argument_do_have_a_future/

[1] https://mail.haskell.org/pipermail/haskell-cafe/2015-September/121217.html

[2] https://ghc.haskell.org/trac/ghc/ticket/10843

[3] https://github.com/gibiansky/ghc-reskin

Best,

Andrew

On Wed, Jun 1, 2016 at 3:26 PM Akio Takano <tkn.akio@gmail.com> wrote:

Hi Bardur,

On 2 June 2016 at 00:09, Bardur Arantsson <spam@scientician.net> wrote:
> On 06/01/2016 01:48 PM, Akio Takano wrote:
>> Hi,
>>
>> Ticket #10843 [0] proposes an extension, ArgumentsDo, which I would
>> love to see in GHC. It's a small syntactic extension that allows do,
>> case, if and lambda blocks as function arguments, without parentheses.
>> However, its differential revision [1] has been abandoned, citing a
>> mixed response from the community. A message [2] on the ticket
>> summarizes a thread in haskell-cafe on this topic.
>>
>> I, for one, think adding this extension is worthwhile, because a
>> significant number of people support it. Also, given how some people
>> seem to feel ambivalent about this change, I believe actually allowing
>> people to try it makes it clearer whether it is a good idea.
>>
>> Thus I'm wondering: is there any chance that this gets merged? If so,
>> I'm willing to work on whatever is remaining to get the change merged.
>>
>
> What's changed since it was last discussed?

Nothing has really changed. I'm just trying to argue that the current
level of community support is good enough to justify an
implementation.

Please note that the previous Differential revision was abandoned by
the author. It was *not* rejected due to a lack of support. Hence my
question: if properly implemented, does this feature have any chance
of getting merged in, or is it regarded too controversial?

> I don't think the objections
> were centered in the implementation, so I don't see what "whatever is
> remaining to get the change merged" would be.

I'm referring the points mentioned in the review comments in the
Differential revision. For example this change needs an update to the
User's Guide.

>
> AFAICT at best it's a *very* small improvement[1] and fractures Haskell
> syntax even more around extensions -- tooling etc. will need to
> understand even *more* syntax extensions[2].

I disagree that this is a small improvement, but I don't intend to
debate this here. As you said, nothing has really changed since it was
discussed before, and a lot of reasons for implementing this extension
have been already pointed out. I don't have anything to add.

Regarding tooling, my understanding is that most tools that need to
understand Haskell (this includes ghc-mod and hdevtools) use either
the GHC API or haskell-src-exts, so I don't think this extension would
need changes in many places.

Regards,
Takano Akio

>
> Regards,
>
> [1] If you grant that it is indeed an improvment, which I, personally,
> don't think it is.
>
> [2] I think most people agree that this is something that should perhaps
> be handled by something like
> https://github.com/haskell/haskell-ide-engine so that it would only need
> to be implemented once, but there's not even an alpha release yet, so
> that particular objection stands, AFAICT.
>
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
_______________________________________________
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs