Moving ArgumentsDo forward

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
12 messages Options
Reply | Threaded
Open this post in threaded view
|

Moving ArgumentsDo forward

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

Regards,
Takano Akio

[0]: https://ghc.haskell.org/trac/ghc/ticket/10843
[1]: https://phabricator.haskell.org/D1219
[2]: https://ghc.haskell.org/trac/ghc/ticket/10843#comment:12
_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

Re: Moving ArgumentsDo forward

Bardur Arantsson-2
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
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

Re: Moving ArgumentsDo forward

Edward Kmett-2
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 <[hidden email]> 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
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs


_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

Re: Moving ArgumentsDo forward

Baldur Blöndal
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 <[hidden email]>:

> 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 <[hidden email]>
> 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
>> [hidden email]
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>>
>
_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

Re: Moving ArgumentsDo forward

Akio Takano
In reply to this post by Bardur Arantsson-2
Hi Bardur,

On 2 June 2016 at 00:09, Bardur Arantsson <[hidden email]> 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
> [hidden email]
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

RE: 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:[hidden email]] On Behalf Of Akio
|  Takano
|  Sent: 01 June 2016 23:26
|  To: Bardur Arantsson <[hidden email]>
|  Cc: ghc-devs <[hidden email]>
|  Subject: Re: Moving ArgumentsDo forward
|  
|  Hi Bardur,
|  
|  On 2 June 2016 at 00:09, Bardur Arantsson <[hidden email]>
|  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
|  > [hidden email]
|  >
|  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
|  [hidden email]
|  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
_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

Re: Moving ArgumentsDo forward

Andrew Gibiansky
In reply to this post by Akio Takano
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.

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

Best,
Andrew

On Wed, Jun 1, 2016 at 3:26 PM Akio Takano <[hidden email]> wrote:
Hi Bardur,

On 2 June 2016 at 00:09, Bardur Arantsson <[hidden email]> 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
> [hidden email]
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
--

– Andrew


_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

Re: Moving ArgumentsDo forward

Akio Takano
In reply to this post by Simon Peyton Jones
Hi Simon,

I'm sorry about the late reply.

On 2 June 2016 at 07:19, Simon Peyton Jones <[hidden email]> 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
_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

Re: Moving ArgumentsDo forward

Akio Takano
In reply to this post by Andrew Gibiansky
Hi Andrew,

On 6 June 2016 at 16:37, Andrew Gibiansky <[hidden email]> 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_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 <[hidden email]> wrote:
>>
>> Hi Bardur,
>>
>> On 2 June 2016 at 00:09, Bardur Arantsson <[hidden email]> 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
>> > [hidden email]
>> > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>> _______________________________________________
>> ghc-devs mailing list
>> [hidden email]
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
> --
>
> – Andrew
>
>
> _______________________________________________
> ghc-devs mailing list
> [hidden email]
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

Re: Moving ArgumentsDo forward

Akio Takano
In reply to this post by Akio Takano
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 <[hidden email]> wrote:

> Hi Simon,
>
> I'm sorry about the late reply.
>
> On 2 June 2016 at 07:19, Simon Peyton Jones <[hidden email]> 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
_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

Re: Moving ArgumentsDo forward

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

On Mon, Aug 22, 2016 at 8:11 AM, Akio Takano <[hidden email]> wrote:
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


_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

Re: Moving ArgumentsDo forward

Akio Takano
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 <[hidden email]> wrote:
> Thank you for making this effort! I am glad someone has finally implemented
> ArgumentDo. I hope your patch gets merged.
_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs