Proposal: ArgumentDo

older
Re: Glasgow-haskell-users Digest,...

Akio Takano

4 Jul 2016 4 Jul '16

6:31 a.m.

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

Show replies by date

David Luposchainsky

4 Jul 4 Jul

12:28 p.m.

Infix ($) is so noisy that I’ve adapted a code style that replaces it entirely with parentheses. And the hack to make ($) work with higher-rank types is pretty awkward too. Seen from these angles, I’m very much in favour of ArgumentDo. However, the clarity of `runST do ...` comes at a high price: only some of the missing ($) make the code clearer, where others make it much worse. You give a couple of examples yourself:

...

f do x do y

I have to think a bit how this might be parsed even after reading the proposal. I’m a bit torn on whether I like or not like it, but I think the ArgumentDo syntax that I find awkward now is a matter of style, and one could probably get used to only using it in certain places, despite all of the possibilities. David/quchen

C Maeder

6 Jul 6 Jul

12:08 p.m.

Hi, allowing group A constructs (do, case, ...) and group B constructs (\, let, if, ...) as parts of functions application (fexp) without extra parentheses looks natural to me. The current state is an artificial and unnecessary restriction. Style guides may dictate restrictions, but the parser/language should not (without good reasons). So +1 for the proposal from me. However, I would not distinguish group A and group B constructs in the proposed grammar rules. The report already states (for the group B constructs): "The grammar is ambiguous regarding the extent of lambda abstractions, let expressions, and conditionals. The ambiguity is resolved by the meta-rule that each of these constructs extends as far to the right as possible." Therefore I would simply add all constructs (that start with a unique keyword) to atomic expressions (aexp) where the term "atomic" might be misleading but is already accepted for the record constructs. For the group B constructs this simply means that they can only be the last argument (or the mere function itself) in any expression (exp). The non-terminal lexp is no longer needed (and could be replaced by fexp in infixexp). Furthermore group B constructs are also delimited by the layout rules (of decls). Cheers Christian Am 04.07.2016 um 12:31 schrieb Akio Takano:

...

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.

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

Akio Takano

10 Jul 10 Jul

9:33 p.m.

Hi Christian, On 6 July 2016 at 16:08, C Maeder wrote:

...

Hi,

allowing group A constructs (do, case, ...) and group B constructs (\, let, if, ...) as parts of functions application (fexp) without extra parentheses looks natural to me. The current state is an artificial and unnecessary restriction. Style guides may dictate restrictions, but the parser/language should not (without good reasons).

So +1 for the proposal from me.

However, I would not distinguish group A and group B constructs in the proposed grammar rules. The report already states (for the group B constructs): "The grammar is ambiguous regarding the extent of lambda abstractions, let expressions, and conditionals. The ambiguity is resolved by the meta-rule that each of these constructs extends as far to the right as possible."

This is a good point, I have updated the wiki page and simplified the grammar change. Thank you, Akio

Bardur Arantsson

6 Jul 6 Jul

1:39 p.m.

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. Regards, [1] Which I should think the barrier to extensions should roughly be :).

Evan Laforge

9:50 p.m.

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.

Carter Schonwald

7 Jul 7 Jul

1:15 p.m.

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

David Feuer

1:23 p.m.

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

Brandon Allbery

1:32 p.m.

Didn't they already say they disliked record syntax for exactly that reason? On Thu, Jul 7, 2016 at 1:23 PM, David Feuer wrote:

...

What makes

f do{x} do{y}

any harder to read than similar record syntax?

f Foo{foo=3} Foo{foo=4}

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

On Thu, Jul 7, 2016 at 1:15 PM, Carter Schonwald wrote: 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

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

-- brandon s allbery kf8nh sine nomine associates allbery.b@gmail.com ballbery@sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net

Carter Schonwald

1:44 p.m.

the fact that its perilously close to looking like *1 typo* away from a parser error about record syntax makes me *-1000* now thanks for pointing this out! On Thu, Jul 7, 2016 at 1:32 PM, Brandon Allbery wrote:

...

Didn't they already say they disliked record syntax for exactly that reason?

On Thu, Jul 7, 2016 at 1:23 PM, David Feuer wrote:

...
What makes

f do{x} do{y}

any harder to read than similar record syntax?

f Foo{foo=3} Foo{foo=4}

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

spam@scientician.net>

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

On Thu, Jul 7, 2016 at 1:15 PM, Carter Schonwald wrote: 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

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

-- brandon s allbery kf8nh sine nomine associates allbery.b@gmail.com ballbery@sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net

Sven Panne

8 Jul 8 Jul

2:35 a.m.

[ There is a trend to repeat one's argument about this proposed extension in various mailing lists/wiki pages/etc., so let's repeat myself, too... :-] 2016-07-07 19:44 GMT+02:00 Carter Schonwald :

...

the fact that its perilously close to looking like *1 typo* away from a parser error about record syntax makes me *-1000* now [...]

