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 <ekm...@gmail.com>: > 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 <s...@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? 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 >> > _______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs