Re: Moving ArgumentsDo forward

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_fut... [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 wrote:

Hi Bardur,

On 2 June 2016 at 00:09, Bardur Arantsson 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

-- – Andrew