code review 5240055: spec: define order of multiple assignment

spec: define order of multiple assignment

[rsc, 2011-10-12 20:20:59]

Hello golang-dev@googlegroups.com,

I'd like you to review this change to
https://go.googlecode.com/hg/

[r, 2011-10-12 20:23:54]

http://codereview.appspot.com/5240055/diff/4001/doc/go_spec.html
File doc/go_spec.html (right):

http://codereview.appspot.com/5240055/diff/4001/doc/go_spec.html#newcode3734
doc/go_spec.html:3734: The expressions on the right and any sub-expressions on
the left
this is the first appearance of the undefined term "sub-expression". you need a
way to say this without using an undefined term. i don't know what it means,
anyway:

m[x] = f()

what is the order of events if m is a map?

[gri, 2011-10-12 20:25:07]

FYI

http://codereview.appspot.com/5240055/diff/4001/doc/go_spec.html
File doc/go_spec.html (right):

http://codereview.appspot.com/5240055/diff/4001/doc/go_spec.html#newcode2
doc/go_spec.html:2: <!-- subtitle Version of September 29, 2011 -->
please update the date

http://codereview.appspot.com/5240055/diff/4001/doc/go_spec.html#newcode3736
doc/go_spec.html:3736: The assignments then proceed in left-to-right order.
The link to evaluation order is gone. I think we still need it, or some version
of it.

[rsc, 2011-10-12 20:35:00]

Hello golang-dev@googlegroups.com, r@golang.org, gri@golang.org (cc:
golang-dev@googlegroups.com),

Please take another look.

[rsc, 2011-10-12 20:35:10]

Take 2:

<p>
In the second form, the number of operands on the left must equal the number
of expressions on the right, each of which must be single-valued, and the
<i>n</i>th expression on the right is assigned to the <i>n</i>th
operand on the left.  The assignment proceeds in two phases.
First, the operands of <a href="#Indexes">index expressions</a>,
<a href="#Selectors">selectors</a>, and
<a href="#Address_operators">pointer indirections</a> on the left
and the expressions on the right are evaluated according to
<a href="#Order_of_evaluation">the usual rules</a>.
Then the assignments are carried out in left-to-right order.
</p>

[r, 2011-10-12 20:49:31]

http://codereview.appspot.com/5240055/diff/9001/doc/go_spec.html
File doc/go_spec.html (right):

http://codereview.appspot.com/5240055/diff/9001/doc/go_spec.html#newcode3738
doc/go_spec.html:3738: <a href="#Order_of_evaluation">the usual rules</a>.
<a href="#Order_of_evaluation">the usual rules of evaluation order</a>.
or maybe

are evaluated <href>in the usual order</a>

and maybe

... across the entire statement.

the "and" on line 3737 arguably implies an ordering itself.
maybe
s/are evaluated/are all evaluated/ to clarify

http://codereview.appspot.com/5240055/diff/9001/doc/go_spec.html#newcode3739
doc/go_spec.html:3739: Then the assignments are carried out in left-to-right
order.
s/Then/Second,/

[rsc, 2011-10-12 20:52:44]

Done.

<p>
In the second form, the number of operands on the left must equal the number
of expressions on the right, each of which must be single-valued, and the
<i>n</i>th expression on the right is assigned to the <i>n</i>th
operand on the left.  The assignment proceeds in two phases.
First, the operands of <a href="#Indexes">index expressions</a>,
<a href="#Selectors">selectors</a>, and
<a href="#Address_operators">pointer indirections</a> on the left
and the expressions on the right are all
<a href="#Order_of_evaluation">evaluated in the usual order</a>.
Second, the assignments are carried out in left-to-right order.
</p>

[rsc, 2011-10-12 20:52:52]

Hello golang-dev@googlegroups.com, r@golang.org, gri@golang.org (cc:
golang-dev@googlegroups.com),

Please take another look.

[r, 2011-10-12 20:55:42]

LGTM but iant and gri should weigh in, at least

