code review 3973051: go spec: follow-up cleanups after communication operato...

go spec: follow-up cleanups after communication operator changes

These are syntactical changes to better reflect the communication
operator's new status in the language.

- sending to a channel is now done via a send statement
- there is no binary communication operation anymore which
  leads to a reduction of the number of precedence levels
  from 6 to 5 (yeah!)
- small semantic change: since a send operation is not part
  of the expression syntax anymore, a <- send operator is
  binding weaker than any other operator now
- receiving from a channel is done as before via the unary
  receive expression
- communication clauses in select statement now can contain
  send statements or receive expressions

[gri, 2011-02-01 00:31:23]

Hello rsc, r, iant, ken2 (cc: golang-dev@googlegroups.com),

I'd like you to review this change.

[gri, 2011-02-01 00:40:28]

Follow-up: Actually there is a small semantic change here because now a send
operation - as it is outside the binary expression precedence hierarchy -
has a weaker precedence then before. This is actually beneficial because it
permits statements such as:

ch <- a && f() | g()

which before had to be written with parentheses:

ch <- (a && f() | g())

w/o parentheses, this was interpreted as:

(ch <- a) && f() | g()

before. The new interpretation is consistent with the fact that send
operations are not expressions anymore.

- gri

On Mon, Jan 31, 2011 at 4:31 PM, <gri@golang.org> wrote:

> Reviewers: rsc, r, iant, ken2,
>
> Message:
> Hello rsc, r, iant, ken2 (cc: golang-dev@googlegroups.com),
>
> I'd like you to review this change.
>
>
> Description:
> go spec: follow-up cleanups after communication operator changes
>
> These are syntactical changes to better reflect the communication
> operator's new status in the language. There are no semantic changes.
>
> - sending to a channel is now done via a send statement
> - there is no binary communication operation anymore which
>  leads to a reduction of the number of precedence levels
>  from 6 to 5 (yeah!)
> - receiving from a channel is done as before via the unary
>  receive expression
> - communication clauses in select statement now can contain
>  send statements or receive expressions
>
> Please review this at http://codereview.appspot.com/3973051/
>
> Affected files:
>  M doc/go_spec.html
>
>
>

[gri, 2011-02-01 00:41:46]

Follow-up: Actually there is a small semantic change here because now a send
operation - as it is outside the binary expression precedence hierarchy -
has a weaker precedence then before. This is actually beneficial because it
permits statements such as:

ch <- a && f() | g()

which before had to be written with parentheses:

ch <- (a && f() | g())

w/o parentheses, this was interpreted as:

(ch <- a) && f() | g()

before. The new interpretation is consistent with the fact that send
operations are not expressions anymore.

- gri

On Mon, Jan 31, 2011 at 4:31 PM, <gri@golang.org> wrote:

> Reviewers: rsc, r, iant, ken2,
>
> Message:
> Hello rsc, r, iant, ken2 (cc: golang-dev@googlegroups.com),
>
> I'd like you to review this change.
>
>
> Description:
> go spec: follow-up cleanups after communication operator changes
>
> These are syntactical changes to better reflect the communication
> operator's new status in the language. There are no semantic changes.
>
> - sending to a channel is now done via a send statement
> - there is no binary communication operation anymore which
>  leads to a reduction of the number of precedence levels
>  from 6 to 5 (yeah!)
> - receiving from a channel is done as before via the unary
>  receive expression
> - communication clauses in select statement now can contain
>  send statements or receive expressions
>
> Please review this at http://codereview.appspot.com/3973051/
>
> Affected files:
>  M doc/go_spec.html
>
>
>

[rsc, 2011-02-01 13:00:36]

http://codereview.appspot.com/3973051/diff/9002/doc/go_spec.html
File doc/go_spec.html (right):

http://codereview.appspot.com/3973051/diff/9002/doc/go_spec.html#newcode3532
doc/go_spec.html:3532: A send statement sends a value (on the right) on the
channel specified
since the grammar hasn't been seen yet this is confusing.
the grammar makes the players clear anyway, so this could
be simplified to

A send statement sends a value on a channel.

http://codereview.appspot.com/3973051/diff/9002/doc/go_spec.html#newcode3557
doc/go_spec.html:3557: Except in a communications clause of a
I suggest dropping this exception wording both here
and above in the receive case:

Sending to a nil channel causes a run-time panic.

The current wording is confusing (it prompted discussion
about this very fact on the mailing list) because it makes
it sound like sending to a nil channel is okay if done inside
a select.  But the nil channel is never sent to in a select.
Having a nil channel disables the select case entirely: it never
tries to do the send. 

Deleting the exception text here and above would leave the
description of the select statement to speak for itself.

http://codereview.appspot.com/3973051/diff/9002/doc/go_spec.html#newcode4095
doc/go_spec.html:4095: except, for send statements, its expression is still
evaluated.
this uses a plural in "for send statements"
but then refers to the singular "its"

the original text (except, if a send,) seems fine.

[rsc, 2011-02-01 13:10:03]

