(j3.2006) (SC22WG5.5458) New draft TS and straw ballot

Tue Mar 17 21:40:57 EDT 2015

On Tue, 2015-03-10 at 11:29 +0000, John Reid wrote:

> Bill has prepared a new draft TS following the recent J3 meeting. 
> Thanks, Bill, for doing this so quickly.
> 
> Here it is, with Bill's editor's report and a straw ballot. I have 
> allowed the usual 28 days for the ballot. It ends on 7 April at 9 a.m. 
> UK time.
> 
> Best wishes,
> 
> John.

                                          ISO/IEC JTC1/SC22/WG5 N2053

                       WG5 straw ballot on N2048

                       John Reid, 10 March 2015

This is a WG5 straw ballot on N2048, the eighth draft PDTS for 
TS 18508, Additional Parallel Features in Fortran.

N2048 was prepared by the editor, Bill Long, following the 
recent meeting of J3. Details of the changes made from the previous 
draft, N2040, are given in N2049. 

Please answer the following question "Is N2048 ready for forwarding to 
SC22 as the PDTS?" in one of these ways. 

1) Yes.
2) Yes, but I recommend the following changes. 
3) No, for the following reasons.
4) Abstain.

"No,: for the reasons in part 1 of the attachment.  But for those, I
would vote "Yes, but I recommend changes in parts 2 and 3 of the
attachment."

-------------- next part --------------
Comments on N2048.  Clause 9 not checked in detail.

1. Technical -- Mandatory
=========================

These must be addressed for me to vote yes.

------------------------------------------------------------------------
As Malcolm pointed out during the previous ballot, use of the term
"innermost" at [5:23 3.5.1] and [9:10 5.1] is nonsense.  If you don't
like Malcolm's words from the previous ballot, develop a term equivalent
to the term "dynamically enclosed" in the Ada standard.

------------------------------------------------------------------------
Discussion of the CRITICAL statement is wrong.

[16:5-7] Replace 6.3p2 with

"If the processor detects that an image has failed during execution of a
critical construct, the construct is regarded by other images as
complete.

"When an image executes a CRITICAL statement and the processor has
detected that the previous image that entered the construct failed
without completing execution of the construct, if the statement has a
STAT= specifier the specified variable becomes defined with the value
STAT_FAILED_IMAGE from the intrinsic module ISO_FORTRAN_ENV; if the
statement has an ERRMSG= specifier the specified variable is assigned an
explanatory message, as if by intrinsic assignment.  If the previous
image completed execution of the construct, the variable specified in
the STAT= specifier becomes defined with the value zero, and the value
of the variable specified in the ERRMSG= specifier is not changed."

Edits to 8.5.7 are necessary as well.  Discussion of the STAT= and
ERRMSG= specifiers in the CRITICAL statement should refer to 8.1.5.

------------------------------------------------------------------------
There is no definition of "equal" for type logical.  8.4.3 needs either
to define it, or use "equivalent".

------------------------------------------------------------------------
An image index assigned by the processor needs to be required to be
unique within the team.

[12:15] After "positive" insert ", unique within the team,"

2. Technical Preferences
========================

------------------------------------------------------------------------
There is no compelling reason that the <coarray-association> and
<sync-stat> entities cannot come in any order.

[9:33-34 R502]

R502 <change-team-stmt> <<is>> CHANGE TEAM ( <team-variable> \smudge
       \smudge <change-team-item-list> )

R502x <change-team-item> <<is>> <coarray-association>
                         <<or>> <sync-stat>

[10:10+ C504+]

C504a (R501) No specifier shall appear more than once in
      <change-team-item-list>.

------------------------------------------------------------------------
There is no compelling reason that named specifiers cannot come in any
order.  And why is ERRMSG= not allowed?

[11:4-5 R624]

R624 <image-selector> <<is>> <lbracket> <cosubscript-list> \smudge
       \smudge [, <image-selector-spec-list> ] <rbracket>

R624x <image-selector-spec> <<is>> <team-identifier>
                            <<or>> <sync-stat>

