Re: Proposal: ArgumentDo

What makes f do{x} do{y} any harder to read than similar record syntax? f Foo{foo=3} Foo{foo=4} On Thu, Jul 7, 2016 at 1:15 PM, Carter Schonwald wrote:

agreed -1, ambiguity is bad for humans, not just parsers.

perhaps most damningly,

...

f do{ x } do { y }

is just reallly really weird/confusing to me, and as the proposal itself says at the end as the cons:

...

It's harder to read than the alternative.

Creating a language extension to get rid of a single character is overkill and unnecessary.

You can already get rid of the $ by just adding parentheses.

which kinda kills any benefit in my mind. thats a HUGE complexity vs alternative ratio. I'm all in favor of doing engineering work to *improve* our parser error messages and suggestions, but not stuff that complicates parsing for humans as well as machines

On Wed, Jul 6, 2016 at 9:50 PM, Evan Laforge wrote:

...

On Wed, Jul 6, 2016 at 10:39 AM, Bardur Arantsson wrote:

...

On 07/04/2016 12:31 PM, Akio Takano wrote:

...

Hi glasgow-haskell-users,

I have written a wiki page about a proposed extension called ArgumentDo. It's a small syntactic extension that allows "do" expressions, lambdas and a few other kinds of expressions to be used as function arguments, without parentheses.

https://ghc.haskell.org/trac/ghc/wiki/ArgumentDo

Any feedback is appreciated. In particular, since the idea has received mixed support (see the "Discussion" section on the wiki page), I'd like to make sure that there is enough support for this feature to justify an implementation in GHC.

-1

Reasons have already been given in previous threads on this. However, I'd point especially to the fact that people don't *agree* that this is more readable as a very strong point against -- regardless of whether any one individual thinks it's more readable or not. The point is the there seems to be a lot of disagreement -- that indicates to me that this cannot by definition be a "clear win"[1]. Disclosure: I personally find it less readable because of the implicitness. Implicitness which has a non-trivial probability of affecting semantics is bad in my book. Frankly, if it came to it, I'd rather just remove $ and deal with the parentheses.

I'm -1 because I think there are already too many styles. So I don't agree with the general sentiment that the parser should accept lots of stuff and to rely on style guides to specify something, because in practice everyone has their own style guide.

I trained myself to see juxtaposition as highest precedence (which newcomers still struggle over) and it's confusing to see juxtaposition that has higher precedence because one of them is a keyword. In the same way I'm confused by 'f a { b = c }', but it's too late to change that one. I suppose this is already on the wiki page in the "cons" section. _______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

_______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users