-1000 for exactly the same reason, and more: If you look at the "Block as a LHS" section on the wiki, things get insame IMHO: do f &&& g x should mean "(f &&& g) x"? It's probably 99% more likely that somebody didn't get the indentation right for the "do". And what about: foobar do f &&& g x Should the x now be an argument of foobar (as it is currently) or the "do"? If it is not an argument of the "do", suddenly things get very context-dependent. Computers are good at handling context-dependent things, humans are quite bad at it. Taking one step back: I think a lot of the discussion is based on the false assumption that "something can be parsed in an unambiguous way by some more or less random parsing technology" means "it can easily be parsed by a human". This is a fundamental misconception, otherwise reading programs in Brainfuck or Whitespace would be easy, too. In our case at hand, visually determining what is an argument of a function in a quick way is *supported* by some (perhaps) redundant syntactic stuff. That's exactly the reason why the current record syntax is a big mistake: Normally, an argument is beginning after a whitespace (unless there are other syntactic clues like '$', '(', etc.), but foo bar { baz = blah } runs against this intuition and one has to mentally backtrack. The proposal at hand would enshrine this kind of broken syntax in more places. As has already been said in another thread, the goal of language design is not to make writing correct programs easier (by allowing more and more syntax), but to make writing wrong programs harder. And a note about counting votes: I think normal democrating voting procedures simply don't apply here. Even if e.g. 80% of the voters find something OK while the other 20% find it confusing, the majority vote doesn't make the confusion of a fifth of the people go away. For a change like this, I would expect near unanimous consent, but I think we are very, very far away from that...

Joachim Breitner

3:09 a.m.

Hi, Am Freitag, den 08.07.2016, 08:35 +0200 schrieb Sven Panne:

...

foobar do f &&& g x

Should the x now be an argument of foobar (as it is currently) or the "do"? If it is not an argument of the "do", suddenly things get very context-dependent. Computers are good at handling context-dependent things, humans are quite bad at it.

What do you mean by “as it is currently”. Currently, this is a syntax error! (“parse error on input ‘do’”). Only with the proposed addition, it becomes an argument to foobar. And it is not hard to reason about this: "x" is lined up with the "do", so it is a sibling, not a child, in the AST. Hence, both are arguments to foobar. This is another good instance of how the (by me) beloved feature of “parenthesless arguments”, which so far is only available for the last argument of a function (using the “$” idiom), would now be possible for every argument of a function. Greetings, Joachim -- Joachim “nomeata” Breitner mail@joachim-breitner.de • https://www.joachim-breitner.de/ XMPP: nomeata@joachim-breitner.de • OpenPGP-Key: 0xF0FBF51F Debian Developer: nomeata@debian.org

C Maeder

5:20 a.m.

Surely layout can bite you: f do x do y and I'm having difficulties to find the documentation for the various layout options. But this is no argument against this proposal! Improper use of white spaces can always be used to obfuscate code! Style guides are important. Furthermore, a wrong/unintended parse tree (due to layout) will - in many cases - result in a typing error. Christian Am 08.07.2016 um 09:09 schrieb Joachim Breitner:

...

Hi,

Am Freitag, den 08.07.2016, 08:35 +0200 schrieb Sven Panne:

...
foobar do f &&& g x

Should the x now be an argument of foobar (as it is currently) or the "do"? If it is not an argument of the "do", suddenly things get very context-dependent. Computers are good at handling context-dependent things, humans are quite bad at it.

What do you mean by “as it is currently”. Currently, this is a syntax error! (“parse error on input ‘do’”).

Only with the proposed addition, it becomes an argument to foobar.

And it is not hard to reason about this: "x" is lined up with the "do", so it is a sibling, not a child, in the AST. Hence, both are arguments to foobar.

This is another good instance of how the (by me) beloved feature of “parenthesless arguments”, which so far is only available for the last argument of a function (using the “$” idiom), would now be possible for every argument of a function.

Greetings, Joachim

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

C Maeder

8:37 a.m.

New subject: layout was Re: Proposal: ArgumentDo

Hi, the layout language options are hard to find (at least in the user guide). Therefore I try to give an overview here. The relevant options I've found by using ghc-7.10.3 with option --supported-languages are: NondecreasingIndentation DoAndIfThenElse RelaxedLayout AlternativeLayoutRule AlternativeLayoutRuleTransitional I ignore the last 3 options since these seem to be candidates for removal: https://ghc.haskell.org/trac/ghc/ticket/11359. The default option is NondecreasingIndentation, that is do x do y is legal and parsed as a single expression "do {x ; do y}". With -XNoNondecreasingIndentation one gets an "Empty 'do' block" for the second do (and this error would not change with ArgumentDo!). DoAndIfThenElse is not switched on by default and requires the keywords "then" and "else" to be further indented for an "if" within a "do". So I believe these options do not interfere with ArgumentDo, but maybe this should be discussed more and maybe mentioned on the wiki page. Surely a single space (inserted before x or removed before the second "do") makes a difference between one or two argument expressions in the example below. HTH Christian Am 08.07.2016 um 11:20 schrieb C Maeder:

...

Surely layout can bite you:

f do x do y

and I'm having difficulties to find the documentation for the various layout options.

But this is no argument against this proposal!

Improper use of white spaces can always be used to obfuscate code! Style guides are important. Furthermore, a wrong/unintended parse tree (due to layout) will - in many cases - result in a typing error.

Christian

Sven Panne

5:32 a.m.

2016-07-08 9:09 GMT+02:00 Joachim Breitner :

...

Am Freitag, den 08.07.2016, 08:35 +0200 schrieb Sven Panne:

...
foobar do f &&& g x [...] Only with the proposed addition, it becomes an argument to foobar. [...]

Huh? Nope! The Wiki page explicitly says that do f &&& g x means (f &&& g) x Why should this be different here? Simply writing "foobar" above that construct won't trigger any special layout rules, I hope...

Joachim Breitner

6:28 a.m.

Hi, Am Freitag, den 08.07.2016, 11:32 +0200 schrieb Sven Panne:

...

2016-07-08 9:09 GMT+02:00 Joachim Breitner :

...
Am Freitag, den 08.07.2016, 08:35 +0200 schrieb Sven Panne:

...
foobar do f &&& g x [...] Only with the proposed addition, it becomes an argument to foobar. [...]

Huh? Nope! The Wiki page explicitly says that

do f &&& g x

means

(f &&& g) x

Why should this be different here? Simply writing "foobar" above that construct won't trigger any special layout rules, I hope...

I believe this follows from the existing layout rules. Currenlty, foobar (do f &&& g) x calls foobar with two arguments, while (do f &&& g) x calls (f &&& g) with one argument. The ArgumentDo proposal does not change that, only that the parenthesis become redundant. Greetings, Joachim -- -- Joachim “nomeata” Breitner mail@joachim-breitner.de • https://www.joachim-breitner.de/ XMPP: nomeata@joachim-breitner.de • OpenPGP-Key: 0xF0FBF51F Debian Developer: nomeata@debian.org

Sven Panne

7:09 a.m.

2016-07-08 12:28 GMT+02:00 Joachim Breitner :

...

Currenlty,

foobar (do f &&& g) x

calls foobar with two arguments, while

(do f &&& g) x

calls (f &&& g) with one argument. The ArgumentDo proposal does not change that, only that the parenthesis become redundant.

I don't think so: https://ghc.haskell.org/trac/ghc/wiki/ArgumentDo#BlockasaLHS explicit states that do f &&& g x parses as (f &&& g) x , so foobar do f &&& g x parses as foobar ((f &&& g) x) under the new proposal, which I find highly confusing. If it doesn't parse like this under the proposal, the wiki page is wrong and/or the proposal is not compositional: Why should being below "foobar" change the parse? "foobar" is not a keyword switching to some different mode.

Joachim Breitner

7:27 a.m.

Hi, Am Freitag, den 08.07.2016, 13:09 +0200 schrieb Sven Panne:

...

I don't think so: https://ghc.haskell.org/trac/ghc/wiki/ArgumentDo#Bl ockasaLHS explicit states that

do f &&& g x

parses as

(f &&& g) x

Correct

...

, so

foobar do f &&& g x

parses as

foobar ((f &&& g) x)

Where is the outer set of parenthesis coming from? This is all not related to the ArgumentDo notation. Note that (f &&& g) x parses as (f &&& g) x and still foobar (f &&& g) x parses as foobar (f &&& g) x just as foobar (f &&& g) x does. (NB: I consider foobar arg1 arg2 bad style and prefer foobar arg1 arg2 but the former is allowed now and will be allowed later as well.) Greetings, Joachim -- Joachim “nomeata” Breitner mail@joachim-breitner.de • https://www.joachim-breitner.de/ XMPP: nomeata@joachim-breitner.de • OpenPGP-Key: 0xF0FBF51F Debian Developer: nomeata@debian.org

Henrik Nilsson

8 a.m.

Hi all, Joachim Breitner wrote:

...

Am Freitag, den 08.07.2016, 13:09 +0200 schrieb Sven Panne:

...
I don't think so: https://ghc.haskell.org/trac/ghc /wiki/ArgumentDo#Bl [...] Where is the outer set of parenthesis coming from?

This is all not related to the ArgumentDo notation. Note that [...]

The very fact that that experts can't easily agree on how a small Haskell fragment is parsed to me just confirms that Haskell already is a syntactically very cumbersome language. The present proposal just makes matters worse. For that reason alone, I don't find it compelling at all. (So -1 from me, then.) I will not repeat the many other strong arguments against that has been made. But I must say I don't find the use cases as documented on the associated web page compelling at all. Maybe there is a tacit desire to be able to pretend functions are keywords for various creative uses in supporting EDSLs and such. But for that to be truly useful, one need to support groups of related keywords. Something like Agda's mixfix syntax springs to mind. But this proposal does not come close, so the benefits are minimal and the drawbacks large. As a final point, the inherent asymmetry of the proposal (the last argument position is special as, for certain kinds of expressions, parentheses may be omitted there but not elsewhere) is also deeply unsettling. Best, /Henrik -- Henrik Nilsson School of Computer Science The University of Nottingham nhn@cs.nott.ac.uk This message and any attachment are intended solely for the addressee and may contain confidential information. If you have received this message in error, please send it back to me, and immediately delete it. Please do not use, copy or disclose the information contained in this message or in any attachment. Any views or opinions expressed by the author of this email do not necessarily reflect the views of the University of Nottingham. This message has been checked for viruses but the contents of an attachment may still contain software viruses which could damage your computer system, you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation.

Aloïs Cochard

8:03 a.m.

-1 for same reasons. On 8 July 2016 at 14:00, Henrik Nilsson wrote:

...

Hi all,

Joachim Breitner wrote:

...
Am Freitag, den 08.07.2016, 13:09 +0200 schrieb Sven Panne:

...
I don't think so: https://ghc.haskell.org/trac/ghc /wiki/ArgumentDo#Bl [...] Where is the outer set of parenthesis coming from?

This is all not related to the ArgumentDo notation. Note that [...]

The very fact that that experts can't easily agree on how a small Haskell fragment is parsed to me just confirms that Haskell already is a syntactically very cumbersome language.

The present proposal just makes matters worse. For that reason alone, I don't find it compelling at all. (So -1 from me, then.)

I will not repeat the many other strong arguments against that has been made. But I must say I don't find the use cases as documented on the associated web page compelling at all. Maybe there is a tacit desire to be able to pretend functions are keywords for various creative uses in supporting EDSLs and such. But for that to be truly useful, one need to support groups of related keywords. Something like Agda's mixfix syntax springs to mind. But this proposal does not come close, so the benefits are minimal and the drawbacks large.

As a final point, the inherent asymmetry of the proposal (the last argument position is special as, for certain kinds of expressions, parentheses may be omitted there but not elsewhere) is also deeply unsettling.

Best,

/Henrik

-- Henrik Nilsson School of Computer Science The University of Nottingham nhn@cs.nott.ac.uk

This message and any attachment are intended solely for the addressee and may contain confidential information. If you have received this message in error, please send it back to me, and immediately delete it. Please do not use, copy or disclose the information contained in this message or in any attachment. Any views or opinions expressed by the author of this email do not necessarily reflect the views of the University of Nottingham.

This message has been checked for viruses but the contents of an attachment may still contain software viruses which could damage your computer system, you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation.

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

-- *Λ\oïs* http://twitter.com/aloiscochard http://github.com/aloiscochard

Iavor Diatchki

12:42 p.m.

Hello, while we are voting here, I kind of like this proposal, so +1 for me. I understand that some of the examples look strange to Haskell old-timers but, as Joachim points out, the behavior is very consistent. Besides, the "Less Obvious Examples" were selected so that they are, well, less obvious. The common use cases (as in ticket #10843) seem quite appealing, at least to me, and not at all confusing. But, then, I also like the records-with-no-parens notation :-) -Iavor On Fri, Jul 8, 2016 at 5:03 AM, Aloïs Cochard wrote:

...

-1 for same reasons.

On 8 July 2016 at 14:00, Henrik Nilsson wrote:

...
Hi all,

Joachim Breitner wrote:

...
Am Freitag, den 08.07.2016, 13:09 +0200 schrieb Sven Panne:

...
I don't think so: https://ghc.haskell.org/trac/ghc /wiki/ArgumentDo#Bl [...] Where is the outer set of parenthesis coming from?

This is all not related to the ArgumentDo notation. Note that [...]

The very fact that that experts can't easily agree on how a small Haskell fragment is parsed to me just confirms that Haskell already is a syntactically very cumbersome language.

The present proposal just makes matters worse. For that reason alone, I don't find it compelling at all. (So -1 from me, then.)

I will not repeat the many other strong arguments against that has been made. But I must say I don't find the use cases as documented on the associated web page compelling at all. Maybe there is a tacit desire to be able to pretend functions are keywords for various creative uses in supporting EDSLs and such. But for that to be truly useful, one need to support groups of related keywords. Something like Agda's mixfix syntax springs to mind. But this proposal does not come close, so the benefits are minimal and the drawbacks large.

As a final point, the inherent asymmetry of the proposal (the last argument position is special as, for certain kinds of expressions, parentheses may be omitted there but not elsewhere) is also deeply unsettling.

Best,

/Henrik

-- Henrik Nilsson School of Computer Science The University of Nottingham nhn@cs.nott.ac.uk

This message and any attachment are intended solely for the addressee and may contain confidential information. If you have received this message in error, please send it back to me, and immediately delete it. Please do not use, copy or disclose the information contained in this message or in any attachment. Any views or opinions expressed by the author of this email do not necessarily reflect the views of the University of Nottingham.

This message has been checked for viruses but the contents of an attachment may still contain software viruses which could damage your computer system, you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation.

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

-- *Λ\oïs* http://twitter.com/aloiscochard http://github.com/aloiscochard

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

C Maeder

9 Jul 9 Jul

3:09 a.m.

The asymmetry that you mention is already apparent for (Haskell98) infix expressions, i.e. when "composing" lambda- or if-expression: (if c then f else g) . \ x -> h x Parentheses around the last argument of "." do not matter, but parentheses around the first argument make a real difference (that the type checker will not detect)! Cheers Christian Am 08.07.2016 um 14:00 schrieb Henrik Nilsson:

...

Hi all,

[...]

...

As a final point, the inherent asymmetry of the proposal (the last argument position is special as, for certain kinds of expressions, parentheses may be omitted there but not elsewhere) is also deeply unsettling.

Best,

/Henrik

Bardur Arantsson

3:42 a.m.

On 07/09/2016 09:09 AM, C Maeder wrote:

...

The asymmetry that you mention is already apparent for (Haskell98) infix expressions, i.e. when "composing" lambda- or if-expression:

(if c then f else g) . \ x -> h x

Parentheses around the last argument of "." do not matter, but parentheses around the first argument make a real difference (that the type checker will not detect)!

What I'm reading here is essentially "Parser already does non-obvious thing" ===> "Adding more non-obvious things is fine!" This is simply bad reasoning, and I'm not sure why a number of people are saying it. Am I missing something? Regards,

Henrik Nilsson

5:46 a.m.

Hi all, On 07/09/2016 08:09 AM, C Maeder wrote:

...

The asymmetry that you mention is already apparent for (Haskell98) infix expressions, i.e. when "composing" lambda- or if-expression:

(if c then f else g) . \ x -> h x

Parentheses around the last argument of "." do not matter, but parentheses around the first argument make a real difference

But that has to do with how grammatical ambiguity related to in this case "if" and "lambda" are resolved by letting the constructs extend as far as possible to the right. This the standard way of resolving that kind of ambiguity across a very wide range of programming languages and parsing tools (e.g. preferring shift over reduce in an LR parser). (And also in principle how lexical ambiguities are typically resolved, sometimes referred to as the "maximal munch rule".) In contrast, the present proposal suggests treating different argument positions in grammatically different ways (different non-terminals). As far as I know, that is unprecedented. And in any case, it manifestly complicates the grammar (more non-terminals) and as a consequence adds another grammatical hurdle to learning the language. I think we often tend to forget just how exotic Haskell syntax can be to the uninitiated. Which is the vast majority of the rest of the programmer world as well as beginners. Only the other week I gave a presentation to a group of highly skilled developers at a tech-savvy London-based company. The emphasis of the talk was not at all on Haskell as such, but small Haskell fragments did feature here and there, which I (naively) thought would be mostly self explanatory. Well, let's just say I was wrong. Now, we can't make Haskell syntax less exotic (not that I'd advocate that: I think basic Haskell syntax for the most part strikes a pretty good balance on a number of counts), but we can certainly avoid making it even more complicated and exotic. Which the present proposal would, in my opinion. Best, /Henrik -- Henrik Nilsson School of Computer Science The University of Nottingham nhn@cs.nott.ac.uk This message and any attachment are intended solely for the addressee and may contain confidential information. If you have received this message in error, please send it back to me, and immediately delete it. Please do not use, copy or disclose the information contained in this message or in any attachment. Any views or opinions expressed by the author of this email do not necessarily reflect the views of the University of Nottingham. This message has been checked for viruses but the contents of an attachment may still contain software viruses which could damage your computer system, you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation.

Carter Schonwald

8:45 a.m.

On Saturday, July 9, 2016, Henrik Nilsson wrote:

...

Hi all,

On 07/09/2016 08:09 AM, C Maeder wrote:

...
The asymmetry that you mention is already apparent for (Haskell98) infix expressions, i.e. when "composing" lambda- or if-expression:

(if c then f else g) . \ x -> h x

Parentheses around the last argument of "." do not matter, but parentheses around the first argument make a real difference

But that has to do with how grammatical ambiguity related to in this case "if" and "lambda" are resolved by letting the constructs extend as far as possible to the right.

This the standard way of resolving that kind of ambiguity across a very wide range of programming languages and parsing tools (e.g. preferring shift over reduce in an LR parser). (And also in principle how lexical ambiguities are typically resolved, sometimes referred to as the "maximal munch rule".)

In contrast, the present proposal suggests treating different argument positions in grammatically different ways (different non-terminals). As far as I know, that is unprecedented. And in any case, it manifestly complicates the grammar (more non-terminals) and as a consequence adds another grammatical hurdle to learning the language.

Well said, I think this articulates exactly what I'm reacting to. Thanks for taking the time to articulate this. I agree.

...

I think we often tend to forget just how exotic Haskell syntax can be to the uninitiated. Which is the vast majority of the rest of the programmer world as well as beginners. Only the other week I gave a presentation to a group of highly skilled developers at a tech-savvy London-based company. The emphasis of the talk was not at all on Haskell as such, but small Haskell fragments did feature here and there, which I (naively) thought would be mostly self explanatory. Well, let's just say I was wrong.

Now, we can't make Haskell syntax less exotic (not that I'd advocate that: I think basic Haskell syntax for the most part strikes a pretty good balance on a number of counts), but we can certainly avoid making it even more complicated and exotic. Which the present proposal would, in my opinion.

Best,

/Henrik

-- Henrik Nilsson School of Computer Science The University of Nottingham nhn@cs.nott.ac.uk

This message and any attachment are intended solely for the addressee and may contain confidential information. If you have received this message in error, please send it back to me, and immediately delete it. Please do not use, copy or disclose the information contained in this message or in any attachment. Any views or opinions expressed by the author of this email do not necessarily reflect the views of the University of Nottingham.

This message has been checked for viruses but the contents of an attachment may still contain software viruses which could damage your computer system, you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation.

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

C Maeder

10 Jul 10 Jul

5:28 a.m.

Hi Hendrik, juxtaposition (of grammar non-terminals aexp) is function application in Haskell. Why does an explicit infix operator make such a big difference for you? (if c then f else g) $ if d then a else b (if c then f else g) if d then a else b The keyword "if" starts a new expression. Nobody would wrongly parse this as "(...(if c then f else g) if)...)", because also nobody parses "... then a else b" wrongly as "... ((then a) else) b)". Actually, I see less rather than more non-terminals (no lexp) in the grammar and no additional ambiguity. Cheers Christian Am 09.07.2016 um 11:46 schrieb Henrik Nilsson:

...

Hi all,

On 07/09/2016 08:09 AM, C Maeder wrote:

...
The asymmetry that you mention is already apparent for (Haskell98) infix expressions, i.e. when "composing" lambda- or if-expression:

(if c then f else g) . \ x -> h x

Parentheses around the last argument of "." do not matter, but parentheses around the first argument make a real difference

But that has to do with how grammatical ambiguity related to in this case "if" and "lambda" are resolved by letting the constructs extend as far as possible to the right.

This the standard way of resolving that kind of ambiguity across a very wide range of programming languages and parsing tools (e.g. preferring shift over reduce in an LR parser). (And also in principle how lexical ambiguities are typically resolved, sometimes referred to as the "maximal munch rule".)

In contrast, the present proposal suggests treating different argument positions in grammatically different ways (different non-terminals). As far as I know, that is unprecedented. And in any case, it manifestly complicates the grammar (more non-terminals) and as a consequence adds another grammatical hurdle to learning the language.

I think we often tend to forget just how exotic Haskell syntax can be to the uninitiated. Which is the vast majority of the rest of the programmer world as well as beginners. Only the other week I gave a presentation to a group of highly skilled developers at a tech-savvy London-based company. The emphasis of the talk was not at all on Haskell as such, but small Haskell fragments did feature here and there, which I (naively) thought would be mostly self explanatory. Well, let's just say I was wrong.

Now, we can't make Haskell syntax less exotic (not that I'd advocate that: I think basic Haskell syntax for the most part strikes a pretty good balance on a number of counts), but we can certainly avoid making it even more complicated and exotic. Which the present proposal would, in my opinion.

Best,

/Henrik

C Maeder

5:30 a.m.

Hi Henrik apologize my "d" in your name below. Am 10.07.2016 um 11:28 schrieb C Maeder:

...

Hi Hendrik,

juxtaposition (of grammar non-terminals aexp) is function application in Haskell.

Why does an explicit infix operator make such a big difference for you?

(if c then f else g) $ if d then a else b

(if c then f else g) if d then a else b

The keyword "if" starts a new expression. Nobody would wrongly parse this as "(...(if c then f else g) if)...)", because also nobody parses "... then a else b" wrongly as "... ((then a) else) b)".

Actually, I see less rather than more non-terminals (no lexp) in the grammar and no additional ambiguity.

Cheers Christian

Am 09.07.2016 um 11:46 schrieb Henrik Nilsson:

...
Hi all,

On 07/09/2016 08:09 AM, C Maeder wrote:

...
The asymmetry that you mention is already apparent for (Haskell98) infix expressions, i.e. when "composing" lambda- or if-expression:

(if c then f else g) . \ x -> h x

Parentheses around the last argument of "." do not matter, but parentheses around the first argument make a real difference

But that has to do with how grammatical ambiguity related to in this case "if" and "lambda" are resolved by letting the constructs extend as far as possible to the right.

This the standard way of resolving that kind of ambiguity across a very wide range of programming languages and parsing tools (e.g. preferring shift over reduce in an LR parser). (And also in principle how lexical ambiguities are typically resolved, sometimes referred to as the "maximal munch rule".)

In contrast, the present proposal suggests treating different argument positions in grammatically different ways (different non-terminals). As far as I know, that is unprecedented. And in any case, it manifestly complicates the grammar (more non-terminals) and as a consequence adds another grammatical hurdle to learning the language.

I think we often tend to forget just how exotic Haskell syntax can be to the uninitiated. Which is the vast majority of the rest of the programmer world as well as beginners. Only the other week I gave a presentation to a group of highly skilled developers at a tech-savvy London-based company. The emphasis of the talk was not at all on Haskell as such, but small Haskell fragments did feature here and there, which I (naively) thought would be mostly self explanatory. Well, let's just say I was wrong.

Now, we can't make Haskell syntax less exotic (not that I'd advocate that: I think basic Haskell syntax for the most part strikes a pretty good balance on a number of counts), but we can certainly avoid making it even more complicated and exotic. Which the present proposal would, in my opinion.