On Mon, Jan 31, 2011 at 19:40, Robert Griesemer <gri@golang.org> wrote:
> Follow-up: Actually there is a small semantic change here because now a send
> operation - as it is outside the binary expression precedence hierarchy -
> has a weaker precedence then before. This is actually beneficial because it
> permits statements such as:
> ch <- a && f() | g()
> which before had to be written with parentheses:
> ch <- (a && f() | g())
> w/o parentheses, this was interpreted as:
> (ch <- a) && f() | g()
> before. The new interpretation is consistent with the fact that send
> operations are not expressions anymore.

Nice.  That's a case I missed in 6g.  Will fix.

Russ

[gri1, 2011-02-01 17:17:08]

PTAL

http://codereview.appspot.com/3973051/diff/9002/doc/go_spec.html
File doc/go_spec.html (right):

http://codereview.appspot.com/3973051/diff/9002/doc/go_spec.html#newcode3532
doc/go_spec.html:3532: A send statement sends a value (on the right) on the
channel specified
On 2011/02/01 13:00:36, rsc wrote:
> since the grammar hasn't been seen yet this is confusing.
> the grammar makes the players clear anyway, so this could
> be simplified to
> 
> A send statement sends a value on a channel.

Done.

http://codereview.appspot.com/3973051/diff/9002/doc/go_spec.html#newcode3557
doc/go_spec.html:3557: Except in a communications clause of a
On 2011/02/01 13:00:36, rsc wrote:
> I suggest dropping this exception wording both here
> and above in the receive case:
> 
> Sending to a nil channel causes a run-time panic.
> 
> The current wording is confusing (it prompted discussion
> about this very fact on the mailing list) because it makes
> it sound like sending to a nil channel is okay if done inside
> a select.  But the nil channel is never sent to in a select.
> Having a nil channel disables the select case entirely: it never
> tries to do the send. 
> 
> Deleting the exception text here and above would leave the
> description of the select statement to speak for itself.

Done.

http://codereview.appspot.com/3973051/diff/9002/doc/go_spec.html#newcode4095
doc/go_spec.html:4095: except, for send statements, its expression is still
evaluated.
On 2011/02/01 13:00:36, rsc wrote:
> this uses a plural in "for send statements"
> but then refers to the singular "its"
> 
> the original text (except, if a send,) seems fine.

Done.

[rsc, 2011-02-01 17:47:07]

LGTM

http://codereview.appspot.com/3973051/diff/11002/doc/go_spec.html
File doc/go_spec.html (right):

http://codereview.appspot.com/3973051/diff/11002/doc/go_spec.html#newcode3513
doc/go_spec.html:3513: Function calls, method calls, and channel operations
s/channel/receive/

[gri1, 2011-02-01 17:51:28]

http://codereview.appspot.com/3973051/diff/11002/doc/go_spec.html
File doc/go_spec.html (right):

http://codereview.appspot.com/3973051/diff/11002/doc/go_spec.html#newcode3513
doc/go_spec.html:3513: Function calls, method calls, and channel operations
On 2011/02/01 17:47:07, rsc wrote:
> s/channel/receive/

Done.

[r, 2011-02-01 19:31:29]

LGTM

http://codereview.appspot.com/3973051/diff/14001/doc/go_spec.html
File doc/go_spec.html (right):

http://codereview.appspot.com/3973051/diff/14001/doc/go_spec.html#newcode4087
doc/go_spec.html:4087: For all the send and receive statements in the "select"
receive isn't a statement. this wording isn't right.
For all the clauses in the select statement?

[gri1, 2011-02-01 19:56:42]

PTAL

Also, adjusted the syntax for RecvStmt so that 

x = <- a + b

in a CommCase is parsed as

(<-a) + b

as it would be in an assignment

(per rsc's suggestion)

http://codereview.appspot.com/3973051/diff/14001/doc/go_spec.html
File doc/go_spec.html (right):

http://codereview.appspot.com/3973051/diff/14001/doc/go_spec.html#newcode4087
doc/go_spec.html:4087: For all the send and receive statements in the "select"
On 2011/02/01 19:31:30, r wrote:
> receive isn't a statement. this wording isn't right.
> For all the clauses in the select statement?

Changed to

For all the cases in the ...

(only the comunication ops in the case part of the syntax are considered)

[rsc, 2011-02-01 19:58:54]

LGTM

http://codereview.appspot.com/3973051/diff/7002/doc/go_spec.html
File doc/go_spec.html (right):

http://codereview.appspot.com/3973051/diff/7002/doc/go_spec.html#newcode4088
doc/go_spec.html:4088: RecvExpr must be a <a href="#Receive_operator"> receive
operation</a>.
s/> />/
(will underline the white space in some browsers)

[gri, 2011-02-01 20:02:51]

*** Submitted as http://code.google.com/p/go/source/detail?r=5c69e7c1eedf ***

go spec: follow-up cleanups after communication operator changes

These are syntactical changes to better reflect the communication
operator's new status in the language.

- sending to a channel is now done via a send statement
- there is no binary communication operation anymore which
  leads to a reduction of the number of precedence levels
  from 6 to 5 (yeah!)
- small semantic change: since a send operation is not part
  of the expression syntax anymore, a <- send operator is
  binding weaker than any other operator now
- receiving from a channel is done as before via the unary
  receive expression
- communication clauses in select statement now can contain
  send statements or receive expressions

R=rsc, r, iant, ken2, gri1
CC=golang-dev
http://codereview.appspot.com/3973051