Subject: SC 22 N 3535 - Summary of Voting on SC 22 N 3501, Concurrent Regi stration and Approval Ballot for CD 1539-1, Fortran - Part 1

From: Matthew Deane <[email-masked]>
Date: Fri, 10 Jan 2003 08:57:16 -0500

ISO/IEC JTC 1/SC22
Programming languages, their environments and system software interfaces
Secretariat:  U.S.A.  (ANSI)

ISO/IEC JTC 1/SC22 N3535

TITLE:
Summary of Voting on SC 22 N 3501, Concurrent Registration and Approval
Ballot for CD 1539-1, Fortran - Part 1 

DATE ASSIGNED:
2003-01-10

SOURCE:
SC 22 Secretariat

BACKWARD POINTER:
N/A

DOCUMENT TYPE:
Summary of Voting

PROJECT NUMBER:
22.02.01.01

STATUS:
The results of this ballot are forwarded to SC 22/WG 5 for review and
appropriate action.  This project has been registered at the CD stage on the
SC 22 programme of work.  The US comments can be found at the following:
http://www.dkuug.dk/jtc1/sc22/def/n3535-1.pdf

ACTION IDENTIFIER:
ACT

DUE DATE:
N/A

DISTRIBUTION:
Text

CROSS REFERENCE:
SC 22 N3501

DISTRIBUTION FORM:
Def

Matt Deane
ANSI
25 West 43rd Street
New York, NY  10036
Telephone:  (212) 642-4992
Fax:             (212) 840-2298
Email:  [email-masked]

_____end of cover page, beginning of document______________

SUMMARY OF VOTING ON 

Letter Ballot Reference No:  SC22 N3501
Circulated by:                JTC 1/SC22 
Circulation Date:            2002-09-27
Closing Date:                 2002-12-27 
SUBJECT:  Summary of Voting on SC 22 N3501, Concurrent Registration and
Approval Ballot for CD 1539-1, Fortran - Part 1 
---------------------------------------------------------------------- 
The following responses have been received on the subject of registration: 

"P" Members supporting registration without comments
13 (Canada, China, Czech Republic, Denmark, Japan, Republic of Korea,
Netherlands, Norway, Russian Federation, Switzerland, United Kingdom,
Ukraine, USA) 

P" Members supporting registration with comments              
-      

"P" Members not supporting registration
1 (Germany)

"P" Members abstaining                    
1 (France) 

"P" Members not voting                    
9 (Austria, Belgium, Brazil, Egypt, Finland, Ireland, DPR of Korea, Romania,
Slovenia) 

___________ end of registration ballot, beginning of approval ballot
_____________

SUMMARY OF VOTING ON 

Letter Ballot Reference No:  SC22 N3501
Circulated by:                JTC 1/SC22 
Circulation Date:            2002-09-27
Closing Date:                 2002-12-27 
SUBJECT:  Summary of Voting on SC 22 N3501, Concurrent Registration and
Approval Ballot for CD 1539-1, Fortran - Part 1 
---------------------------------------------------------------------- 
The following responses have been received on the subject of approval: 

"P" Members supporting approval without comments
10 (Canada, China, Czech Republic, Denmark, Republic of Korea, Netherlands,
Norway, Russian Federation, Switzerland, Ukraine) 

P" Members supporting approval, with comments              
3 (Japan, United Kingdom, USA)        

"P" Members not supporting approval
1 (Germany)

"P" Members abstaining                    
1 (France) 

"P" Members not voting                    
9 (Austria, Belgium, Brazil, Egypt, Finland, Ireland, DPR of Korea, Romania,
Slovenia) 

___________ end of approval ballot, beginning of NB comments _____________

Germany
The DIN Fortran working group appreciates the huge time investment 
and effort by many individuals, especially the members of the 
primary development body, to create the present document and to 
do so on time.  However, depite this heroic effort, DIN believes 
that the current document is not sufficiently mature to pass 
this vote.  

In particular, DIN believes that some key decisions in the past 
have led to a very dangerous situation for Fortran, and the current 
document as well as the current ballot seem to indicate this.  