Best,

/Henrik

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

Sven Panne

11 Jul 11 Jul

2:31 a.m.

2016-07-10 11:28 GMT+02:00 C Maeder :

...

[...] Why does an explicit infix operator make such a big difference for you?

(if c then f else g) $ if d then a else b

(if c then f else g) if d then a else b [...]

Because at first glance, this is visually only a tiny fraction away from (if c then f else g) it d them a elsa b which would be parsed in a totally different way. (Personally, I think that if/then/else is useless in Haskell and just a concession for readers from other programming languages. Having a plain old "if" function would have done the job in a more consistent way.) Of course syntax highlighting improves readability here, but code should be easily digestible in black and white, too. Visual clues matter...

Joachim Breitner

3:45 a.m.

Hi, Am Montag, den 11.07.2016, 08:31 +0200 schrieb Sven Panne:

...

Because at first glance, this is visually only a tiny fraction away from (if c then f else g) it d them a elsa b

which would be parsed in a totally different way. (Personally, I think that if/then/else is useless in Haskell and just a concession for readers from other programming languages. Having a plain old "if" function would have done the job in a more consistent way.) Of course syntax highlighting improves readability here, but code should be easily digestible in black and white, too. Visual clues matter...

I believe we can and should expect programmers to know the keywords (there are not many of them) and should _not_ compromise other goals for “makes similar sense even if a keyword is mistake or mistyped as a symbol name”. Greetings, Joachim -- Joachim “nomeata” Breitner mail@joachim-breitner.de • https://www.joachim-breitner.de/ XMPP: nomeata@joachim-breitner.de • OpenPGP-Key: 0xF0FBF51F Debian Developer: nomeata@debian.org

