Moving ArgumentsDo forward

Andrew Gibiansky andrew.gibiansky at
Mon Jun 6 16:37:33 UTC 2016

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.



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

> Hi Bardur,
> On 2 June 2016 at 00:09, Bardur Arantsson <spam at> 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
> > 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
> >
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at

– Andrew
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the ghc-devs mailing list