Moving ArgumentsDo forward

[Simon Peyton Jones]

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 at haskell.org] On Behalf Of Akio
|  Takano
|  Sent: 01 June 2016 23:26
|  To: Bardur Arantsson <spam at scientician.net>
|  Cc: ghc-devs <ghc-devs at haskell.org>
|  Subject: Re: Moving ArgumentsDo forward
|  
|  Hi Bardur,
|  
|  On 2 June 2016 at 00:09, Bardur Arantsson <spam at 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 at 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 at 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