1. The proposed Fortran language and document are TOO LARGE AND 
MUCH TOO COMPLEX for anyone to learn or read completely.  The 
few who will need to read the document in its entirety are either 
members of a Fortran committee or professional implementors of 
Fortran (and there is a lot of overlap in these two sets).  Even 
potential authors of secondary literature will most likely shy 
away from the task unless they happen to be long-term committee 
members.  And there is absolutely no way to write a simple, 
straightforward book on THIS language unless you consciously drop 
a huge number of details and special rules.  

In any case, it will be extremely difficult to educate and train 
the typical Fortran programmer in this language, or even to 
convince him/her that there is useful stuff in the new standard 
(it has been difficult enough with F90 and F95).  So it seems the 
only real experts left will be people who are NOT USING the 
language (but maybe implementing it).  L'art pour l'art?  

2. The standardization process has become seriously DISCONNECTED 
from the Fortran user community.  Judging by its turnout, the 
national US ballot that closed in November clearly proves this 
point: apparently, there is nobody left out there who is willing 
to comment (or capable of commenting?) on this document.  
That is a disaster!  

3. The other disastrous impression we have been getting over the 
past few years is that the language is collapsing under its own 
weight and complexity and has become UNMANAGEABLE even for the 
experts.  Long discussions on hundreds of major and minor 
issues have been going on for so long and still seem to be going 
at full speed, even right through (and in) this ballot, that 
one has to wonder whether there is any convergence.  Some issues 
that came up in the CCI process took the few remaining Fortran 
experts of this world many meetings and sometimes several years 
to sort out, and the final decision occasionally depended on 
recollections of discussions and perceived intentions at meetings 
that took place many years ago.  And the stream of new problems 
and interpretation requests is not abating.  

It seems that there are two main ingredients in this infernal 
cocktail that make it uncontrollable: 

- the multitude of language levels and styles due to evolving 
programming paradigms (and due to the requirement that the new 
standard must essentially be compatible with the previous four), 
and 

- the lack of any kind of formalism or formal notation to define 
the semantics of the language in the standard.  (Modula-2 has had a 
single request for interpretation in the last five years, and they 
were able to find the unambiguous answer by taking a close look at 
their formal description of the semantics - no change required.)  

There was a brief chance in Cadarache to stop evolving the old 
language and to further develop only its modern parts, but we 
missed that chance . . . 

4. The current revision does not focus on the PRIMARY INTERESTS 
and the most pressing needs of the Fortran community.  Fortran's 
viability depends crucially on its acceptance and usefulness in 
the NUMERICAL AND SCIENTIFIC COMPUTING community, and a significant 
portion of that community is also in the PARALLEL AND HPC BUSINESS.  
It is our conviction that, had any other language (including C++) 
delivered more than half the runtime performance of Fortran code 
consistently on large (vector or parallel) computers, the danger of 
losing the HPC community would be imminent.  Honestly, we 
really haven't done much for them since Fortran 95 (except for 
much better IEEE support, but true exception handling is still 
sorely missing, for example).  

Conclusion: 
-----------

In the interest of Fortran's future and longevity, we urge WG5 
to review the current list of new features and their priorities 
in light of the current state of the document as well as the 
current situation of the Fortran community and market.  

We list our opinion on some features that are currently included as 
well as a few that are currently not included.  This list could 
be much, much longer . . . 

a) At least some of the OOP language is not nearly as important 
for the typical Fortran user as we may have thought (some committee 
members have been thinking along these lines, e.g. Dan Nagle in his 
recent article in Fortran Forum, and Keith Bierman in his recent 
comment).  Of course, this is difficult to disect now . . . 

b) Should we not have initializers?  

c) We probably all wish Interoperability with C were a bit 
simpler.  In retrospect, do we think it was worth the time and 
effort, and do we believe that it will have any "political" or 
"strategic" impact?  

d) Derived-type I/O became ugly and complicated when it had to 
be paired with the traditional Fortran way of performing I/O 
(synchronized traversal of format list and I/O item list).  
Maybe we should have started a new I/O paradigm at this point 
(procedural approach as in many other languages), but then what 
about format strings?  