[gri, 2011-10-12 20:58:05]

http://codereview.appspot.com/5240055/diff/9001/doc/go_spec.html
File doc/go_spec.html (right):

http://codereview.appspot.com/5240055/diff/9001/doc/go_spec.html#newcode2
doc/go_spec.html:2: <!-- subtitle Version of October 13, 2011 -->
I guess we are submitting tomorrow :-)

http://codereview.appspot.com/5240055/diff/9001/doc/go_spec.html#newcode3734
doc/go_spec.html:3734: First, the operands of <a href="#Indexes">index
expressions</a>,
I think this is still a bit vague. Presumably, by operands of index expressions
the "index" is meant, but technically, the syntax of an index expression doesn't
have an "Operand" (only an Expression). Similarly for the others.

If I have:

a[f()] = g()

f() and g() get evaluation from left to right. Say, i = f(). Is a[i] (the
element address) evaluated before or after g() is called? (g may change the
global variable a).

Do we need the notion of an "L-value"? (I'd prefer not to, and I would call it a
variable still). Or am I missing something?

[rsc, 2011-10-12 21:06:42]

> I think this is still a bit vague. Presumably, by operands of index
> expressions the "index" is meant, but technically, the syntax of an
> index expression doesn't have an "Operand" (only an Expression).
> Similarly for the others.

I meant for the operands of the index expression x[y] to be both x and y.
I'm happy to take suggested alternate terminology.

> If I have:
> 
> a[f()] = g()
> 
> f() and g() get evaluation from left to right. Say, i = f(). Is a[i]
> (the element address) evaluated before or after g() is called? (g may
> change the global variable a).

Then the three things a, f(), and g() are evaluated before any
assignments take place, and the ordering of those happen according
to the usual rules.  The usual rules do not specify whether a is
evaluated before or after the calls to f() and g(), and I wasn't
trying to specify that here.
 
> Do we need the notion of an "L-value"? (I'd prefer not to, and I would
> call it a variable still). Or am I missing something?

I am not sure that l-value makes sense here.  In C it does,
because the l-value is logically the location where the
value will be stored.  For a map index operation, the
location is a much murkier concept.  What does happen is
that if you have m[x], m[y] = z, w for arbitrary expressions
m, x, y, z, w, then m, x, y, z, and w are all evaluated
(following the usual rules) before any assignments occur.

Russ

[r, 2011-10-12 23:54:55]

it would be nice to be clear that in

f()[g()] = h()

that if f() is a slice and g() is an index out of range, all functions are
called before the panic. we know that's what we mean, but it doesn't quite say
it. maybe all that's needed is that example.

[gri, 2011-10-12 23:55:33]

+1

and then LGTM

On Wed, Oct 12, 2011 at 4:54 PM,  <r@golang.org> wrote:
> it would be nice to be clear that in
>
> f()[g()] = h()
>
> that if f() is a slice and g() is an index out of range, all functions
> are called before the panic. we know that's what we mean, but it doesn't
> quite say it. maybe all that's needed is that example.
>
> http://codereview.appspot.com/5240055/
>

[rsc, 2011-10-13 16:02:06]

I think the checks being delayed is implied by the fact that
they are part of the assignment.  They are not listed in the things
that happen in the first phase.

I tried for a while but could not come up with a concise way to
add an explicit note.  However, I added these examples:

x[1], x[3] = 4, 5 // set x[1] = 4, then panic setting x[3] = 5.

type Point struct { x, y int }
var p *Point
x[2], p.x = 6, 7  // set x[2] = 6, then panic setting p.x = 7

Russ

[gri, 2011-10-13 18:16:58]

LGTM

I think the examples make it clear enough for now.

[r, 2011-10-13 18:26:45]

LGTM for now
it would be nice to find a cleaner presentation but this will do

[rsc, 2011-10-13 19:44:25]

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

spec: define order of multiple assignment

R=golang-dev, r, gri
CC=golang-dev
http://codereview.appspot.com/5240055