Proposal: ArgumentDo

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
37 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Proposal: ArgumentDo

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
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: ArgumentDo

Haskell - Glasgow-haskell-users mailing list
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
_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: ArgumentDo

C Maeder-2
In reply to this post by Akio Takano
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
> [hidden email]
> http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
>

_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: ArgumentDo

Bardur Arantsson-2
In reply to this post by Akio Takano
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 :).

_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: ArgumentDo

Evan Laforge
On Wed, Jul 6, 2016 at 10:39 AM, Bardur Arantsson <[hidden email]> 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
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: ArgumentDo

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, 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 <[hidden email]> wrote:
On Wed, Jul 6, 2016 at 10:39 AM, Bardur Arantsson <[hidden email]> 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
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users


_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: ArgumentDo

David Feuer
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
<[hidden email]> 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 <[hidden email]> wrote:
>>
>> On Wed, Jul 6, 2016 at 10:39 AM, Bardur Arantsson <[hidden email]>
>> 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
>> [hidden email]
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
>
>
>
> _______________________________________________
> Glasgow-haskell-users mailing list
> [hidden email]
> http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
>
_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: ArgumentDo

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

On Thu, Jul 7, 2016 at 1:23 PM, David Feuer <[hidden email]> wrote:
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
<[hidden email]> 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 <[hidden email]> wrote:
>>
>> On Wed, Jul 6, 2016 at 10:39 AM, Bardur Arantsson <[hidden email]>
>> 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
>> [hidden email]
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
>
>
>
> _______________________________________________
> Glasgow-haskell-users mailing list
> [hidden email]
> http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
>
_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users



--
brandon s allbery kf8nh                               sine nomine associates
[hidden email]                                  [hidden email]
unix, openafs, kerberos, infrastructure, xmonad        http://sinenomine.net

_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: ArgumentDo

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

thanks for pointing this out! 

On Thu, Jul 7, 2016 at 1:32 PM, Brandon Allbery <[hidden email]> 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 <[hidden email]> wrote:
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
<[hidden email]> 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 <[hidden email]> wrote:
>>
>> On Wed, Jul 6, 2016 at 10:39 AM, Bardur Arantsson <[hidden email]>
>> 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
>> [hidden email]
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
>
>
>
> _______________________________________________
> Glasgow-haskell-users mailing list
> [hidden email]
> http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
>
_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users



--
brandon s allbery kf8nh                               sine nomine associates
[hidden email]                                  [hidden email]
unix, openafs, kerberos, infrastructure, xmonad        http://sinenomine.net


_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: ArgumentDo

Joachim Breitner-2
In reply to this post by Carter Schonwald
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
  [hidden email]https://www.joachim-breitner.de/
  XMPP: [hidden email] • OpenPGP-Key: 0xF0FBF51F
  Debian Developer: [hidden email]
_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

signature.asc (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: ArgumentDo

Ryan Trinkle-3
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 <[hidden email]> 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
  [hidden email]https://www.joachim-breitner.de/
  XMPP: [hidden email] • OpenPGP-Key: 0xF0FBF51F
  Debian Developer: [hidden email]

_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users



_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: ArgumentDo

Jon Purdy
In reply to this post by Carter Schonwald
> 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.
_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: ArgumentDo

Carter Schonwald

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" <[hidden email]> 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.

_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: ArgumentDo

Sven Panne-2
In reply to this post by Carter Schonwald
[ 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 <[hidden email]>:
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...

_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: ArgumentDo

Joachim Breitner-2
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
  [hidden email]https://www.joachim-breitner.de/
  XMPP: [hidden email] • OpenPGP-Key: 0xF0FBF51F
  Debian Developer: [hidden email]
_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

signature.asc (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: ArgumentDo

C Maeder-2
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
> [hidden email]
> http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
>

_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: ArgumentDo

Sven Panne-2
In reply to this post by Joachim Breitner-2
2016-07-08 9:09 GMT+02:00 Joachim Breitner <[hidden email]>:
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...

_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: ArgumentDo

Joachim Breitner-2
Hi,

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

> 2016-07-08 9:09 GMT+02:00 Joachim Breitner <[hidden email]>:
> > 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
  [hidden email]https://www.joachim-breitner.de/
  XMPP: [hidden email] • OpenPGP-Key: 0xF0FBF51F
  Debian Developer: [hidden email]
_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

signature.asc (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: ArgumentDo

Sven Panne-2
2016-07-08 12:28 GMT+02:00 Joachim Breitner <[hidden email]>:
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.

_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: ArgumentDo

Joachim Breitner-2
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
  [hidden email]https://www.joachim-breitner.de/
  XMPP: [hidden email] • OpenPGP-Key: 0xF0FBF51F
  Debian Developer: [hidden email]
_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

signature.asc (836 bytes) Download Attachment
12