e) Good IEEE support is certainly a must for Fortran, but using 
our facility is very cumbersome and awkward if you want to write 
truly portable code.  The number of cases to distinguish grows 
exponentially with the number of features that may or may not 
be supported.  Is there a remedy?  

f) Some IEEE features would be more useful if they were also 
accessible in another way.  For example, instead of having to 
explicitly set the rounding mode and then perform an arithmetic 
operation, it would be useful to also provide the rounded 
operators directly, e.g. .ADDUP. or +> .  This would make the 
implementation of interval arithmetic easier (and possibly more 
efficient if rounded operations are provided directly in hardware).  

g) Good exception handling is crucial for writing robust code 
in any application area, and this is certainly true for numerical 
programs.  Both C++ and Java provide excellent models --- why 
can't we do this?  John Reid's proposal was an excellent starting 
point, and it is one of the darkest chapters of Fortran history 
that it was killed.  2004 is MUCH TOO LATE for this, but can we 
really afford to do it EVEN LATER?  Every serious numerical library 
and program is suffering because this feature is lacking.  

h) We agree with the UK's technical comment TC10 that the automatic 
(deallocation and) allocation of a left-hand side ALLOCATABLE array 
during assignment should finally be allowed and is LONG overdue.  
The ALLOCATABLE array concept was severely crippled right from the 
beginning because you could not and you still cannot have a 
right-hand side whose shape is only determined at runtime.  

i) We also agree with the UK that some features should be simplified 
or possibly deleted altogether, e.g. with their comments TC2, TC3, 
TC6, TC8, TC9, TC10 (see above), MTC6, MTC7, MTC8, MTC9, and MTC11, 
at least.  

j) A facility that allows the specification of the precedence of an 
operator with a user-defined operator name is long overdue and will 
not do any harm as some would make you believe.  Let those who want 
to mimick their usual notation as closely as possible do as they 
like.  This will have absolutely no effect on those who do not want 
to use this feature.  Freedom!!  

k) (see Van Snyder) Separating the specification/definition from the 
implementation/body of a module should have been done right from the 
beginning, and some of us who had some Modula-2 experience were 
advocating this very early.  Why were we not able to learn from 
Modula-2?  Because some of us were hardly ready to even accept 
modules, let alone more advanced variants.  

l) Taking interface blocks out of the normal host association 
rules was among the biggest blunders we ever made, and the reason 
for doing it was so unimportant and wrong (somebody wanted to save 
a bit of time instead of taking a few minutes to look at his/her 
code more carefully).  As we understand the current situation, one 
can now selectively IMPORT entities defined in the host module 
containing the current interface block.  Wouldn't it be helpful 
(and easier) to (also?) simply allow USE M of the enclosing host 
module M, with the understanding that you get normal host association, 
not just a view of the PUBLIC entities?  

Once we allow USEing the host module, we may as well allow ONLY and 
get rid of IMPORT entirely.  Seriously, do we really want yak (= yet 
another keyword)?  

m) For the following reasons we oppose an alternative, redundant
and thus superfluous notation for array constructors in general and
the use of square brackets for this purpose in particular:

1. There is absolutely NO technical reason why Fortran should need
yet another purely syntactic variant of an existing, well
established and perfectly good notation (there are too many ways
to say the same things already) --- especially since the proposed
syntax is really a purely LEXICAL variant of a notation that was only
introduced by the Fortran 90 standard (the beginning of the "modern"
era for Fortran).

Indeed, just two simple global change commands in any editor
will suffice to perform this local, context-free transformation:
'[' -> '(/' and ']' -> '/)'  --- if you are willing to accept that
these changes will also be made in character literals and in comments.

2. Most syntactic variants were introduced into Fortran in order to
improve the readability, reliability and security of Fortran code,
not just the notation of an old (F66 or F77) feature/concept.
In fact, they often led to important generalizations or other
substantial enhancements of the functionality of the language.
Noteworthy examples of this are ends of DO loops (and other
block-structured syntax elements), attributes in type declarations,
kind parameters, etc. .

