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