spec: fix description of initialization

The analysis does not depend on the values of the items.
Fixes #4648.

R=golang-dev, gri, rsc
CC=golang-dev
https://golang.org/cl/7593050

doc/go_spec.html

@@ -3542,7 +3542,7 @@ using an addressable value will automatically take the address of that value: <c
 f := t.Mv; f(7)   // like t.Mv(7)
 f := pt.Mp; f(7)  // like pt.Mp(7)
 f := pt.Mv; f(7)  // like (*pt).Mv(7)
-f := t.Mp; f(7)   // like (&t).Mp(7)
+f := t.Mp; f(7)   // like (&amp;t).Mp(7)
 f := makeT().Mp   // invalid: result of makeT() is not addressable
 </pre>
 
@@ -5715,19 +5715,23 @@ in unspecified order.
 </p>
 <p>
 Within a package, package-level variables are initialized,
-and constant values are determined, in
-data-dependent order: if the initializer of <code>A</code>
-depends on the value of <code>B</code>, <code>A</code>
+and constant values are determined, according to
+order of reference: if the initializer of <code>A</code>
+depends on <code>B</code>, <code>A</code>
 will be set after <code>B</code>.
-It is an error if such dependencies form a cycle.
-Dependency analysis is done lexically: <code>A</code>
+Dependency analysis does not depend on the actual values
+of the items being initialized, only on their appearance
+in the source.
+<code>A</code>
 depends on <code>B</code> if the value of <code>A</code>
 contains a mention of <code>B</code>, contains a value
 whose initializer
 mentions <code>B</code>, or mentions a function that
 mentions <code>B</code>, recursively.
+It is an error if such dependencies form a cycle.
 If two items are not interdependent, they will be initialized
-in the order they appear in the source.
+in the order they appear in the source, possibly in multiple files,
+as presented to the compiler.
 Since the dependency analysis is done per package, it can produce
 unspecified results  if <code>A</code>'s initializer calls a function defined
 in another package that refers to <code>B</code>.