C Maeder

4:27 a.m.

Hi Sven, a wrongly spelled keyword will soon be detected by the checker in either cases. Readability is the responsibility of programmers. It is up to you or a team to use parentheses for the examples below. (I find a line break and indentation to be sufficient.) (I know people - mostly beginners - that insist on using "if b then True else False" instead of "b" for readability reasons.) Surely, a grammar could enforce more redundancy, but this is usually considered as an annoyance (in particular for instance distant closing tags that are more or less hidden in a pile of other closing tags). The $-notation was (in the first place) only used (and maybe misused) to avoid additional parentheses. Haskell's strong typing is the major safeguard (against spelling errors). Cheers Christian Am 11.07.2016 um 08:31 schrieb Sven Panne:

...

2016-07-10 11:28 GMT+02:00 C Maeder mailto:chr.maeder@web.de>:

[...] Why does an explicit infix operator make such a big difference for you?

(if c then f else g) $ if d then a else b

(if c then f else g) if d then a else b [...]

Because at first glance, this is visually only a tiny fraction away from

(if c then f else g) it d them a elsa b

which would be parsed in a totally different way. (Personally, I think that if/then/else is useless in Haskell and just a concession for readers from other programming languages. Having a plain old "if" function would have done the job in a more consistent way.) Of course syntax highlighting improves readability here, but code should be easily digestible in black and white, too. Visual clues matter...

