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
Follow-up: Actually there is a small semantic change here because now a send operation - ...
14 years, 1 month ago
(2011-02-01 00:40:28 UTC)
#2
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
>
>
>
Follow-up: Actually there is a small semantic change here because now a send operation - ...
14 years, 1 month ago
(2011-02-01 00:41:46 UTC)
#3
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
>
>
>
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) ...
14 years, 1 month ago
(2011-02-01 13:00:36 UTC)
#4
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.
On Mon, Jan 31, 2011 at 19:40, Robert Griesemer <gri@golang.org> wrote: > Follow-up: Actually there ...
14 years, 1 month ago
(2011-02-01 13:10:03 UTC)
#5
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
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 ...
14 years, 1 month ago
(2011-02-01 17:17:08 UTC)
#6
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.
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 ...
14 years, 1 month ago
(2011-02-01 19:31:29 UTC)
#9
PTAL Also, adjusted the syntax for RecvStmt so that x = <- a + b ...
14 years, 1 month ago
(2011-02-01 19:56:42 UTC)
#10
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)
*** Submitted as http://code.google.com/p/go/source/detail?r=5c69e7c1eedf *** go spec: follow-up cleanups after communication operator changes These are ...
14 years, 1 month ago
(2011-02-01 20:02:51 UTC)
#12
*** 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
Issue 3973051: code review 3973051: go spec: follow-up cleanups after communication operato...
(Closed)
Created 14 years, 1 month ago by gri
Modified 14 years, 1 month ago
Reviewers:
Base URL:
Comments: 11