In the present case we cannot discern an enhancement of the existing
language in any respect.  Also, the proposed use of square brackets
is highly unvonventional in mathematics and unusual in general
programming languages (some specialized mathematical systems such 
as Maple are an exception).

3.  The Fortran committees have repeatedly rejected new ways of
saying the same thing, especially if it was only a different spelling.
The long discussions about CONSTANT as an alternative spelling for
the PARAMETER attribute spring to mind.  It was rejected in the
late phases of defining Fortran 90, and we believe it was discussed
and rejected again for Fortran 95.

4. Some of the most popular languages around, among them C, C++, and
Java, use CURLY BRACES { } to enclose the array elements in an array
notation, and that is not the only use of braces in these languages.

In these and many other languages since Algol 60, square brackets [ ]
are used for array dimensioning and indexing, but NOT for array
construction.  Pascal also uses square brackets to construct sets, but
not arrays (Pascal does not provide array constructors).  Modula-2
does not provide array constructors either, but switches to braces
for set construction, having discontinued the use of braces for
comments.  Square brackets are used for subrange types and for array
indexing in Modula-2.

Interestingly enough, Ada folows the example of Algol 68 and uses
normal parentheses ( ) for array constructors.  However, this is
not an option in Fortran since it would result in ambiguities.

5. Array constructors were only introduced into Fortran through the
Fortran 90 standard, and the decision then was that Fortran (or
computers or the world) were not ready to use previously unused
characters for this purpose.

What has changed since the late 80's?  Not much, really, except
that the percentage of systems that do not have square brackets and
curly braces in their character set has dwindled even further.

Is that a reason to use these characters now?  Not necessarily, but
their use should certainly be considered.

If Fortran really wants to, after almost 50 years of existence, start
using these "new" characters, then it should do so very carefully and
very deliberately, and with the consciousness that [ ] and { } are
probably the ONLY bracketing characters besides ( ) there will ever
be (for all practical purposes).  

Does Fortran really want to waste one of these two pairs of symbols
on a redundant notation, thus precluding much more interesting uses,
e.g. in parallel and high performance computing, for intervals, etc. ?

We do not see Fortran ready to take this historic step at this time.
Before making such an irreversible decision, we strongly recommend a 
thorough investigation and discussion of the potential uses of these
"precious" symbols.

Japan
On approval, Japan's vote is "Yes with comments".  The comments are 
all typographical or editorial and ordered by [page:line] as follow:

[2:24]   Change "(4.4)" to "(4.2)".
[13:32]  Add the case of a scoping unit of an interface body to "all 
         program units and subprograms" to justify the "IMPORT state-
         ments" in Table 2.1.
[24:7+]  In Table 3.1, change "Vertical bar" to "Vertical line", i.e. 
         the name of "|" in ISO/IEC 646 and ISO/IEC 10646.
[71:6+]  In NOTE 5.5, line 12, change "matrix" to "humongous_matrix".
[91:16+] In NOTE 5.36, line 6, change "need" to "need to".
[109:4]  Move the rule R632 after R626.
[121:7+] In Table 7.1, change "C  I,R  L,L" to "C  C  L" for rel-ops.
[173:27] Delete "or a file positioning statement".  This clause has 
         been here for long, but we found it unnecessary and confusing.
[253:12] Exchange this paragraph and the next.
[255:9-24] Move all the R rules immediately after R1205.  C1202 has 
         a forward reference and is hard to read.
[258:5]  Adjust the space between "7.1.3" and "7.1.8.7".
[261:13+] NOTE 12.14 should refer to NOTE 7.42.
[265:9-10] The restriction that an actual argument corresponding to a 
         polymorphic dummy argument must be polymorphic is, in our 
         opinion, surprising, even in the case of dummy argument that 
         is allocatable or pointer.  Add a note explaining the intent.
[292:9]  Change "total number" to "Total number".
[333:(positional)7]  Add ")" after "FROM (12.7.3".
[353:6-10] Exchange and renumber Subsections 13.8.1 and 13.8.2.
[362:26] Change "[P,][R]" to "[P,R]".
[378:] In NOTE 14.14, Change "--" to "-".
[379:] In NOTE 14.15, Change "--" to "-" thrice.
====================================================================

