code review 6912056: spec: consistently use "indices" (rather than "indexes")

spec: consistently use "indices" (rather than "indexes")

We have been using all three terms "indices", "indexes",
and "index expressions" indiscriminatly for index values.
With this change, "index" refers to an index value,
"indices" is the plural of "index", and "index expression"
refers to an array, slice, or map indexed by an index: a[x].

[gri, 2012-12-08 00:08:45]

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

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

[mtj1, 2012-12-08 00:14:21]

Awesome. When you get to this point, you're ready to be an international
standard. I remember just this normalization in OpenGL's spec/books
for *matrix, matrices
and matrixes.* ;-)

On Fri, Dec 7, 2012 at 4:08 PM, <gri@golang.org> wrote:

> Reviewers: r, rsc, iant, ken2,
>
> Message:
> Hello r@golang.org, rsc@golang.org, iant@golang.org, ken@golang.org (cc:
> golang-dev@googlegroups.com),
>
> I'd like you to review this change to
> https://code.google.com/p/go
>
>
> Description:
> spec: consistently use "indices" (rather than "indexes")
>
> We have been using all three terms "indices", "indexes",
> and "index expressions" indiscriminatly for index values.
> With this change, "index" refers to an index value,
> "indices" is the plural of "index", and "index expression"
> refers to an array, slice, or map indexed by an index: a[x].
>
> Please review this at
https://codereview.appspot.**com/6912056/<https://codereview.appspot.com/6912...
>
> Affected files:
>   M doc/go_spec.html
>
>
> Index: doc/go_spec.html
> ==============================**==============================**=======
> --- a/doc/go_spec.html
> +++ b/doc/go_spec.html
> @@ -1,6 +1,6 @@
>  <!--{
>         "Title": "The Go Programming Language Specification",
> -       "Subtitle": "Version of December 6, 2012",
> +       "Subtitle": "Version of December 7, 2012",
>         "Path": "/ref/spec"
>  }-->
>
> @@ -791,8 +791,8 @@
>  The length of a string <code>s</code> (its size in bytes) can be
> discovered using
>  the built-in function <a href="#Length_and_capacity"><**
> code>len</code></a>.
>  The length is a compile-time constant if the string is a constant.
> -A string's bytes can be accessed by integer indices 0 through
> -<code>len(s)-1</code> (§<a href="#Indexes">Indexes</a>).
> +A string's bytes can be accessed by integer <a href="#Index_expressions">
> **indices</a>
> +0 through <code>len(s)-1</code>.
>  It is illegal to take the address of such an element; if
>  <code>s[i]</code> is the <code>i</code>'th byte of a
>  string, <code>&amp;s[i]</code> is invalid.
> @@ -819,8 +819,8 @@
>  <a href="#Constant_expressions">**constant expression</a> that evaluates
> to a non-negative
>  integer value.  The length of array <code>a</code> can be discovered
>  using the built-in function <a href="#Length_and_capacity"><**
> code>len</code></a>.
> -The elements can be indexed by integer
> -indices 0 through <code>len(a)-1</code> (§<a href="#Indexes">Indexes</a>).
> +The elements can be addressed by integer <a href="#Index_expressions">**
> indices</a>
> +indices 0 through <code>len(a)-1</code>.
>  Array types are always one-dimensional but may be composed to form
>  multi-dimensional types.
>  </p>
> @@ -850,8 +850,8 @@
>  Like arrays, slices are indexable and have a length.  The length of a
>  slice <code>s</code> can be discovered by the built-in function
>  <a href="#Length_and_capacity"><**code>len</code></a>; unlike with
> arrays it may change during
> -execution.  The elements can be addressed by integer indices 0
> -through <code>len(s)-1</code> (§<a href="#Indexes">Indexes</a>).  The
> slice index of a
> +execution.  The elements can be addressed by integer <a
> href="#Index_expressions">**indices</a>
> +0 through <code>len(s)-1</code>.  The slice index of a
>  given element may be less than the index of the same element in the
>  underlying array.
>  </p>
> @@ -1257,7 +1257,7 @@
>  built-in function <a href="#Length_and_capacity"><**code>len</code></a>
>  and may change during execution. Elements may be added during execution
>  using <a href="#Assignments">**assignments</a> and retrieved with
> -<a href="#Indexes">index</a> expressions; they may be removed with the
> +<a href="#Index_expressions">**index expressions</a>; they may be
> removed with the
>  <a href="#Deletion_of_map_**elements"><code>delete</code><**/a> built-in
> function.
>  </p>
>  <p>
> @@ -2120,7 +2120,7 @@
>  to the respective field, element, and key types of the LiteralType;
>  there is no additional conversion.
>  The key is interpreted as a field name for struct literals,
> -an index expression for array and slice literals, and a key for map
> literals.
> +an index for array and slice literals, and a key for map literals.
>  For map literals, all elements must have a key. It is an error
>  to specify multiple elements with the same field name or
>  constant key value.
> @@ -2480,7 +2480,7 @@
>  -->
>
>
> -<h3 id="Indexes">Indexes</h3>
> +<h3 id="Index_expressions">Index expressions</h3>
>
>  <p>
>  A primary expression of the form
> @@ -2596,7 +2596,7 @@
>  </pre>
>
>  <p>
> -constructs a substring or slice. The index expressions <code>low</code>
> and
> +constructs a substring or slice. The indices <code>low</code> and
>  <code>high</code> select which elements appear in the result. The result
> has
>  indices starting at 0 and length equal to
>  <code>high</code>&nbsp;-&nbsp;**<code>low</code>.
> @@ -2619,7 +2619,7 @@
>  </pre>
>
>  <p>
> -For convenience, any of the index expressions may be omitted. A missing
> <code>low</code>
> +For convenience, any of the indices may be omitted. A missing
> <code>low</code>
>  index defaults to zero; a missing <code>high</code> index defaults to the
> length of the
>  sliced operand:
>  </p>
> @@ -4010,7 +4010,7 @@
>
>  <p>
>  The assignment proceeds in two phases.
> -First, the operands of <a href="#Indexes">index expressions</a>
> +First, the operands of <a href="#Index_expressions">**index
> expressions</a>
>  and <a href="#Address_operators">**pointer indirections</a>
>  (including implicit pointer indirections in <a
> href="#Selectors">selectors</**a>)
>  on the left and the expressions on the right are all
>
>
>


-- 
Michael T. Jones | Chief Technology Advocate  | mtj@google.com |  +1
650-335-5765

[gri, 2012-12-08 00:19:44]

So what was the outcome in the battle between "matrices" and "matrixes" ? :-)

On Fri, Dec 7, 2012 at 4:13 PM, Michael Jones <mtj@google.com> wrote:
> Awesome. When you get to this point, you're ready to be an international
> standard. I remember just this normalization in OpenGL's spec/books for
> matrix, matrices and matrixes. ;-)
>
>
> On Fri, Dec 7, 2012 at 4:08 PM, <gri@golang.org> wrote:
>>
>> Reviewers: r, rsc, iant, ken2,
>>
>> Message:
>> Hello r@golang.org, rsc@golang.org, iant@golang.org, ken@golang.org (cc:
>> golang-dev@googlegroups.com),
>>
>> I'd like you to review this change to
>> https://code.google.com/p/go
>>
>>
>> Description:
>> spec: consistently use "indices" (rather than "indexes")
>>
>> We have been using all three terms "indices", "indexes",
>> and "index expressions" indiscriminatly for index values.
>> With this change, "index" refers to an index value,
>> "indices" is the plural of "index", and "index expression"
>> refers to an array, slice, or map indexed by an index: a[x].
>>
>> Please review this at https://codereview.appspot.com/6912056/
>>
>> Affected files:
>>   M doc/go_spec.html
>>
>>
>> Index: doc/go_spec.html
>> ===================================================================
>> --- a/doc/go_spec.html
>> +++ b/doc/go_spec.html
>> @@ -1,6 +1,6 @@
>>  <!--{
>>         "Title": "The Go Programming Language Specification",
>> -       "Subtitle": "Version of December 6, 2012",
>> +       "Subtitle": "Version of December 7, 2012",
>>         "Path": "/ref/spec"
>>  }-->
>>
>> @@ -791,8 +791,8 @@
>>  The length of a string <code>s</code> (its size in bytes) can be
>> discovered using
>>  the built-in function <a
>> href="#Length_and_capacity"><code>len</code></a>.
>>  The length is a compile-time constant if the string is a constant.
>> -A string's bytes can be accessed by integer indices 0 through
>> -<code>len(s)-1</code> (§<a href="#Indexes">Indexes</a>).
>> +A string's bytes can be accessed by integer <a
>> href="#Index_expressions">indices</a>
>> +0 through <code>len(s)-1</code>.
>>  It is illegal to take the address of such an element; if
>>  <code>s[i]</code> is the <code>i</code>'th byte of a
>>  string, <code>&amp;s[i]</code> is invalid.
>> @@ -819,8 +819,8 @@
>>  <a href="#Constant_expressions">constant expression</a> that evaluates to
>> a non-negative
>>  integer value.  The length of array <code>a</code> can be discovered
>>  using the built-in function <a
>> href="#Length_and_capacity"><code>len</code></a>.
>> -The elements can be indexed by integer
>> -indices 0 through <code>len(a)-1</code> (§<a
>> href="#Indexes">Indexes</a>).
>> +The elements can be addressed by integer <a
>> href="#Index_expressions">indices</a>
>> +indices 0 through <code>len(a)-1</code>.
>>  Array types are always one-dimensional but may be composed to form
>>  multi-dimensional types.
>>  </p>
>> @@ -850,8 +850,8 @@
>>  Like arrays, slices are indexable and have a length.  The length of a
>>  slice <code>s</code> can be discovered by the built-in function
>>  <a href="#Length_and_capacity"><code>len</code></a>; unlike with arrays
>> it may change during
>> -execution.  The elements can be addressed by integer indices 0
>> -through <code>len(s)-1</code> (§<a href="#Indexes">Indexes</a>).  The
>> slice index of a
>> +execution.  The elements can be addressed by integer <a
>> href="#Index_expressions">indices</a>
>> +0 through <code>len(s)-1</code>.  The slice index of a
>>  given element may be less than the index of the same element in the
>>  underlying array.
>>  </p>
>> @@ -1257,7 +1257,7 @@
>>  built-in function <a href="#Length_and_capacity"><code>len</code></a>
>>  and may change during execution. Elements may be added during execution
>>  using <a href="#Assignments">assignments</a> and retrieved with
>> -<a href="#Indexes">index</a> expressions; they may be removed with the
>> +<a href="#Index_expressions">index expressions</a>; they may be removed
>> with the
>>  <a href="#Deletion_of_map_elements"><code>delete</code></a> built-in
>> function.
>>  </p>
>>  <p>
>> @@ -2120,7 +2120,7 @@
>>  to the respective field, element, and key types of the LiteralType;
>>  there is no additional conversion.
>>  The key is interpreted as a field name for struct literals,
>> -an index expression for array and slice literals, and a key for map
>> literals.
>> +an index for array and slice literals, and a key for map literals.
>>  For map literals, all elements must have a key. It is an error
>>  to specify multiple elements with the same field name or
>>  constant key value.
>> @@ -2480,7 +2480,7 @@
>>  -->
>>
>>
>> -<h3 id="Indexes">Indexes</h3>
>> +<h3 id="Index_expressions">Index expressions</h3>
>>
>>  <p>
>>  A primary expression of the form
>> @@ -2596,7 +2596,7 @@
>>  </pre>
>>
>>  <p>
>> -constructs a substring or slice. The index expressions <code>low</code>
>> and
>> +constructs a substring or slice. The indices <code>low</code> and
>>  <code>high</code> select which elements appear in the result. The result
>> has
>>  indices starting at 0 and length equal to
>>  <code>high</code>&nbsp;-&nbsp;<code>low</code>.
>> @@ -2619,7 +2619,7 @@
>>  </pre>
>>
>>  <p>
>> -For convenience, any of the index expressions may be omitted. A missing
>> <code>low</code>
>> +For convenience, any of the indices may be omitted. A missing
>> <code>low</code>
>>  index defaults to zero; a missing <code>high</code> index defaults to the
>> length of the
>>  sliced operand:
>>  </p>
>> @@ -4010,7 +4010,7 @@
>>
>>  <p>
>>  The assignment proceeds in two phases.
>> -First, the operands of <a href="#Indexes">index expressions</a>
>> +First, the operands of <a href="#Index_expressions">index expressions</a>
>>  and <a href="#Address_operators">pointer indirections</a>
>>  (including implicit pointer indirections in <a
>> href="#Selectors">selectors</a>)
>>  on the left and the expressions on the right are all
>>
>>
>
>
>
> --
> Michael T. Jones | Chief Technology Advocate  | mtj@google.com |  +1
> 650-335-5765
>

[r, 2012-12-08 00:22:09]

LGTM and thank you

[mtj1, 2012-12-08 01:03:06]

Matrix & Matrices, though my point was only about pervasive normalization.
;-)

On Fri, Dec 7, 2012 at 4:22 PM, <r@golang.org> wrote:

> LGTM and thank you
>
>
https://codereview.appspot.**com/6912056/<https://codereview.appspot.com/6912...
>

Michael T. Jones | Chief Technology Advocate  | mtj@google.com |  +1
650-335-5765

[rsc, 2012-12-10 18:40:41]

LGTM

[iant, 2012-12-10 19:20:54]

LGTM

https://codereview.appspot.com/6912056/diff/6001/doc/go_spec.html
File doc/go_spec.html (right):

https://codereview.appspot.com/6912056/diff/6001/doc/go_spec.html#newcode3
doc/go_spec.html:3: "Subtitle": "Version of December 7, 2012",
s/7/10/

[gri, 2012-12-10 19:56:14]

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

spec: consistently use "indices" (rather than "indexes")

We have been using all three terms "indices", "indexes",
and "index expressions" indiscriminatly for index values.
With this change, "index" refers to an index value,
"indices" is the plural of "index", and "index expression"
refers to an array, slice, or map indexed by an index: a[x].

R=r, rsc, iant, ken, mtj
CC=golang-dev
https://codereview.appspot.com/6912056