J3/10-214
To: J3
From: Malcolm Cohen
Subject: Editorial suggestions and responses.
Date: 2010 October 04


1. Introduction

This paper lists some editorial suggestions received by the editor since
the last meeting.  Responses are suggested.


2. Suggestions

First three from Erik Kruyt:

(1) The wording in 2.4.3.3 is different from that in 7.1.1, third
    paragraph.

    E.g. in 2.4.3.3
    - An expression produces a data entity when evaluated.
    In 7.1.1
    - Evaluation of an expression produces a value, ...

    Suggestion: Evaluation of an expression produces a data entity.
                The data entity has a type, type parameters ...

(2) 2.4.3.3 and 2.4.3.4 please change "rank" into "shape".

(3) 7.1.1, first sentence: please change "data" into "data object".

From Van Snyder:

(4) Last paragraph before C.9 contains "Since these these entities are...".
    One "these" should be deleted.

(5) IEEE_IS_FINITE appears twice in Table 14.1.  Only one is needed.


3. Responses to suggestions

(1) Rejected.
    Use of the term "data entity", which can refer to practically anything,
    instead of the term "value", would be unnatural and lose specificity.

    Of course 2.4.3.3 says an expression produces a data entity, because
    all of 2.4.3 is about data entities.  That an expression produces a
    value and not just a data entity is properly specified in 7.1.1.

    I am sympathetic to the idea of improving the wording, but I think that
    2.4.3.3 is too vague, rather than 7.1.1 being too specific.

(2) (i) 2.4.3.3 Problematic.
        7.1.9 does claim to specify the "Type, type parameters, and shape
        of an expression", but a disassociated pointer (this is an
        acceptable result of an expression in some contexts) has rank but
        no shape.

        Further consideration should be given to possible rewording at a
        later date.  I think the wording in 7.1.9 could need revision.

    (ii) 2.4.3.4 Rejected.
         In fact the shape of a function result is not necessarily
         determined by the interface of the function.  Therefore the
         standard is correct as is, changing it would be an error.

(3) Accepted.
    This will make the opening sentence of 7.1.1 clearer, and also
    consistent with 2.4.3.3.
      "An expression represents either a data object reference or a
       computation,"

(4) Accepted.

(5) Accepted.


4. Edits to 10-007

[133:4] 7.1.1, first sentence,
  After "either a data" insert "object" before "reference".
{Suggestion 3 from Erik Kruyt.}

[407:24+7] In table 14.1, delete the second IEEE_IS_FINITE line.
           This is the one ending "being finite.".
{Suggestion 5 from Van Snyder.}

[505:5] C.8.4 last paragraph, last sentence,
  Change "these these entities" to "these entities".
{Suggestion 4 from Van Snyder.}

===END===