United Kingdom
UK Comments.
The BSI Fortran Panel wishes to congratulate the Fortran primary
development body on bringing this major revision of the ISO Standard to
the public ballot stage on schedule.

A number of changes are proposed in the UK comments. These are in the
nature of regularizing, simplifying and/or clarifying the language and
do not introduce new concepts. It is intended, if they are approved,
that their adoption should not delay final publication of the revised
Standard. Members of the BSI Fortran Panel will provide detailed edits
for all proposed technical changes in papers to be submitted to the
joint WG5/J3 meeting in March and April 2003. 

The comments are divided into three groups: technical changes, minor
technical changes and edits. Detailed edits for the first two groups
will be provided later. Comments in the 'edit' group mostly relate to
minor corrections or clarifications. Where the reason is not
self-evident, a short rationale is attached; where detailed text is not
supplied, it will be provided before the March/April 2003 meeting. 

TECHNICAL CHANGES

TC1 Provide more support for ISO 10646. 

ISO 10646 support is incomplete in that there is no support for:
- any of the file formats defined by ISO 10646; different file
format choices will inhibit portability,
- reading/writing numeric data to/from 10646 variables, and
- mixing ASCII and 10646 data, despite 10646 being a superset of ASCII.
Additionally, there are restrictions on reading/writing ASCII
characters in a 10646 environment which appear to be impossible to
check.

The following features should be added to the standard to correct this:
- allow the file format to be specified (to be UTF-8).
- reading/writing numeric data to 10646 variables.
- reading default character or ASCII data into 10646 variables.
- assignment of default character or ASCII variables to 10646 variables.
These requirements only to apply to processors which support ISO 10646.

Edits will be needed to sections 4.4.4, 7.4.1, 9.4.5.8 and 10.6
(pages 38, 139-140, 183 and 224).

TC2 Remove the option of re-specifying the accessibility and default
initial value for the parent component when a type is extended

This complicates the language with little benefit.

TC3 Allow default initialization of parameter values of derived types

This is an editorially easy change to make and will lead to
consistency with the properties of intrinsic types.

TC4 Change type-bound generics to be sets of specific named type-bound
procedures.

The generic type-bound procedure facility is difficult to understand and 
unnecessarily difficult to implement. It's confusing for the user when 
you explain that generic resolution produces a "slot number" in the 
dispatch table instead of a name.

This confusion arises at least partly because although normal generics 
are a collection of (named) normal procedures, type-bound generics are a 
collection of UNNAMED type-bound procedures created by compiler magic 
from the list of the actual procedures implementing them at some level.

It's also difficult to understand when, during inheritance, one is 
extending the generic vs. overriding an already-existing specific, 
precisely because the specifics don't have names.

Section 4.5.1
Page 44
Syntax change: Instead of GENERIC :: <generic-spec> => <procedure-list>
have GENERIC :: <generic-spec> => <type-bound-proc-list>

Concomitant change:
(a) The GENERIC statement always adds new specifics to the list, it 
never overrides them.
(b) To override a specific within a generic, you use the specific name 
on the PROCEDURE statement, just like nongeneric tbps.
i.e. to override a specific, you specific *the specific name*,
to extend the generic, you specify *the generic spec*.

Advantages:
(1) Simpler exposition.
(2) Simpler implementation.
(3) Programs will be simpler to understand and maintain, because of the
differentiation between overriding and extending.

Disadvantages:
(1) The user has to name the specifics instead of the compiler doing 
all the work.
(2) The specific names have to be public if the user wants them to be
overridable.

TC5 Remove the facility to add type parameters during type extension.

A derived type statement with an EXTENDS clause shall not declare
any type parameters.

The current description is incorrect, as SELECT TYPE provides no
way to discover the values of any kind type parameters that were
added during type extension. Furthermore, this feature complicates
the language and adds little benefit.

TC6 Allow a CLASS(*) pointer to point to an object of any type, 
including an intrinsic type.

The restrictions are not necessary and exclude useful
functionality. An example is for sorting of data of any type for
which the ordering operators are defined.

