This gets a guilty +1 from me, I have always found $ busy and cumbersome to read. Patterns such as ‘f a b c $ do’ are ubiquitous (especially in ESDLs where clean syntax matters more) and code such as

dataFetch req = Fetch $ \ref -> do

awkwardly requires 3 steps ($, lambda, do). 2016-06-01 16:32 GMT, Edward Kmett :

Just as a note: I noticed this was being discussed a couple of weeks ago as a possible topic for haskell-prime, when they were discussing what was in scope for the committee, so I'm not entirely sure its a dead topic.

-Edward

On Wed, Jun 1, 2016 at 11:09 AM, 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? 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.

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].

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

Akio Thanks for bringing back the ArgumentsDo question. My personal take on it is similar to Bardur:

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].

The benefit to me seems slight. The cost is also modest, but it is not zero (see below), even given a complete implementation. ANY feature carries a cost that is borne by every subsequent implementor, in perpetuity. So I am a bit reluctant. These things are a judgement call, and we don't have a good process for making that decision. A few of us have been talking about putting forward a better process; it'll be a few weeks. Meanwhile, what to do about ArgumentDo? You say | 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. Is there a wiki page that describes the proposal, and lists the "lot of reasons" why it would be a good thing? And lists any disadvantages? I'm not just erecting obstacles: the trouble with email is that it is long and discursive, so it's really hard to find all the relevant messages, and even if you do each message only makes sense if you read the long sequence. One question I have is this. Presumably f do stmts will be represented as HsApp (HsVar f) (HsDo ...stmts...) And should print without parens -- they are signalled by HsPar. So what about (HsApp (HsVar f) (HsDo ...stmts1..)) (HsDo ..stmts2..) How does that pretty-print. I suppose it should be f do stmts1 do stmts2 That is, it must use layout. But at the moment the pretty printer doesn't do that. Simon | -----Original Message----- | From: ghc-devs [mailto:ghc-devs-bounces@haskell.org] On Behalf Of Akio | Takano | Sent: 01 June 2016 23:26 | To: Bardur Arantsson | Cc: ghc-devs | Subject: Re: Moving ArgumentsDo forward | | 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 | > | https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fmail.h | > askell.org%2fcgi-bin%2fmailman%2flistinfo%2fghc- | devs&data=01%7c01%7csi | > | monpj%40064d.mgd.microsoft.com%7c738d83b44c5c4a806d4208d38a6bd2fe%7c72 | > | f988bf86f141af91ab2d7cd011db47%7c1&sdata=9gGIMGGJZgWFHueOeKUyIAzUaZuun | > %2b3PwKEzctMizss%3d | _______________________________________________ | ghc-devs mailing list | ghc-devs@haskell.org | https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fmail.h | askell.org%2fcgi-bin%2fmailman%2flistinfo%2fghc- | devs&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7c738d83b44c5c4a8 | 06d4208d38a6bd2fe%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=9gGIMGG | JZgWFHueOeKUyIAzUaZuun%2b3PwKEzctMizss%3d

I have put up an implementation: https://github.com/takano-akio/ghc/commits/argumentdo Shall I submit the patch on the Phabricator, or should this go through the new proposal submission process? Regards, Takano Akio On 4 July 2016 at 07:50, Akio Takano wrote:

Hi Simon,

I'm sorry about the late reply.

On 2 June 2016 at 07:19, Simon Peyton Jones wrote:

...

Akio

Thanks for bringing back the ArgumentsDo question.

My personal take on it is similar to Bardur:

...

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].

The benefit to me seems slight. The cost is also modest, but it is not zero (see below), even given a complete implementation. ANY feature carries a cost that is borne by every subsequent implementor, in perpetuity.

I understand your concern. I think this extension is worthwhile, but of course this should be ultimately decided on by people who actually maintain GHC.

...

So I am a bit reluctant.

These things are a judgement call, and we don't have a good process for making that decision. A few of us have been talking about putting forward a better process; it'll be a few weeks.

Meanwhile, what to do about ArgumentDo? You say

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

Is there a wiki page that describes the proposal, and lists the "lot of reasons" why it would be a good thing? And lists any disadvantages? I'm not just erecting obstacles: the trouble with email is that it is long and discursive, so it's really hard to find all the relevant messages, and even if you do each message only makes sense if you read the long sequence.

I made a wiki page: https://ghc.haskell.org/trac/ghc/wiki/ArgumentDo

...

One question I have is this. Presumably f do stmts will be represented as HsApp (HsVar f) (HsDo ...stmts...) And should print without parens -- they are signalled by HsPar. So what about (HsApp (HsVar f) (HsDo ...stmts1..)) (HsDo ..stmts2..) How does that pretty-print. I suppose it should be f do stmts1 do stmts2 That is, it must use layout. But at the moment the pretty printer doesn't do that.

It looks like the pretty printer always prints curly braces around do statements (ppr_do_stmts in hsSyn/HsExpr.hs), so perhaps this is not an issue?

- Akio

Thank you, but let me clarify that a significant portion of my patch was simply copied from Andrew Gibiansky's differential revision: https://phabricator.haskell.org/D1219 - Akio On 22 August 2016 at 05:35, Index Int wrote:

Thank you for making this effort! I am glad someone has finally implemented ArgumentDo. I hope your patch gets merged.

Hi Andrew, On 6 June 2016 at 16:37, Andrew Gibiansky wrote:

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]

Thank you for the clarification. I hope you don't mind that I pick up your proposal and use your code as a starting point.

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.

I actually found the response from people at haskell-cafe rather encouraging. To me a 50% support seems high enough to justify an implementation.

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.

Thank you. Unfortunately for my uses a separate preprocessor probably would have too much overhead.

[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

_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs