code review 94030045: spec: several clarifications to language on channels

spec: several clarifications to language on channels

- A channel may be used between any number of goroutines,
  not just two.
- Replace "passing a value" (which is not further defined)
  by "sending and receiving a value".
- Made syntax production more symmetric.
- Talk about unbuffered channels before buffered channels.
- Clarify what the comma,ok receive values mean (issue 7785).

Not a language change.

Fixes issue 7785.

[gri, 2014-05-05 21:41:14]

Hello r@golang.org, rsc@golang.org, iant@golang.org, ken@golang.org (cc:
golang-codereviews@googlegroups.com),

I'd like you to review this change to
https://code.google.com/p/go/

[r, 2014-05-06 11:45:20]

https://codereview.appspot.com/94030045/diff/120001/doc/go_spec.html
File doc/go_spec.html (right):

https://codereview.appspot.com/94030045/diff/120001/doc/go_spec.html#newcode1335
doc/go_spec.html:1335: <i>asynchronous</i>: communication operations succeed
without blocking if the buffer
delete the synchronous and asynchronous terms here and everywhere else.
although we use the terminology colloquially, a channel is not synchronous, only
its operations are.
this is like saying an int is commutative because addition is commutative.

stick with buffered and unbuffered.

https://codereview.appspot.com/94030045/diff/120001/doc/go_spec.html#newcode5365
doc/go_spec.html:5365: make(T)          channel    synchronous channel of type T
s/synchronous/unbuffered/

https://codereview.appspot.com/94030045/diff/120001/doc/go_spec.html#newcode5366
doc/go_spec.html:5366: make(T, n)       channel    asynchronous channel of type
T, buffer size n
s/asynchronous/buffered/

[gri, 2014-05-06 17:20:26]

PTAL

https://codereview.appspot.com/94030045/diff/120001/doc/go_spec.html
File doc/go_spec.html (right):

https://codereview.appspot.com/94030045/diff/120001/doc/go_spec.html#newcode1335
doc/go_spec.html:1335: <i>asynchronous</i>: communication operations succeed
without blocking if the buffer
On 2014/05/06 11:45:20, r wrote:
> delete the synchronous and asynchronous terms here and everywhere else.
> although we use the terminology colloquially, a channel is not synchronous,
only
> its operations are.
> this is like saying an int is commutative because addition is commutative.
> 
> stick with buffered and unbuffered.

Done.

https://codereview.appspot.com/94030045/diff/120001/doc/go_spec.html#newcode5365
doc/go_spec.html:5365: make(T)          channel    synchronous channel of type T
On 2014/05/06 11:45:20, r wrote:
> s/synchronous/unbuffered/

Done.

https://codereview.appspot.com/94030045/diff/120001/doc/go_spec.html#newcode5366
doc/go_spec.html:5366: make(T, n)       channel    asynchronous channel of type
T, buffer size n
On 2014/05/06 11:45:20, r wrote:
> s/asynchronous/buffered/

Done.

[iant, 2014-05-06 18:08:07]

https://codereview.appspot.com/94030045/diff/140001/doc/go_spec.html
File doc/go_spec.html (right):

https://codereview.appspot.com/94030045/diff/140001/doc/go_spec.html#newcode1284
doc/go_spec.html:1284: <a href="#Send_statements">sending</a> or
s/or/and/ ?

https://codereview.appspot.com/94030045/diff/140001/doc/go_spec.html#newcode1356
doc/go_spec.html:1356: <a href="#Close"><code>close</code></a>
I don't think I would put "close" on this list, as calling close on a closed
channel will panic.  While it is true that multiple goroutines can call close on
a channel without causing a race condition, it's not actually a reasonable thing
to do.

https://codereview.appspot.com/94030045/diff/140001/doc/go_spec.html#newcode1360
doc/go_spec.html:1360: that are received by a single goroutine, the values are
received in the order sent.
s/single goroutine/single other goroutine/ ?

[gri, 2014-05-06 18:22:17]

PTAL

https://codereview.appspot.com/94030045/diff/140001/doc/go_spec.html
File doc/go_spec.html (right):

https://codereview.appspot.com/94030045/diff/140001/doc/go_spec.html#newcode1284
doc/go_spec.html:1284: <a href="#Send_statements">sending</a> or
On 2014/05/06 18:08:07, iant wrote:
> s/or/and/ ?

Done.

https://codereview.appspot.com/94030045/diff/140001/doc/go_spec.html#newcode1356
doc/go_spec.html:1356: <a href="#Close"><code>close</code></a>
On 2014/05/06 18:08:07, iant wrote:
> I don't think I would put "close" on this list, as calling close on a closed
> channel will panic.  While it is true that multiple goroutines can call close
on
> a channel without causing a race condition, it's not actually a reasonable
thing
> to do.

Fair enough. That said, one could have multiple goroutines that all call close
_without_further synchronization_ and that catch the potentially ensuing panic
(and thus use this mechanism to detect if the channel was closed before).

Not feeling strongly about it. Leaving for Rob.

https://codereview.appspot.com/94030045/diff/140001/doc/go_spec.html#newcode1360
doc/go_spec.html:1360: that are received by a single goroutine, the values are
received in the order sent.
On 2014/05/06 18:08:07, iant wrote:
> s/single goroutine/single other goroutine/ ?

Done.

[rsc, 2014-05-07 02:54:42]

LGTM

https://codereview.appspot.com/94030045/diff/110002/doc/go_spec.html
File doc/go_spec.html (right):

https://codereview.appspot.com/94030045/diff/110002/doc/go_spec.html#newcode1297
doc/go_spec.html:1297: <i>bi-directional</i>.
i think bidirectional is usually not hyphenated

https://codereview.appspot.com/94030045/diff/110002/doc/go_spec.html#newcode1356
doc/go_spec.html:1356: <a href="#Close"><code>close</code></a>
Drop 'close' from the list. The others are all truly independent, but close has
synchronization requirements, probably best not spelled out here: a send cannot
happen after a close, and there cannot be multiple closes.

https://codereview.appspot.com/94030045/diff/110002/doc/go_spec.html#newcode1359
doc/go_spec.html:1359: For example, if a single goroutine sends on a channel
values
if one goroutine sends values on a channel
and a second goroutine receives them,

[gri, 2014-05-07 16:02:18]

PTAL r, iant

https://codereview.appspot.com/94030045/diff/110002/doc/go_spec.html
File doc/go_spec.html (right):

https://codereview.appspot.com/94030045/diff/110002/doc/go_spec.html#newcode1297
doc/go_spec.html:1297: <i>bi-directional</i>.
On 2014/05/07 02:54:41, rsc wrote:
> i think bidirectional is usually not hyphenated

Done.

https://codereview.appspot.com/94030045/diff/110002/doc/go_spec.html#newcode1297
doc/go_spec.html:1297: <i>bi-directional</i>.
On 2014/05/07 02:54:41, rsc wrote:
> i think bidirectional is usually not hyphenated

Done.

https://codereview.appspot.com/94030045/diff/110002/doc/go_spec.html#newcode1356
doc/go_spec.html:1356: <a href="#Close"><code>close</code></a>
On 2014/05/07 02:54:41, rsc wrote:
> Drop 'close' from the list. The others are all truly independent, but close
has
> synchronization requirements, probably best not spelled out here: a send
cannot
> happen after a close, and there cannot be multiple closes.

Done.

https://codereview.appspot.com/94030045/diff/110002/doc/go_spec.html#newcode1359
doc/go_spec.html:1359: For example, if a single goroutine sends on a channel
values
On 2014/05/07 02:54:41, rsc wrote:
> if one goroutine sends values on a channel
> and a second goroutine receives them, 

Done.

[r, 2014-05-07 16:10:34]

LGTM

[iant, 2014-05-07 17:34:57]

LGTM

[gri, 2014-05-07 17:40:42]

*** Submitted as https://code.google.com/p/go/source/detail?r=1ce8d70162aa ***

spec: several clarifications to language on channels

- A channel may be used between any number of goroutines,
  not just two.
- Replace "passing a value" (which is not further defined)
  by "sending and receiving a value".
- Made syntax production more symmetric.
- Talk about unbuffered channels before buffered channels.
- Clarify what the comma,ok receive values mean (issue 7785).

Not a language change.

Fixes issue 7785.

LGTM=rsc, r, iant
R=r, rsc, iant, ken
CC=golang-codereviews
https://codereview.appspot.com/94030045