One should be able to select for intrinsic types in a SELECT TYPE
construct.

Pointer assignment should allow <data-pointer-object> to be of a
non-extensible derived type when <data-target> is a pointer of
CLASS(*) and has the dynamic type of <data-pointer-object>.

TC7 Allow any non-SEQUENCE type to be extended.

There is no technical reason for the requirement that only
extensible types can be extended; therefore it should be possible
to extend any non-SEQUENCE derived type. However, SELECT TYPE
should continue to require that its type guards specify extensible
types (or intrinsic types).

TC8 Remove the TYPEALIAS facility

This complicates the language and adds little benefit.

TC9 Remove the ENUM facility. 

ENUM complicates the language and adds little to the Fortran
language per se; it appears to be of use only in conjunction with
C. Moreover this definition inhibits future development of a more
useful enumeration type.

TC10 Treat the assignment to an allocatable array in the same way as to
an allocatable array component

Allocatable array assignment should be user-friendly the same way that 
allocatable component assignment is; that is, the destination array 
should be reallocated to the correct shape if it is of the incorrect 
shape. Thus, instead of having to say:
DEALLOCATE (A)
ALLOCATE (A(SIZE(COMPRESS(B))))
A = COMPRESS(B)
one should be able to say
A = COMPRESS(B)
and have the same effect (except that if A has the TARGET attribute
and is already the same size as B, it should be reused rather than
go through the allocate-deallocate cycle - for compatibility with
F90/95).

TC11 Allow reallocation of allocatable arrays

It should be possible to reallocate arrays; given the existence of
the RESHAPE function this should apply to arrays of any rank. The
value preserved should be via array element ordering, as with
RESHAPE. We prefer a REALLOCATE procedure but could accept a
facility like the SWAP_ALLOCATION procedure which has been
suggested.

MINOR TECHNICAL CHANGES

MTC1 Reword "NONKIND" as "EXTENT"

NONKIND excludes the possibility of extending to other non-
kind parameters in future.

MTC2 Remove ambiguities re VOLATILE 

The text needs to be clarified to avoid the problem of a variable being
referenced while it is in the process of being changed.

Possible edits are the following: 

Page 83: 8+ Add:
If the value or properties of an object with the VOLATILE attribute
are changed by means not specified in this standard, any change
shall appear to the Fortran program as if it had taken place
immediately before or immediately after the execution of an executable
Fortran statement. Furthermore, when executing the statement
immediately following such a change, the object shall be in a
consistent state as if it had been changed by operations defined by
this standard.

and replace Note 5.23 by: 
The Fortran processor should use the most recent definition of a
volatile object when a value is required, should make the most
recent Fortran definition available, and should ensure that the
above consistency rule holds. It is the programmer's
responsibility to manage the interactions with the non-Fortran
processes and to obey any constraints documented by the Fortran
processor.

MTC3 Resolve ambiguity re asynchronous i/o

It is not clear whether pending i/o operations must be performed in
order of program execution, in order for each unit, or may be
performed in any order. The sentence 189:2-4 is ambiguous and 
needs to be changed. 

MTC4 Resolve ambiguity re error handing with asynchronous i/o

What happens if an error occurs while several i/o statements are
pending?

A possible edit is the following:
Page 189: 15+. Add new note 9.30a:
If an asynchronous data transfer is pending when a synchronous data
transfer is started on the same unit, or multiple asynchronous data
transfer statements are waited on out of order, and an error
condition occurs on any of them, it is processor dependent on which
of the transfer or transfers it will be indicated, though it shall
be indicated at least once.

MTC5 Allow edit descriptors such as 1P2E12.4

This was a Fortran 66 facility which appears to have been omitted
by oversight. 

A possible edit is the following:
Page 219:19. Change "descriptor" to "descriptor, possibly preceded
by a repeat specifier"

MTC6 Change ACHAR(10) syntax within stream i/o

Special handling of ACHAR(10) is unnatural to Fortran programmers.
We recommend replacement by an intrinsic function such as
NEW_LINE([KIND]), perhaps recommending that it have the value
ACHAR(10).

MTC7 Allow input/output of IEEE exceptional values

