(j3.2006) Papers 13-316, 13-317, 13-318

[Van Snyder]

Papers 13-316 and 13-317 need edits to 1.6 Compatibility, presumably in
a new subclause that will be entitled "Fortran 2008 Compatibility", and
maybe some words also in a "new features" subclause of the introduction.

It isn't necessary in 13-316 (or any paper) to delete table of contents
and index items; these are automatically generated.

In retrospect, it's not obvious that we need a REDUCE intrinsic
function, since (unlike the CO_REDUCE case) it's so easy to write one.
The considerations that led to CO_REDUCE simply do not apply in the
non-coarray case.  I think J3 should ask WG5 to remove this requirement.

Assuming it remains, paper 13-318 needs extensive revision.

An edit to a "new features" subclause of the introduction is needed.

It's not obvious that ARRAY should be prohibited to be polymorphic.
Rather, the dynamic type of the result of the operation should be
required to be the same as for ARRAY.

I would prefer that the name of the dummy argument for the reduction
function be called something other than OPERATOR, say FUNCTION or
REDUCTION.  The syntax doesn't admit things like .MyOpia. as actual
arguments.  In the description of that argument, presumably SOURCE ought
to be ARRAY.

The result might be processor dependent even if the operation is
commutative and associative.  Rather than the final sentence of the
OPERATOR paragraph, there should be a statement in the Result Value
paragraph (and Annex A) that the order of the (x,y) reductions is
processor dependent.

In the Result Value paragraph, replace "reduction operation" by
"reduction".  The phrase "for each x and y elements of ARRAY" should be
"for x and y distinct elements of the set at that iteration".

The first sentence of Case (iii) in Result Value doesn't say anything:

  "If ARRAY has rank one, REDUCE(ARRAY, OPERATOR, DIM=DIM
   [, MASK]) has a value equal to REDUCE(ARRAY, OPERATOR, DIM=DIM
   [, MASK])."

I'm not convinced the null value should be zero for numeric types.  For
example, the null result of PRODUCT is one.  Similarly, it's not obvious
that that the null value should be false for logical.  For example, the
null result of ALL is true.  It's not obvious what "the null string" is
for character type.  It should be something like "string of zero
length".

For derived types, the appropriate null value is not necessarily one
with components that have null values.  What if the type of ARRAY has
allocatable or pointer components?  It seems that those components ought
to be deallocated and disassociated, respectively, not allocated or
associated, with a value that is the null value for their types.

Perhaps an optional (or maybe not optional) NULL argument is needed.

In N1983, CO_REDUCE has many of the same problems.