Akio Takano

10 Jul 10 Jul

10:06 p.m.

Hi Henrik, On 9 July 2016 at 09:46, Henrik Nilsson wrote:

...

Hi all,

On 07/09/2016 08:09 AM, C Maeder wrote:

...
The asymmetry that you mention is already apparent for (Haskell98) infix expressions, i.e. when "composing" lambda- or if-expression:

(if c then f else g) . \ x -> h x

Parentheses around the last argument of "." do not matter, but parentheses around the first argument make a real difference

But that has to do with how grammatical ambiguity related to in this case "if" and "lambda" are resolved by letting the constructs extend as far as possible to the right.

This the standard way of resolving that kind of ambiguity across a very wide range of programming languages and parsing tools (e.g. preferring shift over reduce in an LR parser). (And also in principle how lexical ambiguities are typically resolved, sometimes referred to as the "maximal munch rule".)

In contrast, the present proposal suggests treating different argument positions in grammatically different ways (different non-terminals). As far as I know, that is unprecedented. And in any case, it manifestly complicates the grammar (more non-terminals) and as a consequence adds another grammatical hurdle to learning the language.

Thank you for pointing this out. I have updated the proposal so that it doesn't introduce a new non-terminal. I'm not sure if it should be implemented this way in the GHC parser, but this is probably a separate question. - Akio