Input/output of IEEE "exceptional" values should be specified. 
Currently, if the user has an IEEE infinity (or NaN), i/o is completely 
non-standard. Now that the standard supports IEEE arithmetic, it should 
specify the i/o results, and at least for the infinities should specify 
what they are (for NaNs it would be acceptable to make it "processor-
dependent". Similarly, the results of various intrinsic functions (e.g. 
EXPONENT and FRACTION) should be specified for these values.

MTC8 Add the value IEEE_NOT_IEEE to IEEE_CLASS_TYPE

This is needed for implementing the module on systems which are
basically IEEE, but do not implement all of it. It is analogous to
IEEE_OTHER for IEEE_ROUND_TYPE. It might be needed, for example, if
an unformatted file were written in a program executing with
gradual underflow enabled and read with it disabled.

MTC9 Allow for IEEE extended format

IEEE_SUPPORT_DATATYPE and IEEE_SELECTED_REAL_KIND should handle
IEEE 754 compliant "extended" types. We see no need to make a
distinction between the extended and non-extended IEEE types here.

MTC10 Add a facility for controlling IEEE underflow

There should be a standard way of finding out, and setting on
systems that permit it, the underflow handling mode. Many machines
have settable "abrupt underflow" vs. "gradual underflow" and can
run noticeably faster in abrupt underflow mode. We suggest
adding procedures IEEE_SET_DENORMAL_MODE(HANDLED) and
IEEE_GET_DENORMAL_MODE(HANDLED) with HANDLED of type default
logical. The inquiry function IEEE_SUPPORT_DENORMAL_CONTROL() would
also be appropriate.

MTC11 Have separate types for C data and procedure pointers

Function C_LOC operates on either pointers or functions. In C,
pointers and functions are separate and it is confusing to mix them
in Fortran. There should be a separate type C_FUNPTR for C
function pointers.

MTC12 Make TYPE(C_PTR) be an opaque derived type

TYPE(C_PTR) should be required to be an opaque derived type. Allowing 
it to be an (alias for) integer invites unreliable programming 
practices.

MTC13 Require the prototype of an interoperable C function not have 
the inline function specifier

This is needed to remove possible linkage difficulties

A possible edit is the following:
Page 389:18+. Add: 
(7) The C function prototype does not have the inline function 
specifier.

MTC14 Add further requirement for C interoperability

Certain aspects of C interoperability have not been addressed: the
following additional requirements appear to be needed:

A C procedure shall not:
(1) invoke longjmp where this would imply leaving an active Fortran 
procedure.
(2) use signal (C std, 7.14.1) to change the handling of any exception 
that occurs in a Fortran routine or which is being handled by the 
Fortran processor.
(3) perform i/o to a file that is currently connected to a Fortran 
unit, if a Fortran procedure has performed or will perform i/o 
to that unit.
(4) close a file that is currently connected to a Fortran unit.
(5) alter the floating-point status other than by setting an 
exception flag to signalling.

If a C procedure reads the floating-point exception flags on entry,
the result is processor-dependent.

MTC15 Specify that the PROCESSOR_DEPENDENT i/o rounding mode should 
not depend on the rounding mode used for arithmetic

It appears that there are no requirements on the "PROCESSOR_DEPENDENT"
i/o rounding mode, so this could vary depending on the rounding mode
used for arithmetic. That would be unfortunate and confusing.
Suggested edit:
Page 229:10
Change "other modes" to "other modes, and is not affected by the 
rounding mode used for arithmetic (14.3)".

EDITS

E1 Sections 4.5.1 and 12.3.2.1
Generic bindings and abstract interfaces are inadequately described. 
Further notes and examples are needed.

E2 Sections 4.5.1.4 and 4.5.8
Page 49 - Note 4.28 and page 59 Note 4.55
Change the variable name 'abstract' in the example to 'summary' or 
'synopsis' so as to avoid confusion with abstract interfaces in a text 
search.

E3 Section 6.3.1.1
Page 111:4
Before "except" insert "corresponding to a nonallocatable dummy
argument".