[11:8+ C509+]

C509a (R624) TEAM_ID and TEAM shall not both appear.

C509b (R624) No specifier shall appear more than once in
      <image-selector-spec-list>.

------------------------------------------------------------------------
NOTE 6.2 illustrates why standard input should be available on all
images.  Either the program can decide which image gets to read it, and
never try to read it until that image fails and a different one is
chosen, or if several images want to read it, they can do it in critical
sections.

------------------------------------------------------------------------
There is no apparent reason why the STAT argument of an atomic or
collective procedure should have at least four decimal digits.  The only
remote clue is the "processor dependent value" described in 8.2p4 and
8.3p5.  Statement specifiers to which a processor-dependent value might
be assigned, for example in an ALLOCATE statement, do not require at
least four digits.  Equally mysterious is why the LENGTH and STATUS
arguments to the GET_COMMAND, GET_COMMAND_ARGUMENT, and
GET_ENVIRONMENT_VARIABLE intrinsic subroutines, and the CMDSTAT argument
to the EXECUTE_COMMAND_LINE intrinsic subroutine, require at least four
digits, but those are not the topic of N2048.

The VALUES argument to the DATE_AND_TIME intrinsic subroutine makes
sense because the year is assigned to the first element.

------------------------------------------------------------------------
There is no apparent reason why the OPERATOR function passed to
CO_REDUCE is not allowed to have optional arguments.  There is no
apparent reason why the OPERATOR function passed to CO_REDUCE is not
allowed to have polymorphic arguments or result.  Replace the first two
sentences [26:10-11] with "shall be a pure function with explicit
interface and at least two scalar, nonallocatable, nonpointer arguments
of the same declared and dynamic type and type parameters as A.  If it
has more than two arguments, all arguments after the second argument
shall be optional.  Its result shall have the same declared and dynamic
type and type parameters as A."  At [26:12], delete "The arguments and
result shall not be polymorphic."

------------------------------------------------------------------------
EVENT_QUERY should be a type-bound function, not an intrinsic function.

3. Editorial
============

"C509x (R624) 
[13:8] If this is not required to be the same SYNC TEAM statement,
replace "executed a" with "executed any".  Otherwise, replace "executed
a" with "executed the same".

[15:4] Replace the semicolon with a comma.

[15:18] Part of the sentence is passive voice and part is active voice. 
Replace "Execution of" with "Executing".

[16:22] After "STAT_UNLOCKED" insert "in that module".

[17:13] Insert "of" before "type".

[18:25+9 NOTE7.5:2] Specifying "Event variables of EVENT TYPE" implies
that there are event variables of other types, to which the note does
not apply.  Remove "of type EVENT TYPE" because [17:8] defines an event
variable to be a variable of EVENT TYPE.

[24:38-39 8.4.11] Delete "It shall ... current team." because it cannot
be otherwise.  See 8.3p1.

[25:22-23 8.4.12] Delete "It shall ... current team." because it cannot
be otherwise.  See 8.3p1.

[26:3-4 8.4.13] Delete "It shall ... current team." because it cannot
be otherwise.  See 8.3p1.

[26:37-38 8.4.14] Delete "It shall ... current team." because it cannot
be otherwise.  See 8.3p1.

[28:5 8.4.16] Move the first sentence "If TEAM ... current team" to the
description of the TEAM argument.  It has nothing to do with the result
value.

[29:12 8.4.18] Move the first sentence "If TEAM ... current team" to the
description of the TEAM argument.  It has nothing to do with the result
value.

[29:29 8.4.19] Move the first sentence "If TEAM ... current team" to the
description of the TEAM argument.  It has nothing to do with the result
value.

[30:5 8.4.20] Move the first sentence "If TEAM ... current team" to the
description of the TEAM argument.  It has nothing to do with the result
value.

[44:8-20] Edits to Annex A are needed for the case of a
processor-dependent value being assigned to a STAT argument in a
reference to an atomic or collective intrinsic procedure.