Joachim Breitner

7 Jul 7 Jul

2:50 p.m.

Hi, Am Donnerstag, den 07.07.2016, 13:15 -0400 schrieb Carter Schonwald:

...

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,

It is weird to me, but in no way confusing under the simple new rules, and I am actually looking forward to using that, and also to reading code with that. In fact, everything I wanted to pass two arguments in do-notation to a function I felt at a loss. The prospect of itemizing multiple large arguments to a function by writing someFunctionWithManyArguments do firstArgument do second Argument which may span several lines do third Argument is actually making me happy! It feels like going from XML to YAML... Greetings, Joachim -- Joachim “nomeata” Breitner mail@joachim-breitner.de • https://www.joachim-breitner.de/ XMPP: nomeata@joachim-breitner.de • OpenPGP-Key: 0xF0FBF51F Debian Developer: nomeata@debian.org

Ryan Trinkle

3:40 p.m.

I'm very on the fence on this topic, but one point i haven't seen mentioned is the influence of syntax highlighting on this. My guess is that I would like this extension when I have syntax highlighting available and would dislike it when I do not. Also, I agree with Carter about the record update syntax - I find it harder to parse visually than most other parts of the language, and I expect I'd find curly brace syntax for inline 'do' harder to parse in a similar way. On the other hand, maybe I should get used to both... On Thu, Jul 7, 2016 at 2:50 PM, Joachim Breitner wrote:

