(j3.2006) (SC22WG5.4629) Vote on N1904

[Bill Long]

On 3/12/12 10:29 AM, John Reid wrote:
>
>
> Please answer the following question "Is N1904 ready for forwarding to SC22
> as the DTS?" in one of these ways.
>
> 3) No, for the following reasons.
>
> Page 9, C407a. After "that" add "does not have INTENT(OUT) and".
> Reason: INTENT(OUT) causes the dummy argument to become undefined, so
> is a sort of assignment. Allowing it is inconsistent with C407b - the
> intention is that as assumed-type object be altered only by a C
> function.
>

I agree with the goal here, though I think Reinhold's version of the 
edit is more economical.


> Page 10, C1255, line 2, change "or" to
> ", a variable that has the ALLOCATABLE or POINTER attribute, a variable
> of assumed shape, a variable of assumed type, a variable of assumed
> character length, or".
> Reason: We are currently saying that all these variables are disallowed
> as arguments of a procedure with the BIND attribute. This is at variance

There is definitely a problem with C1255.

> with the whole intent of the TS. This change perhaps goes too far. It

By "too far", I assume you mean does not provide as much constraint as 
needed. If so, I certainly agree with that.  New to the things allowed 
are allocatable coarrays.  Additionally, there is no restriction that 
these dummy arguments have interoperable types and type parameters.  For 
the assumed-type case, one could infer that we intended to allow a 
complete free-for-all. However, for the non-assumed-type case does it 
make sense to, by changing the declaration from explicit-shape to 
assumed-shape, concurrently delete the requirement that at least the 
type and type parameters still be interoperable?

> allows a procedure to have the BIND attribute despite it being
> impossible to write a C function prototype with which it interoperates.
> If this is felt to be important, more constraints along the lines of
> C516 could be added.
>
> Page 17, 8.2, line 3 and page 20, end of para under Table 8.1. Change
> "scalar or is an assumed-shape, explicit-shape, or assumed-size array"
> to
> "scalar, an array whose shape is known, or an assumed-size array"
> or
> "an object whose shape is known or an assumed-size array."
> Reason: The present wording excludes the case of an actual argument
> of assumed rank. It is also misleading since there is nothing in the
> descriptor to distinguish an assumed-shape array from an explicit-shape
> array (and no need for it).
>
> In addition, I suggest this change:
>
> Page 15, RANK. In the Example para, change "effective" to "actual".
> Reason: The meaning is the same in this case, but the reader has to
> think it through with "effective".
>

This is fine.

Cheers,
Bill


>
>
>
> _______________________________________________
> J3 mailing list
> J3 at j3-fortran.org
> http://j3-fortran.org/mailman/listinfo/j3

-- 
Bill Long                                           longb at cray.com
Fortran Technical Support    &                 voice: 651-605-9024
Bioinformatics Software Development            fax:   651-605-9142
Cray Inc./Cray Plaza, Suite 210/380 Jackson St./St. Paul, MN 55101