|
|
Descriptionspec: clarify section on package initialization
- split description of package initialization and
program execution
- better grouping of concerns in section on package
initialization
- more explicit definition of what constitues a
dependency
- removed language about constant dependencies -
they are computed at compile-time and not
initialized at run-time
- clarified that independent variables are initialized
in declaration order (rather than reference order)
Note that the last clarification is what distinguishes
gc and gccgo at the moment: gc uses reference order
(i.e., order in which variables are referenced in
initialization expressions), while gccgo uses declaration
order for independent variables.
Not a language change. But adopting this CL will
clarify what constitutes a dependency.
Fixes issue 6703.
Patch Set 1 #Patch Set 2 : diff -r 1ce8d70162aa https://code.google.com/p/go/ #Patch Set 3 : diff -r 2c7ba8c04515 https://code.google.com/p/go/ #Patch Set 4 : diff -r 209bb94bd691 https://code.google.com/p/go #Patch Set 5 : diff -r 209bb94bd691 https://code.google.com/p/go #
Total comments: 10
Patch Set 6 : diff -r 209bb94bd691 https://code.google.com/p/go/ #Patch Set 7 : diff -r 209bb94bd691 https://code.google.com/p/go/ #
Total comments: 6
Patch Set 8 : diff -r 209bb94bd691 https://code.google.com/p/go/ #
Total comments: 14
Patch Set 9 : diff -r 209bb94bd691 https://code.google.com/p/go/ #Patch Set 10 : diff -r 209bb94bd691 https://code.google.com/p/go/ #
Total comments: 14
Patch Set 11 : diff -r 5283a606b755 https://code.google.com/p/go/ #Patch Set 12 : diff -r 0f7c69d6c367 https://code.google.com/p/go/ #
Total comments: 2
Patch Set 13 : diff -r c9bcacf2ba33 https://code.google.com/p/go/ #Patch Set 14 : diff -r c9bcacf2ba33 https://code.google.com/p/go/ #Patch Set 15 : diff -r c9bcacf2ba33 https://code.google.com/p/go/ #Patch Set 16 : diff -r c0c00145e2d3 https://code.google.com/p/go/ #
Total comments: 4
Patch Set 17 : diff -r c0c00145e2d3 https://code.google.com/p/go/ #
Total comments: 4
Patch Set 18 : diff -r c0c00145e2d3 https://code.google.com/p/go/ #
Total comments: 5
Patch Set 19 : diff -r ddbcb0e26855 https://code.google.com/p/go/ #Patch Set 20 : diff -r ddbcb0e26855 https://code.google.com/p/go/ #MessagesTotal messages: 30
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
Sign in to reply to this message.
Much better. https://codereview.appspot.com/99020043/diff/80001/doc/go_spec.html File doc/go_spec.html (right): https://codereview.appspot.com/99020043/diff/80001/doc/go_spec.html#newcode4020 doc/go_spec.html:4020: At package level, <a href="#Package_initialization"</a>initialization dependencies</a> Bad HTML here. https://codereview.appspot.com/99020043/diff/80001/doc/go_spec.html#newcode5887 doc/go_spec.html:5887: depends on the value of a variable <code>y</code>, <code>x</code> "depends on the value" suggests that the initialization order is determined by true data dependencies. In fact it is merely the existence of a syntactic dependency. Your next paragraph clarifies this, but perhaps you could avoid raising the confusion in the first place. https://codereview.appspot.com/99020043/diff/80001/doc/go_spec.html#newcode5923 doc/go_spec.html:5923: satisfy the interface. This is probably overkill. s/probably// https://codereview.appspot.com/99020043/diff/80001/doc/go_spec.html#newcode5930 doc/go_spec.html:5930: If two variables are not interdependent, they will be initialized You should make it clear that the specified initialization order (resulting from the combination of the graph order and the lexical order) is total. There is no room for variation among compilers. Perhaps it's also worth stating explicitly that the order of lexical references within an initialization expression is immaterial. You might want to write the formal algorithm in a comment, since it has apparently caused a lot of confusion: ---- Within a single package, the dependency graph G is a directed graph G=<V,E> where V is the set of package-level 'func' and 'var' entities and E⊂V×V is the set of directed edges (x, y) induced by syntactic references (as defined above) to y∈V within the initializer expression of var x∈V or within the body of func x∈V. The edge (x, y) signifies that y must be initialized before x. It is an error if G is cyclic. Since G is a DAG, it defines a partial order. The total order I={V,<} of initialization is defined as follows: If there exists a directed path from x to y in G, y < x. Otherwise, if y is defined lexically earlier than x, y < x. Otherwise x < y.
Sign in to reply to this message.
On 2014/05/09 15:00:08, adonovan wrote: > Much better. > > https://codereview.appspot.com/99020043/diff/80001/doc/go_spec.html > File doc/go_spec.html (right): > > https://codereview.appspot.com/99020043/diff/80001/doc/go_spec.html#newcode4020 > doc/go_spec.html:4020: At package level, <a > href="#Package_initialization"</a>initialization dependencies</a> > Bad HTML here. > > https://codereview.appspot.com/99020043/diff/80001/doc/go_spec.html#newcode5887 > doc/go_spec.html:5887: depends on the value of a variable <code>y</code>, > <code>x</code> > "depends on the value" suggests that the initialization order is determined by > true data dependencies. In fact it is merely the existence of a syntactic > dependency. Your next paragraph clarifies this, but perhaps you could avoid > raising the confusion in the first place. > > https://codereview.appspot.com/99020043/diff/80001/doc/go_spec.html#newcode5923 > doc/go_spec.html:5923: satisfy the interface. This is probably overkill. > s/probably// > > https://codereview.appspot.com/99020043/diff/80001/doc/go_spec.html#newcode5930 > doc/go_spec.html:5930: If two variables are not interdependent, they will be > initialized > You should make it clear that the specified initialization order (resulting from > the combination of the graph order and the lexical order) is total. There is no > room for variation among compilers. > > Perhaps it's also worth stating explicitly that the order of lexical references > within an initialization expression is immaterial. > > You might want to write the formal algorithm in a comment, since it has > apparently caused a lot of confusion: > > ---- > Within a single package, the dependency graph G is a directed graph G=<V,E> > where V is the set of package-level 'func' and 'var' entities and E⊂V×V is the > set of directed edges (x, y) induced by syntactic references (as defined above) > to y∈V within the initializer expression of var x∈V or within the body of func > x∈V. The edge (x, y) signifies that y must be initialized before x. It is an > error if G is cyclic. > > Since G is a DAG, it defines a partial order. The total order I={V,<} of > initialization is defined as follows: > If there exists a directed path from x to y in G, y < x. > Otherwise, if y is defined lexically earlier than x, y < x. > Otherwise x < y. One other thing: you should clarify that this: var x, y = a(), b() creates edges x->a, y->b and is thus (at package-level only) entirely equivalent to both var x = a() var y = b() and to: var y = b() var x = a() but that var x, y = a() creates edges x->a, y->a.
Sign in to reply to this message.
On 9 May 2014 11:04, <adonovan@google.com> wrote: > > One other thing: you should clarify that this: > > var x, y = a(), b() > > creates edges x->a, y->b and is thus (at package-level only) entirely > equivalent to both > > var x = a() > var y = b() > > and to: > > var y = b() > var x = a() > > (I meant "equivalent in terms of dependency graph edges", not necessarily the resulting total order. In the last example x is obviously flipped w.r.t. y in the lexical order, and this could affect the result. I hope that was obvious. Time for coffee.)
Sign in to reply to this message.
PTAL Specifically, please note that extra sentence: Specifically, the order in which variables are referenced in initialization expressions, function, and method bodies does not matter. (lines 5931, 5932). https://codereview.appspot.com/99020043/diff/80001/doc/go_spec.html File doc/go_spec.html (right): https://codereview.appspot.com/99020043/diff/80001/doc/go_spec.html#newcode4020 doc/go_spec.html:4020: At package level, <a href="#Package_initialization"</a>initialization dependencies</a> On 2014/05/09 15:00:08, adonovan wrote: > Bad HTML here. Done. https://codereview.appspot.com/99020043/diff/80001/doc/go_spec.html#newcode5887 doc/go_spec.html:5887: depends on the value of a variable <code>y</code>, <code>x</code> On 2014/05/09 15:00:08, adonovan wrote: > "depends on the value" suggests that the initialization order is determined by > true data dependencies. In fact it is merely the existence of a syntactic > dependency. Your next paragraph clarifies this, but perhaps you could avoid > raising the confusion in the first place. Done. https://codereview.appspot.com/99020043/diff/80001/doc/go_spec.html#newcode5910 doc/go_spec.html:5910: A primary expression <code>x</code> depends on a variable Rephrased this section. https://codereview.appspot.com/99020043/diff/80001/doc/go_spec.html#newcode5923 doc/go_spec.html:5923: satisfy the interface. This is probably overkill. On 2014/05/09 15:00:08, adonovan wrote: > s/probably// Done. https://codereview.appspot.com/99020043/diff/80001/doc/go_spec.html#newcode5930 doc/go_spec.html:5930: If two variables are not interdependent, they will be initialized On 2014/05/09 15:00:08, adonovan wrote: > You should make it clear that the specified initialization order (resulting from > the combination of the graph order and the lexical order) is total. There is no > room for variation among compilers. > > Perhaps it's also worth stating explicitly that the order of lexical references > within an initialization expression is immaterial. > > You might want to write the formal algorithm in a comment, since it has > apparently caused a lot of confusion: > > ---- > Within a single package, the dependency graph G is a directed graph G=<V,E> > where V is the set of package-level 'func' and 'var' entities and E⊂V×V is the > set of directed edges (x, y) induced by syntactic references (as defined above) > to y∈V within the initializer expression of var x∈V or within the body of func > x∈V. The edge (x, y) signifies that y must be initialized before x. It is an > error if G is cyclic. > > Since G is a DAG, it defines a partial order. The total order I={V,<} of > initialization is defined as follows: > If there exists a directed path from x to y in G, y < x. > Otherwise, if y is defined lexically earlier than x, y < x. > Otherwise x < y. I have clarified that for interdependent variables the declaration order (rather than the reference order) matters. The two compilers differ in this respect. For http://play.golang.org/p/icbjgkx71B the initialization order is: c b a (gc) b c a (gccgo) gc uses reference order, gccgo uses declaration order. I'd rather not add more formal commentary, it will only lead to requests for more of that elsewhere, and it's not necessarily clearer.
Sign in to reply to this message.
https://codereview.appspot.com/99020043/diff/80001/doc/go_spec.html File doc/go_spec.html (right): https://codereview.appspot.com/99020043/diff/80001/doc/go_spec.html#newcode5930 doc/go_spec.html:5930: If two variables are not interdependent, they will be initialized On 2014/05/09 17:55:16, gri wrote: > On 2014/05/09 15:00:08, adonovan wrote: > > You should make it clear that the specified initialization order (resulting > from > > the combination of the graph order and the lexical order) is total. There is > no > > room for variation among compilers. > > > > Perhaps it's also worth stating explicitly that the order of lexical > references > > within an initialization expression is immaterial. > > > > You might want to write the formal algorithm in a comment, since it has > > apparently caused a lot of confusion: > > > > ---- > > Within a single package, the dependency graph G is a directed graph G=<V,E> > > where V is the set of package-level 'func' and 'var' entities and E⊂V×V is the > > set of directed edges (x, y) induced by syntactic references (as defined > above) > > to y∈V within the initializer expression of var x∈V or within the body of func > > x∈V. The edge (x, y) signifies that y must be initialized before x. It is an > > error if G is cyclic. > > > > Since G is a DAG, it defines a partial order. The total order I={V,<} of > > initialization is defined as follows: > > If there exists a directed path from x to y in G, y < x. > > Otherwise, if y is defined lexically earlier than x, y < x. > > Otherwise x < y. > > I have clarified that for interdependent variables the declaration order (rather > than the reference order) matters. The two compilers differ in this respect. For > http://play.golang.org/p/icbjgkx71B the initialization order is: > > c b a (gc) > b c a (gccgo) > > gc uses reference order, gccgo uses declaration order. > > I'd rather not add more formal commentary, it will only lead to requests for > more of that elsewhere, and it's not necessarily clearer. I meant "independent" (rather than interdependent) variables, of course.
Sign in to reply to this message.
https://codereview.appspot.com/99020043/diff/110002/doc/go_spec.html File doc/go_spec.html (right): https://codereview.appspot.com/99020043/diff/110002/doc/go_spec.html#newcode5890 doc/go_spec.html:5890: variables, only on the appearance of references to them in the For references, appearance is existence. So: "only on the existence of references to them" or: "only on references to them" https://codereview.appspot.com/99020043/diff/110002/doc/go_spec.html#newcode5931 doc/go_spec.html:5931: Specifically, the order in which variables are referenced in initialization I'm not sure "specifically" is the right connective here. Try a semicolon. https://codereview.appspot.com/99020043/diff/110002/doc/go_spec.html#newcode5934 doc/go_spec.html:5934: unspecified results if <code>x</code>'s initializer calls a function The results of the dependency analysis and order of initialization are fully specified across the entire program. It's the dynamic behaviour of programs that access uninitialized data that is unspecified. This sentence doesn't make clear how that can happen. And I'm struggling to relate the x and y mentioned here to their uses above.
Sign in to reply to this message.
PTAL https://codereview.appspot.com/99020043/diff/110002/doc/go_spec.html File doc/go_spec.html (right): https://codereview.appspot.com/99020043/diff/110002/doc/go_spec.html#newcode5890 doc/go_spec.html:5890: variables, only on the appearance of references to them in the On 2014/05/09 19:00:39, adonovan wrote: > For references, appearance is existence. > So: "only on the existence of references to them" > or: "only on references to them" Done. https://codereview.appspot.com/99020043/diff/110002/doc/go_spec.html#newcode5931 doc/go_spec.html:5931: Specifically, the order in which variables are referenced in initialization On 2014/05/09 19:00:40, adonovan wrote: > I'm not sure "specifically" is the right connective here. Try a semicolon. Done. https://codereview.appspot.com/99020043/diff/110002/doc/go_spec.html#newcode5934 doc/go_spec.html:5934: unspecified results if <code>x</code>'s initializer calls a function On 2014/05/09 19:00:40, adonovan wrote: > The results of the dependency analysis and order of initialization are fully > specified across the entire program. It's the dynamic behaviour of programs > that access uninitialized data that is unspecified. This sentence doesn't make > clear how that can happen. And I'm struggling to relate the x and y mentioned > here to their uses above. Leaving this sentence away. It's confusing and unclear.
Sign in to reply to this message.
On 2014/05/09 19:12:21, gri wrote: > PTAL > > https://codereview.appspot.com/99020043/diff/110002/doc/go_spec.html > File doc/go_spec.html (right): > > https://codereview.appspot.com/99020043/diff/110002/doc/go_spec.html#newcode5890 > doc/go_spec.html:5890: variables, only on the appearance of references to them > in the > On 2014/05/09 19:00:39, adonovan wrote: > > For references, appearance is existence. > > So: "only on the existence of references to them" > > or: "only on references to them" > > Done. > > https://codereview.appspot.com/99020043/diff/110002/doc/go_spec.html#newcode5931 > doc/go_spec.html:5931: Specifically, the order in which variables are referenced > in initialization > On 2014/05/09 19:00:40, adonovan wrote: > > I'm not sure "specifically" is the right connective here. Try a semicolon. > > Done. > > https://codereview.appspot.com/99020043/diff/110002/doc/go_spec.html#newcode5934 > doc/go_spec.html:5934: unspecified results if <code>x</code>'s initializer calls > a function > On 2014/05/09 19:00:40, adonovan wrote: > > The results of the dependency analysis and order of initialization are fully > > specified across the entire program. It's the dynamic behaviour of programs > > that access uninitialized data that is unspecified. This sentence doesn't > make > > clear how that can happen. And I'm struggling to relate the x and y mentioned > > here to their uses above. > > Leaving this sentence away. It's confusing and unclear. LGTM
Sign in to reply to this message.
https://codereview.appspot.com/99020043/diff/130001/doc/go_spec.html File doc/go_spec.html (right): https://codereview.appspot.com/99020043/diff/130001/doc/go_spec.html#newcode5903 doc/go_spec.html:5903: respectively) contains an identifier denoting <code>y</code>, You've got three things (expression, function, method) and then you've got two things (x, body of x) so using "respectively" is confusing. https://codereview.appspot.com/99020043/diff/130001/doc/go_spec.html#newcode5906 doc/go_spec.html:5906: that depends on <code>y</code>. What about a function? https://codereview.appspot.com/99020043/diff/130001/doc/go_spec.html#newcode5912 doc/go_spec.html:5912: <code>t.m</code> where the (static) type of <code>t</code> is not an interface s/not an interface/not an interface type/ https://codereview.appspot.com/99020043/diff/130001/doc/go_spec.html#newcode5914 doc/go_spec.html:5914: from which the corresponding function value <code>t.m</code> was derived. This is expressed in a rather complicated way. Though I admit I'm having trouble simplifying it. Also this dependency only exists if the method is defined in the same package. Can we say something like: A method value or method expression t.m, where the (static) type of t is not an interface type, where t is defined in the current package, depends on the method m in the method set of t. https://codereview.appspot.com/99020043/diff/130001/doc/go_spec.html#newcode5928 doc/go_spec.html:5928: in the source, possibly in multiple files, as presented to the compiler; I don't think we want to promise anything about the order of initialization across multiple files. In particular it's hard to make sense of that when using the go tool. Source order only applies within a single file. https://codereview.appspot.com/99020043/diff/130001/doc/go_spec.html#newcode5930 doc/go_spec.html:5930: expressions, function, and method bodies does not matter. I don't understand what is added by this last clause.
Sign in to reply to this message.
https://codereview.appspot.com/99020043/diff/130001/doc/go_spec.html File doc/go_spec.html (right): https://codereview.appspot.com/99020043/diff/130001/doc/go_spec.html#newcode5928 doc/go_spec.html:5928: in the source, possibly in multiple files, as presented to the compiler; On 2014/05/09 19:48:33, iant wrote: > I don't think we want to promise anything about the order of initialization > across multiple files. In particular it's hard to make sense of that when using > the go tool. Source order only applies within a single file. In the interests of cross-toolchain determinism and predictability, I think we should (continue to) make such a promise. In practice, the set of source files in a compilation unit is always passed to the compiler in some order. If build tools obfuscate or randomize that order, that's not the spec's problem, and fact they do not: the go/build library always returns files in name order and our favourite proprietary build system uses the order in which *.go files are enumerated in the BUILD file.
Sign in to reply to this message.
https://codereview.appspot.com/99020043/diff/130001/doc/go_spec.html File doc/go_spec.html (right): https://codereview.appspot.com/99020043/diff/130001/doc/go_spec.html#newcode5928 doc/go_spec.html:5928: in the source, possibly in multiple files, as presented to the compiler; On 2014/05/09 20:02:02, adonovan wrote: > On 2014/05/09 19:48:33, iant wrote: > > I don't think we want to promise anything about the order of initialization > > across multiple files. In particular it's hard to make sense of that when > using > > the go tool. Source order only applies within a single file. > > In the interests of cross-toolchain determinism and predictability, I think we > should (continue to) make such a promise. In practice, the set of source files > in a compilation unit is always passed to the compiler in some order. If build > tools obfuscate or randomize that order, that's not the spec's problem, and fact > they do not: the go/build library always returns files in name order and our > favourite proprietary build system uses the order in which *.go files are > enumerated in the BUILD file. I never understood us to be making that promise in the past. I don't see a strong reason to start making that promise now. It's not hard to determine the initialization order when it matters.
Sign in to reply to this message.
PTAL https://codereview.appspot.com/99020043/diff/130001/doc/go_spec.html File doc/go_spec.html (right): https://codereview.appspot.com/99020043/diff/130001/doc/go_spec.html#newcode5903 doc/go_spec.html:5903: respectively) contains an identifier denoting <code>y</code>, On 2014/05/09 19:48:33, iant wrote: > You've got three things (expression, function, method) and then you've got two > things (x, body of x) so using "respectively" is confusing. Done. But I think it read better using respectively. https://codereview.appspot.com/99020043/diff/130001/doc/go_spec.html#newcode5906 doc/go_spec.html:5906: that depends on <code>y</code>. On 2014/05/09 19:48:33, iant wrote: > What about a function? What about it? (an identifier may denote a function or variable y) https://codereview.appspot.com/99020043/diff/130001/doc/go_spec.html#newcode5912 doc/go_spec.html:5912: <code>t.m</code> where the (static) type of <code>t</code> is not an interface On 2014/05/09 19:48:33, iant wrote: > s/not an interface/not an interface type/ Done. https://codereview.appspot.com/99020043/diff/130001/doc/go_spec.html#newcode5914 doc/go_spec.html:5914: from which the corresponding function value <code>t.m</code> was derived. On 2014/05/09 19:48:34, iant wrote: > This is expressed in a rather complicated way. Though I admit I'm having > trouble simplifying it. Also this dependency only exists if the method is > defined in the same package. Can we say something like: > > A method value or method expression t.m, where the (static) type of t is not an > interface type, where t is defined in the current package, depends on the method > m in the method set of t. Done. https://codereview.appspot.com/99020043/diff/130001/doc/go_spec.html#newcode5928 doc/go_spec.html:5928: in the source, possibly in multiple files, as presented to the compiler; On 2014/05/09 20:15:40, iant wrote: > On 2014/05/09 20:02:02, adonovan wrote: > > On 2014/05/09 19:48:33, iant wrote: > > > I don't think we want to promise anything about the order of initialization > > > across multiple files. In particular it's hard to make sense of that when > > using > > > the go tool. Source order only applies within a single file. > > > > In the interests of cross-toolchain determinism and predictability, I think we > > should (continue to) make such a promise. In practice, the set of source > files > > in a compilation unit is always passed to the compiler in some order. If > build > > tools obfuscate or randomize that order, that's not the spec's problem, and > fact > > they do not: the go/build library always returns files in name order and our > > favourite proprietary build system uses the order in which *.go files are > > enumerated in the BUILD file. > > I never understood us to be making that promise in the past. I don't see a > strong reason to start making that promise now. It's not hard to determine the > initialization order when it matters. I am inclined to leave this as is. This is not a new promise, it was in the spec all along. The order exists, and knowing about it is useful when tracking down problems. https://codereview.appspot.com/99020043/diff/130001/doc/go_spec.html#newcode5930 doc/go_spec.html:5930: expressions, function, and method bodies does not matter. On 2014/05/09 19:48:33, iant wrote: > I don't understand what is added by this last clause. This emphasizes what is said before, namely that independent variables are initialized in _declaration_ source order (rather than order they appear in initialization expressions). gc does this incorrectly. See issue https://code.google.com/p/go/issues/detail?id=7962 . Happy to leave it away, but it was subtle enough that it caused divergence in implementations.
Sign in to reply to this message.
please let me review this before submitting. i want to have time to look it over carefully, and also i am concerned about the length of the change. if initialization is that hard to explain, something is wrong.
Sign in to reply to this message.
Sure, I'm not going to submit until we're all on the same page. Just FYI, the change looks larger than it is, mostly because I re-organized the order of things. Before various aspects were talked about in no particular order. Now the order is "variable dependencies, init functions, overall package initialization". The part that is more complicated than before is the part that explains what constitutes a dependency. This was imprecise enough before to lead to 3 different interpretations (gc, gccgo, go/types). - gri On Fri, May 9, 2014 at 2:15 PM, <r@golang.org> wrote: > please let me review this before submitting. i want to have time to look > it over carefully, and also i am concerned about the length of the > change. if initialization is that hard to explain, something is wrong. > > > https://codereview.appspot.com/99020043/ >
Sign in to reply to this message.
https://codereview.appspot.com/99020043/diff/160001/doc/go_spec.html File doc/go_spec.html (right): https://codereview.appspot.com/99020043/diff/160001/doc/go_spec.html#newcode5901 doc/go_spec.html:5901: An (initialization) expression, function, or method <code>x</code> depends on why is initialization parenthesized? https://codereview.appspot.com/99020043/diff/160001/doc/go_spec.html#newcode5915 doc/go_spec.html:5915: of <code>t</code>. It does not matter whether the resulting function s/does not matter/is immaterial/ https://codereview.appspot.com/99020043/diff/160001/doc/go_spec.html#newcode5916 doc/go_spec.html:5916: value <code>t.m</code> is invoked or not. s/ or not// https://codereview.appspot.com/99020043/diff/160001/doc/go_spec.html#newcode5932 doc/go_spec.html:5932: expressions, function, and method bodies does not matter. i don't know what these last two lines mean. the order matters in some respects. https://codereview.appspot.com/99020043/diff/160001/doc/go_spec.html#newcode5955 doc/go_spec.html:5955: Variables may also be initialized using <code>init</code> functions s/$/,/ https://codereview.appspot.com/99020043/diff/160001/doc/go_spec.html#newcode5956 doc/go_spec.html:5956: which must be of the form: it would be better to define what they are rather than give pseudocode. functions named init declared in the package block, with no arguments and no result parameters. https://codereview.appspot.com/99020043/diff/160001/doc/go_spec.html#newcode5974 doc/go_spec.html:5974: functions in unspecified order. it's not clear to me how init functions affect the dependency calculation, and i thought that was the motivation for this change.
Sign in to reply to this message.
PTAL https://codereview.appspot.com/99020043/diff/160001/doc/go_spec.html File doc/go_spec.html (right): https://codereview.appspot.com/99020043/diff/160001/doc/go_spec.html#newcode5901 doc/go_spec.html:5901: An (initialization) expression, function, or method <code>x</code> depends on On 2014/05/12 19:43:07, r wrote: > why is initialization parenthesized? It's any expression, not just an initialization expression (e.g., it could be an expression inside a function). Admittedly, that's covered already. I can leave away the ()'s, or the (initialization). https://codereview.appspot.com/99020043/diff/160001/doc/go_spec.html#newcode5915 doc/go_spec.html:5915: of <code>t</code>. It does not matter whether the resulting function On 2014/05/12 19:43:07, r wrote: > s/does not matter/is immaterial/ Done. https://codereview.appspot.com/99020043/diff/160001/doc/go_spec.html#newcode5916 doc/go_spec.html:5916: value <code>t.m</code> is invoked or not. On 2014/05/12 19:43:08, r wrote: > s/ or not// Done. https://codereview.appspot.com/99020043/diff/160001/doc/go_spec.html#newcode5932 doc/go_spec.html:5932: expressions, function, and method bodies does not matter. On 2014/05/12 19:43:07, r wrote: > i don't know what these last two lines mean. the order matters in some respects. Iant had the same question. Obviously it needs to be rephrased. I want to make clear that (after the order determined via dependencies), as a secondary sort key, the declaration order is used, and _not_ the order in which variables are referenced in an expression: For instance, in the example below, we have a = c + b and the order between c and b is b, c because b is declared before c; rather than c, b because c is mentioned before b in the expression c + b. gc gets this wrong at the moment, gccgo gets it right. Tried to rephrase it in a new sentence. https://codereview.appspot.com/99020043/diff/160001/doc/go_spec.html#newcode5955 doc/go_spec.html:5955: Variables may also be initialized using <code>init</code> functions On 2014/05/12 19:43:08, r wrote: > s/$/,/ Done. https://codereview.appspot.com/99020043/diff/160001/doc/go_spec.html#newcode5956 doc/go_spec.html:5956: which must be of the form: On 2014/05/12 19:43:08, r wrote: > it would be better to define what they are rather than give pseudocode. > > functions named init declared in the package block, with no arguments and no > result parameters. Done. https://codereview.appspot.com/99020043/diff/160001/doc/go_spec.html#newcode5974 doc/go_spec.html:5974: functions in unspecified order. On 2014/05/12 19:43:07, r wrote: > it's not clear to me how init functions affect the dependency calculation, and i > thought that was the motivation for this change. That was not the motivation. Init functions cannot be referred to from anywhere so nobody can depend on them, and thus they could only be roots of dependencies. But when they are invoked, all variables with initialization expressions must already be initialized. Are you referring to something else?
Sign in to reply to this message.
it still doesn't say precisely what "depends on" means. i could take a crack at it if you like, or you could try again.
Sign in to reply to this message.
I think it does. That's the purpose of the 3-step recursive definition: 1) A variable x depends on y if the initialization expression for x depends on y. 2 ) An initialization expression, function, or method x depends on y if x (or the body of x, for functions and methods) contains an identifier denoting y, or a method value or method expression that depends on y. 3) A method value or method expression of the form t.m, where the (static) type of t is declared in the current package and is not an interface type, depends on the method m in the method set of t. It is immaterial whether the resulting function value t.m is invoked. It defines what depends means. Simplified: 1) x depends on y, if the definition of x depends on y. 2) The definition (expression, method, function) depends on y, if it contains (the identifier denoting) y, or a method expression or method value that depends on y. 3) the method expression/value depends on y if... etc. If you can write this down more clearly without loss of precision, I'm happy as well. - gri On Tue, May 13, 2014 at 2:28 PM, <r@golang.org> wrote: > it still doesn't say precisely what "depends on" means. > > i could take a crack at it if you like, or you could try again. > > > https://codereview.appspot.com/99020043/ >
Sign in to reply to this message.
https://codereview.appspot.com/99020043/diff/200001/doc/go_spec.html File doc/go_spec.html (right): https://codereview.appspot.com/99020043/diff/200001/doc/go_spec.html#newcode5890 doc/go_spec.html:5890: variables, only on references to them in the source: Dependency analysis does not rely on the actual values of the variables, only on lexical references to them in the source code, analyzed transitively. That is, variable <code>x</code> depends on the variable <code>y</code> if: - x's initialization is an expression whose source code contains a reference to y; or - x's initialization references a function or method whose source code contains a reference to y, transitively. Also, a method value of method expression of the form ... as below
Sign in to reply to this message.
PTAL https://codereview.appspot.com/99020043/diff/200001/doc/go_spec.html File doc/go_spec.html (right): https://codereview.appspot.com/99020043/diff/200001/doc/go_spec.html#newcode5890 doc/go_spec.html:5890: variables, only on references to them in the source: On 2014/05/13 22:00:08, r wrote: > Dependency analysis does not rely on the actual values of the variables, only on > lexical references to them in the source code, analyzed transitively. > That is, variable <code>x</code> depends on the variable <code>y</code> if: > > - x's initialization is an expression whose source code contains a reference to > y; or > - x's initialization references a function or method whose source code contains > a reference to y, transitively. > > Also, a method value of method expression of the form ... as below Rephrased section.
Sign in to reply to this message.
this is much better https://codereview.appspot.com/99020043/diff/280001/doc/go_spec.html File doc/go_spec.html (right): https://codereview.appspot.com/99020043/diff/280001/doc/go_spec.html#newcode5927 doc/go_spec.html:5927: thus <code>x</code> is indirectly dependent on <code>y</code>. if so, x depends on y. https://codereview.appspot.com/99020043/diff/280001/doc/go_spec.html#newcode5969 doc/go_spec.html:5969: they are initialized in the order they are <i>declared</i> the italics are unnecessary
Sign in to reply to this message.
PTAL https://codereview.appspot.com/99020043/diff/280001/doc/go_spec.html File doc/go_spec.html (right): https://codereview.appspot.com/99020043/diff/280001/doc/go_spec.html#newcode5927 doc/go_spec.html:5927: thus <code>x</code> is indirectly dependent on <code>y</code>. On 2014/05/14 19:24:03, r wrote: > if so, x depends on y. Done. https://codereview.appspot.com/99020043/diff/280001/doc/go_spec.html#newcode5969 doc/go_spec.html:5969: they are initialized in the order they are <i>declared</i> On 2014/05/14 19:24:03, r wrote: > the italics are unnecessary Done.
Sign in to reply to this message.
LGTM but let others weigh in
Sign in to reply to this message.
LGTM https://codereview.appspot.com/99020043/diff/300001/doc/go_spec.html File doc/go_spec.html (right): https://codereview.appspot.com/99020043/diff/300001/doc/go_spec.html#newcode5941 doc/go_spec.html:5941: <code>t.m</code>, where the (static) type of <code>t</code> is Omit "(static)" since there's no ambiguity. We're obviously not talking about the dynamic type since that can never be an interface. https://codereview.appspot.com/99020043/diff/300001/doc/go_spec.html#newcode5948 doc/go_spec.html:5948: be identified. One could conservatively introduce a dependency "One could...": this is a rejected language design choice, not a legitimate implementation strategy. I would just delete that sentence.
Sign in to reply to this message.
https://codereview.appspot.com/99020043/diff/300001/doc/go_spec.html File doc/go_spec.html (right): https://codereview.appspot.com/99020043/diff/300001/doc/go_spec.html#newcode5941 doc/go_spec.html:5941: <code>t.m</code>, where the (static) type of <code>t</code> is On 2014/05/14 20:33:27, adonovan wrote: > Omit "(static)" since there's no ambiguity. We're obviously not talking about > the dynamic type since that can never be an interface. I've been thinking about this but I prefer to be extra clear here. https://codereview.appspot.com/99020043/diff/300001/doc/go_spec.html#newcode5948 doc/go_spec.html:5948: be identified. One could conservatively introduce a dependency On 2014/05/14 20:33:27, adonovan wrote: > "One could...": this is a rejected language design choice, not a legitimate > implementation strategy. I would just delete that sentence. Done.
Sign in to reply to this message.
LGTM
Sign in to reply to this message.
LGTM https://codereview.appspot.com/99020043/diff/320001/doc/go_spec.html File doc/go_spec.html (right): https://codereview.appspot.com/99020043/diff/320001/doc/go_spec.html#newcode5974 doc/go_spec.html:5974: b = 2 It might be worth strengthening this example to show that two variables can be independent (neither depends on the other) even if they both depend on a third variable. var ( a = c + b b = f() c = f() d = 3 ) func f() int { d++ return d } If you use this, the text doesn't need to change - b and c are still independent and b is initialized before c - but now you can actually tell which was initialized first by looking at the final values. In the example in the current draft CL, even if you initialize c before b you still get the right final set of variables, so people might conclude that really the order of the independent variables don't matter. The suggested example above shows that they do. This is a variant of that bug you have open against 6g. (6g is doing a recursive dependency-order traversal, which at the time I thought would be equivalent to the phrasing in the spec, but it's not, precisely due to examples like this one.) https://codereview.appspot.com/99020043/diff/320001/doc/go_spec.html#newcode6008 doc/go_spec.html:6008: functions in unspecified order. should we say 'source order'? We're so clear about the tie-breaking everywhere else. Since this is a strict refinement it wouldn't invalidate any existing programs. I don't know what 6g does - probably not source order - but I'm okay with that being a bug in 6g that needs fixing.
Sign in to reply to this message.
https://codereview.appspot.com/99020043/diff/320001/doc/go_spec.html File doc/go_spec.html (right): https://codereview.appspot.com/99020043/diff/320001/doc/go_spec.html#newcode5974 doc/go_spec.html:5974: b = 2 On 2014/05/20 19:38:51, rsc wrote: > It might be worth strengthening this example to show that two variables can be > independent (neither depends on the other) even if they both depend on a third > variable. > > var ( > a = c + b > b = f() > c = f() > d = 3 > ) > > func f() int { > d++ > return d > } > > If you use this, the text doesn't need to change - b and c are still independent > and b is initialized before c - but now you can actually tell which was > initialized first by looking at the final values. In the example in the current > draft CL, even if you initialize c before b you still get the right final set of > variables, so people might conclude that really the order of the independent > variables don't matter. The suggested example above shows that they do. > > This is a variant of that bug you have open against 6g. (6g is doing a recursive > dependency-order traversal, which at the time I thought would be equivalent to > the phrasing in the spec, but it's not, precisely due to examples like this > one.) > The text does change because now d needs to be initialized before d. Fixed. https://codereview.appspot.com/99020043/diff/320001/doc/go_spec.html#newcode5974 doc/go_spec.html:5974: b = 2 On 2014/05/20 19:38:51, rsc wrote: > It might be worth strengthening this example to show that two variables can be > independent (neither depends on the other) even if they both depend on a third > variable. > > var ( > a = c + b > b = f() > c = f() > d = 3 > ) > > func f() int { > d++ > return d > } > > If you use this, the text doesn't need to change - b and c are still independent > and b is initialized before c - but now you can actually tell which was > initialized first by looking at the final values. In the example in the current > draft CL, even if you initialize c before b you still get the right final set of > variables, so people might conclude that really the order of the independent > variables don't matter. The suggested example above shows that they do. > > This is a variant of that bug you have open against 6g. (6g is doing a recursive > dependency-order traversal, which at the time I thought would be equivalent to > the phrasing in the spec, but it's not, precisely due to examples like this > one.) > Done. But note that the ordering changes to d, b, c, a (but b and c remain independent). https://codereview.appspot.com/99020043/diff/320001/doc/go_spec.html#newcode6008 doc/go_spec.html:6008: functions in unspecified order. On 2014/05/20 19:38:51, rsc wrote: > should we say 'source order'? > We're so clear about the tie-breaking everywhere else. Since this is a strict > refinement it wouldn't invalidate any existing programs. > I don't know what 6g does - probably not source order - but I'm okay with that > being a bug in 6g that needs fixing. Sounds good to me. I'll do this in a separate CL since I don't want to open this one up again for discussion.
Sign in to reply to this message.
*** Submitted as https://code.google.com/p/go/source/detail?r=eabf83a5e11c *** spec: clarify section on package initialization - split description of package initialization and program execution - better grouping of concerns in section on package initialization - more explicit definition of what constitues a dependency - removed language about constant dependencies - they are computed at compile-time and not initialized at run-time - clarified that independent variables are initialized in declaration order (rather than reference order) Note that the last clarification is what distinguishes gc and gccgo at the moment: gc uses reference order (i.e., order in which variables are referenced in initialization expressions), while gccgo uses declaration order for independent variables. Not a language change. But adopting this CL will clarify what constitutes a dependency. Fixes issue 6703. LGTM=adonovan, r, iant, rsc R=r, rsc, iant, ken, adonovan CC=golang-codereviews https://codereview.appspot.com/99020043
Sign in to reply to this message.
|