...

Hi,

Am Donnerstag, den 07.07.2016, 13:15 -0400 schrieb Carter Schonwald:

...
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,

It is weird to me, but in no way confusing under the simple new rules, and I am actually looking forward to using that, and also to reading code with that.

In fact, everything I wanted to pass two arguments in do-notation to a function I felt at a loss. The prospect of itemizing multiple large arguments to a function by writing

someFunctionWithManyArguments do firstArgument do second Argument which may span several lines do third Argument

is actually making me happy! It feels like going from XML to YAML...

Greetings, Joachim

--

Joachim “nomeata” Breitner mail@joachim-breitner.de • https://www.joachim-breitner.de/ XMPP: nomeata@joachim-breitner.de • OpenPGP-Key: 0xF0FBF51F Debian Developer: nomeata@debian.org _______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

Akio Takano

10 Jul 10 Jul

9:53 p.m.

Hi Ryan, On 7 July 2016 at 19:40, Ryan Trinkle wrote:

...

I'm very on the fence on this topic, but one point i haven't seen mentioned is the influence of syntax highlighting on this. My guess is that I would like this extension when I have syntax highlighting available and would dislike it when I do not.

vim and hscolour can highlight code with the new syntax just fine. I imagine that most existing syntax highlighter will be able to deal with the new syntax without needing to be updated, because they usually don't attempt to fully parse expressions: they mostly just pattern-match on tokens. - Akio

...

Also, I agree with Carter about the record update syntax - I find it harder to parse visually than most other parts of the language, and I expect I'd find curly brace syntax for inline 'do' harder to parse in a similar way. On the other hand, maybe I should get used to both...