E4 Section 8.1.4
Page 160:2-4
There is need for a rationale for using this construct along the lines 
of its increasing efficiency and avoiding the need for using the TARGET 
attribute. More detailed text will be submitted in due course.

E5 Section 9
Page 171:16
After "file storage units" add "(9.2.4)"

E6 Section 9
Page 171:21
Change "external file" to "external file (9.2)" and change "internal 
file" to "internal file (9.3)"

E7 Section 9.4.1
Page 179:8
Change ", pad mode (9.5.3.4.2), and scale factor (10.7.5)" to "and pad 
mode (9.5.3.4.2)"

Page 179:15
Delete the sentence "The scale factor ... 0."
Rationale: Correction. The scale factor is not accessed by the OPEN 
statement.

E8 Sections 9.5.3.7 and 10.6.5
The description of user-defined derived-type input/output at 9.5.3.7, 
although lengthy, is not very clear. The description at 10.6.5 is 
inadequate. In both cases further examples would be helpful, either in 
the text or in Annex C.

E9 Section 9.5.3.7.2
Page 199:8
Change "dtio-generic-spec" to "dtio-generic-spec(R1208)"
Page 199:16 and 199:32
Change "generic_spec" to "dtio_generic_spec"

E10 Section 9.5.3.7.2
Page 201:17+
In Note 9.45 change "chose" to "choose".

E11 Section 9.6.2
Page 204:23
Change: "A wait operation terminates a pending data transfer
operation" to "A wait operation terminates (9.5.4) a pending data
transfer operation".
Rationale: Without careful reading of 9.6.1, this could be
interpreted to mean that the wait interrupts and stops a data
transfer operation.

E12 Section 9.7.1
Page 206:0+
Change: "ERR=20" to "IOSTAT=N"

E13 Section 9.8
Page 207:17+
Change in Note 9.59: "ERR=20" to "IOSTAT=N"

E14 Section 9.8
Page 207:17+
Change in Note 9.58: "left vague" to "not closely defined"

E15 Section 11.2
Page 246:6
Change "not themselves" to "not necessarily themselves"

E16 Section 14
Page 355:20+. Add new note:
NOTE 14.1a The reason that IEEE_INVALID is not required always in 
IEEE_EXCEPTIONS is to allow a non-IEEE processor to provide support
for overflow and divide_by_zero. On an IEEE machine, invalid is an
equally serious condition. 

E17 Section 14.2
Page 357:17
Change "examples" to "possible examples"
Rationale: Not all CPUs will flag over-large integer values as an error.

E18 Section 14.3
Page 359:20+
Add at the end of the paragraph: "The rounding mode may affect the 
result of an intrinsic function."

E19 Section 14.7
Page 360:18-19
Replace "arithmetic operators" by "operators of addition, subtraction 
and multiplication"
Page 360: 23-25
Replace "For each ... normalized" by "For each of the operators for 
addition, subtraction and multiplication, the result shall be as 
specified in the IEEE standard whenever the operands or arguments and 
IEEE result are normalized (if a floating-point value) or valid and 
within range (if some other type of value).
Rationale: Exponentiation is not an IEEE operation. Fortran division is 
defined differently from IEEE division.

E20 Section 14.7
Page 360: 28-29 and page 361:3.
Change 'is as specified in the IEEE standard' to 'shall be
consistent with the specifications in the IEEE standard'.
Rationale: The IEEE does not specify all the Fortran intrinsics. 

E21 Section 14.7
Page 361:3+
Add new paragraph: "The inquiry function IEEE_SUPPORT_DENORMAL is 
provided to inquire whether the processor supports IEEE denormals. Where 
these are supported, their behavior for unary and binary operations, 
including those defined by intrinsic functions and by functions in 
intrinsic modules, is as specified in the IEEE standard."
Rationale: Provides description for IEEE_SUPPORT_DENORMAL and 
regularizes situation compared to IEEE_SUPPORT_NAN and IEEE_SUPPORT_INF.

E22 Annex E
Page 533
Asterisk is used for so many different purposes in addition to 
multiplication, it is confusing to select only one of them for the 
index. The entry should be removed or should be made comprehensive.
------------------------------end of UK comments-------------------------