On Thu, Jul 7, 2016 at 2:50 PM, Joachim Breitner wrote:

...
Hi,

Am Donnerstag, den 07.07.2016, 13:15 -0400 schrieb Carter Schonwald:

...
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,

It is weird to me, but in no way confusing under the simple new rules, and I am actually looking forward to using that, and also to reading code with that.

In fact, everything I wanted to pass two arguments in do-notation to a function I felt at a loss. The prospect of itemizing multiple large arguments to a function by writing

someFunctionWithManyArguments do firstArgument do second Argument which may span several lines do third Argument

is actually making me happy! It feels like going from XML to YAML...

Greetings, Joachim

--

Joachim “nomeata” Breitner mail@joachim-breitner.de • https://www.joachim-breitner.de/ XMPP: nomeata@joachim-breitner.de • OpenPGP-Key: 0xF0FBF51F Debian Developer: nomeata@debian.org _______________________________________________ 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

Ryan Trinkle

10:07 p.m.

Akio, Yes, definitely! I think I was a bit unclear, but what I was trying to say was that, in the (rare) circumstances in which I'm editing Haskell without the benefit of syntax highlighting, the difference between keywords and identifiers is not quite as obvious. In those cases, requiring an operator may make things easier to read. This is a very small point, but I appreciate you taking the time to respond! Ryan On Sun, Jul 10, 2016 at 9:53 PM, Akio Takano wrote:

...

Hi Ryan,

On 7 July 2016 at 19:40, Ryan Trinkle wrote:

...
I'm very on the fence on this topic, but one point i haven't seen mentioned is the influence of syntax highlighting on this. My guess is that I would like this extension when I have syntax highlighting available and would dislike it when I do not.

vim and hscolour can highlight code with the new syntax just fine. I imagine that most existing syntax highlighter will be able to deal with the new syntax without needing to be updated, because they usually don't attempt to fully parse expressions: they mostly just pattern-match on tokens.

- Akio

...
Also, I agree with Carter about the record update syntax - I find it

harder

...
to parse visually than most other parts of the language, and I expect I'd find curly brace syntax for inline 'do' harder to parse in a similar way. On the other hand, maybe I should get used to both...

On Thu, Jul 7, 2016 at 2:50 PM, Joachim Breitner < mail@joachim-breitner.de> wrote:

...
Hi,

Am Donnerstag, den 07.07.2016, 13:15 -0400 schrieb Carter Schonwald:

...
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,

It is weird to me, but in no way confusing under the simple new rules, and I am actually looking forward to using that, and also to reading code with that.

In fact, everything I wanted to pass two arguments in do-notation to a function I felt at a loss. The prospect of itemizing multiple large arguments to a function by writing

someFunctionWithManyArguments do firstArgument do second Argument which may span several lines do third Argument

is actually making me happy! It feels like going from XML to YAML...

Greetings, Joachim

--

Joachim “nomeata” Breitner mail@joachim-breitner.de • https://www.joachim-breitner.de/ XMPP: nomeata@joachim-breitner.de • OpenPGP-Key: 0xF0FBF51F Debian Developer: nomeata@debian.org _______________________________________________ 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

Jon Purdy

7 Jul 7 Jul

4:46 p.m.

...

ambiguity is bad for humans, not just parsers.

This is not ambiguous. It’s removing the need for a redundant set of parentheses, whichever way you slice it. Of course, some redundancy is useful for readability (look at natural language), but you should really be explicit if you’re arguing from that position.

...

perhaps most damningly,

...
f do{ x } do { y }

is just reallly really weird/confusing to me

By “weird”, do you mean anything other than “I don’t understand it, and I blame it”? Can you give an example of how you might misparse it, as a human reader?

...

...
It's harder to read than the alternative.

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

It’s only a language extension for backward compatibility. It’s really fixing a bug in the grammar.

...

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

This would be a simplification of the parser if the bug hadn’t been standardised originally.

Carter Schonwald

6:40 p.m.

Can you walk me through how this simplifies the grammar etc in concrete compare contrast or what the diffs between the grammar and associated engineering would be? I don't see how it simplifies the grammar, but I could be a bit obtuse. That aside, I'm also a bit fuzzy on the other claim, that this change will simplify post parsing engineering, On Jul 7, 2016 4:47 PM, "Jon Purdy" wrote:

...

...
ambiguity is bad for humans, not just parsers.

This is not ambiguous. It’s removing the need for a redundant set of parentheses, whichever way you slice it. Of course, some redundancy is useful for readability (look at natural language), but you should really be explicit if you’re arguing from that position.

...
perhaps most damningly,

...
f do{ x } do { y }

is just reallly really weird/confusing to me

By “weird”, do you mean anything other than “I don’t understand it, and I blame it”? Can you give an example of how you might misparse it, as a human reader?

...
...
It's harder to read than the alternative.

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

It’s only a language extension for backward compatibility. It’s really fixing a bug in the grammar.

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

This would be a simplification of the parser if the bug hadn’t been standardised originally.

3235

Age (days ago)

3242

Last active (days ago)

List overview

Download

36 comments

15 participants

participants (15)

Akio Takano
Aloïs Cochard
Bardur Arantsson
Brandon Allbery
C Maeder
Carter Schonwald
David Feuer
David Luposchainsky
Evan Laforge
Henrik Nilsson
Iavor Diatchki
Joachim Breitner
Jon Purdy
Ryan Trinkle
Sven Panne