From owner-sc22docs@dkuug.dk  Fri Jan 10 14:58:14 2003
Received: (from majordom@localhost)
	by dkuug.dk (8.9.2/8.9.2) id OAA68897
	for sc22docs-domo; Fri, 10 Jan 2003 14:58:14 +0100 (CET)
	(envelope-from owner-sc22docs@dkuug.dk)
X-Authentication-Warning: ptah.dkuug.dk: majordom set sender to owner-sc22docs@dkuug.dk using -f
Received: from email1.ansi.org (email1.ansi.org [12.15.192.17])
	by dkuug.dk (8.9.2/8.9.2) with ESMTP id OAA68890
	for <sc22info@dkuug.dk>; Fri, 10 Jan 2003 14:58:09 +0100 (CET)
	(envelope-from mdeane@ANSI.org)
Received: by email1.ansi.org with Internet Mail Service (5.5.2653.19)
	id <T1YP2QTG>; Fri, 10 Jan 2003 08:57:18 -0500
Message-ID: <2F81C8110D55D411882A0020356797B2027FDE94@email1.ansi.org>
From: Matthew Deane <mdeane@ANSI.org>
To: "'SC 22 Distribution List'" <sc22info@dkuug.dk>
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
Date: Fri, 10 Jan 2003 08:57:16 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C2B8B0.2F0189A0"
Sender: owner-sc22docs@dkuug.dk
Precedence: bulk

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C2B8B0.2F0189A0
Content-Type: text/plain;
	charset="iso-8859-1"

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:  mdeane@ansi.org

_____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-------------------------



------_=_NextPart_001_01C2B8B0.2F0189A0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2653.12">
<TITLE>SC 22 N 3535 - Summary of Voting on SC 22 N 3501, Concurrent =
Registration and Approval Ballot for CD 1539-1, Fortran - Part =
1</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2 FACE=3D"Courier New">ISO/IEC JTC 1/SC22</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">Programming languages, their =
environments and system software interfaces</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">Secretariat:&nbsp; U.S.A.&nbsp; =
(ANSI)</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Courier New">ISO/IEC JTC 1/SC22 N3535</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Courier New">TITLE:<BR>
Summary of Voting on SC 22 N 3501, Concurrent Registration and Approval =
Ballot for CD 1539-1, Fortran - Part 1 </FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Courier New">DATE ASSIGNED:</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">2003-01-10</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Courier New">SOURCE:</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">SC 22 Secretariat</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Courier New">BACKWARD POINTER:</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">N/A</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Courier New">DOCUMENT TYPE:</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">Summary of Voting</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Courier New">PROJECT NUMBER:</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">22.02.01.01</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Courier New">STATUS:</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">The results of this ballot are =
forwarded to SC 22/WG 5 for review and appropriate action.&nbsp; This =
project has been registered at the CD stage on the SC 22 programme of =
work.&nbsp; The US comments can be found at the following:&nbsp;</FONT> =
<FONT SIZE=3D2 FACE=3D"Courier New"><A =
HREF=3D"http://www.dkuug.dk/jtc1/sc22/def/n3535-1.pdf" =
TARGET=3D"_blank">http://www.dkuug.dk/jtc1/sc22/def/n3535-1.pdf</A></FON=
T></P>

<P><FONT SIZE=3D2 FACE=3D"Courier New">ACTION IDENTIFIER:</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">ACT</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Courier New">DUE DATE:</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">N/A</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Courier New">DISTRIBUTION:</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">Text</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Courier New">CROSS REFERENCE:</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">SC 22 N3501</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Courier New">DISTRIBUTION FORM:</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">Def</FONT>
</P>
<BR>

<P><FONT SIZE=3D2 FACE=3D"Courier New">Matt Deane</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">ANSI</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">25 West 43rd Street</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">New York, NY&nbsp; 10036</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">Telephone:&nbsp; (212) =
642-4992</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier =
New">Fax:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp; (212) 840-2298</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">Email:&nbsp; =
mdeane@ansi.org</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Courier New">_____end of cover page, =
beginning of document______________</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">SUMMARY OF VOTING ON </FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Letter Ballot Reference No:&nbsp; SC22 =
N3501<BR>
Circulated =
by:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp; JTC 1/SC22<BR>
Circulation =
Date:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
2002-09-27<BR>
Closing =
Date:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 2002-12-27 </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">SUBJECT:&nbsp; Summary of Voting on =
SC 22 N3501, Concurrent Registration and Approval Ballot for CD 1539-1, =
Fortran - Part 1</FONT> </P>

<P><FONT SIZE=3D2 =
FACE=3D"Arial">---------------------------------------------------------=
------------- </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">The following responses have been =
received on the subject of registration: </FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">&quot;P&quot; Members supporting =
registration without comments<BR>
13 (Canada, China, Czech Republic, Denmark, Japan, Republic of Korea, =
Netherlands, Norway, Russian Federation, Switzerland, United Kingdom, =
Ukraine, USA) </FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">P&quot; Members supporting =
registration with =
comments&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;<BR>
-&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">&quot;P&quot; Members not supporting =
registration<BR>
1 (Germany)</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">&quot;P&quot; Members =
abstaining&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<BR>
1 (France) </FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">&quot;P&quot; Members not =
voting&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<BR>
9 (Austria, Belgium, Brazil, Egypt, Finland, Ireland, DPR of Korea, =
Romania, Slovenia) </FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">___________ end of registration =
ballot, beginning of approval ballot _____________</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">SUMMARY OF VOTING ON </FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Letter Ballot Reference No:&nbsp; SC22 =
N3501<BR>
Circulated =
by:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp; JTC 1/SC22<BR>
Circulation =
Date:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
2002-09-27<BR>
Closing =
Date:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 2002-12-27 </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">SUBJECT:&nbsp; Summary of Voting on =
SC 22 N3501, Concurrent Registration and Approval Ballot for CD 1539-1, =
Fortran - Part 1 </FONT></P>

<P><FONT SIZE=3D2 =
FACE=3D"Arial">---------------------------------------------------------=
------------- </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">The following responses have been =
received on the subject of approval: </FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">&quot;P&quot; Members supporting =
approval without comments<BR>
10 (Canada, China, Czech Republic, Denmark, Republic of Korea, =
Netherlands, Norway, Russian Federation, Switzerland, Ukraine) =
</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">P&quot; Members supporting approval, =
with =
comments&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;<BR>
3 (Japan, United Kingdom, =
USA)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">&quot;P&quot; Members not supporting =
approval<BR>
1 (Germany)</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">&quot;P&quot; Members =
abstaining&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<BR>
1 (France) </FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">&quot;P&quot; Members not =
voting&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<BR>
9 (Austria, Belgium, Brazil, Egypt, Finland, Ireland, DPR of Korea, =
Romania, Slovenia) </FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">___________ end of approval ballot, =
beginning of NB comments _____________</FONT>
</P>
<BR>
<BR>

<P><U><B><FONT FACE=3D"Arial">Germany</FONT></B></U>
<BR><FONT SIZE=3D2 FACE=3D"Arial">The DIN Fortran working group =
appreciates the huge time investment </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">and effort by many individuals, =
especially the members of the </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">primary development body, to create =
the present document and to </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">do so on time.&nbsp; However, depite =
this heroic effort, DIN believes </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">that the current document is not =
sufficiently mature to pass </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">this vote.&nbsp; </FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">In particular, DIN believes that some =
key decisions in the past </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">have led to a very dangerous =
situation for Fortran, and the current </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">document as well as the current =
ballot seem to indicate this.&nbsp; </FONT>
</P>
<BR>

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

<P><FONT SIZE=3D2 FACE=3D"Arial">In any case, it will be extremely =
difficult to educate and train </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">the typical Fortran programmer in =
this language, or even to </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">convince him/her that there is useful =
stuff in the new standard </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">(it has been difficult enough with =
F90 and F95).&nbsp; So it seems the </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">only real experts left will be people =
who are NOT USING the </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">language (but maybe implementing =
it).&nbsp; L'art pour l'art?&nbsp; </FONT>
</P>
<BR>

<P><FONT SIZE=3D2 FACE=3D"Arial">2. The standardization process has =
become seriously DISCONNECTED </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">from the Fortran user =
community.&nbsp; Judging by its turnout, the </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">national US ballot that closed in =
November clearly proves this </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">point: apparently, there is nobody =
left out there who is willing </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">to comment (or capable of =
commenting?) on this document.&nbsp; </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">That is a disaster!&nbsp; </FONT>
</P>
<BR>

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

<P><FONT SIZE=3D2 FACE=3D"Arial">It seems that there are two main =
ingredients in this infernal </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">cocktail that make it uncontrollable: =
</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">- the multitude of language levels and =
styles due to evolving </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">programming paradigms (and due to the =
requirement that the new </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">standard must essentially be =
compatible with the previous four), </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">and </FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">- the lack of any kind of formalism or =
formal notation to define </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">the semantics of the language in the =
standard.&nbsp; (Modula-2 has had a </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">single request for interpretation in =
the last five years, and they </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">were able to find the unambiguous =
answer by taking a close look at </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">their formal description of the =
semantics - no change required.)&nbsp; </FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">There was a brief chance in Cadarache =
to stop evolving the old </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">language and to further develop only =
its modern parts, but we </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">missed that chance . . . </FONT>
</P>
<BR>

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

<P><FONT SIZE=3D2 FACE=3D"Arial">Conclusion: </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">-----------</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">In the interest of Fortran's future =
and longevity, we urge WG5 </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">to review the current list of new =
features and their priorities </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">in light of the current state of the =
document as well as the </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">current situation of the Fortran =
community and market.&nbsp; </FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">We list our opinion on some features =
that are currently included as </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">well as a few that are currently not =
included.&nbsp; This list could </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">be much, much longer . . . </FONT>
</P>
<BR>

<P><FONT SIZE=3D2 FACE=3D"Arial">a) At least some of the OOP language =
is not nearly as important </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">for the typical Fortran user as we =
may have thought (some committee </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">members have been thinking along =
these lines, e.g. Dan Nagle in his </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">recent article in Fortran Forum, and =
Keith Bierman in his recent </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">comment).&nbsp; Of course, this is =
difficult to disect now . . . </FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">b) Should we not have =
initializers?&nbsp; </FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">c) We probably all wish =
Interoperability with C were a bit </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">simpler.&nbsp; In retrospect, do we =
think it was worth the time and </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">effort, and do we believe that it =
will have any &quot;political&quot; or </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&quot;strategic&quot; impact?&nbsp; =
</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">d) Derived-type I/O became ugly and =
complicated when it had to </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">be paired with the traditional =
Fortran way of performing I/O </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">(synchronized traversal of format =
list and I/O item list).&nbsp; </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">Maybe we should have started a new =
I/O paradigm at this point </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">(procedural approach as in many other =
languages), but then what </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">about format strings?&nbsp; </FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">e) Good IEEE support is certainly a =
must for Fortran, but using </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">our facility is very cumbersome and =
awkward if you want to write </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">truly portable code.&nbsp; The number =
of cases to distinguish grows </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">exponentially with the number of =
features that may or may not </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">be supported.&nbsp; Is there a =
remedy?&nbsp; </FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">f) Some IEEE features would be more =
useful if they were also </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">accessible in another way.&nbsp; For =
example, instead of having to </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">explicitly set the rounding mode and =
then perform an arithmetic </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">operation, it would be useful to also =
provide the rounded </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">operators directly, e.g. .ADDUP. or =
+&gt; .&nbsp; This would make the </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">implementation of interval arithmetic =
easier (and possibly more </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">efficient if rounded operations are =
provided directly in hardware).&nbsp; </FONT>
</P>

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

<P><FONT SIZE=3D2 FACE=3D"Arial">h) We agree with the UK's technical =
comment TC10 that the automatic </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">(deallocation and) allocation of a =
left-hand side ALLOCATABLE array </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">during assignment should finally be =
allowed and is LONG overdue.&nbsp; </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">The ALLOCATABLE array concept was =
severely crippled right from the </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">beginning because you could not and =
you still cannot have a </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">right-hand side whose shape is only =
determined at runtime.&nbsp; </FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">i) We also agree with the UK that some =
features should be simplified </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">or possibly deleted altogether, e.g. =
with their comments TC2, TC3, </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">TC6, TC8, TC9, TC10 (see above), =
MTC6, MTC7, MTC8, MTC9, and MTC11, </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">at least.&nbsp; </FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">j) A facility that allows the =
specification of the precedence of an </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">operator with a user-defined operator =
name is long overdue and will </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">not do any harm as some would make =
you believe.&nbsp; Let those who want </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">to mimick their usual notation as =
closely as possible do as they </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">like.&nbsp; This will have absolutely =
no effect on those who do not want </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">to use this feature.&nbsp; =
Freedom!!&nbsp; </FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">k) (see Van Snyder) Separating the =
specification/definition from the </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">implementation/body of a module =
should have been done right from the </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">beginning, and some of us who had =
some Modula-2 experience were </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">advocating this very early.&nbsp; Why =
were we not able to learn from </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">Modula-2?&nbsp; Because some of us =
were hardly ready to even accept </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">modules, let alone more advanced =
variants.&nbsp; </FONT>
</P>

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

<P><FONT SIZE=3D2 FACE=3D"Arial">Once we allow USEing the host module, =
we may as well allow ONLY and </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">get rid of IMPORT entirely.&nbsp; =
Seriously, do we really want yak (=3D yet </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">another keyword)?&nbsp; </FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">m) For the following reasons we oppose =
an alternative, redundant</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">and thus superfluous notation for =
array constructors in general and</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">the use of square brackets for this =
purpose in particular:</FONT>
</P>
<BR>

<P><FONT SIZE=3D2 FACE=3D"Arial">1. There is absolutely NO technical =
reason why Fortran should need</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">yet another purely syntactic variant =
of an existing, well</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">established and perfectly good =
notation (there are too many ways</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">to say the same things already) --- =
especially since the proposed</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">syntax is really a purely LEXICAL =
variant of a notation that was only</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">introduced by the Fortran 90 standard =
(the beginning of the &quot;modern&quot;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">era for Fortran).</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Indeed, just two simple global change =
commands in any editor</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">will suffice to perform this local, =
context-free transformation:</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">'[' -&gt; '(/' and ']' -&gt; =
'/)'&nbsp; --- if you are willing to accept that</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">these changes will also be made in =
character literals and in comments.</FONT>
</P>
<BR>

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

<P><FONT SIZE=3D2 FACE=3D"Arial">In the present case we cannot discern =
an enhancement of the existing</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">language in any respect.&nbsp; Also, =
the proposed use of square brackets</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">is highly unvonventional in =
mathematics and unusual in general</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">programming languages (some =
specialized mathematical systems such </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">as Maple are an exception).</FONT>
</P>
<BR>

<P><FONT SIZE=3D2 FACE=3D"Arial">3.&nbsp; The Fortran committees have =
repeatedly rejected new ways of</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">saying the same thing, especially if =
it was only a different spelling.</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">The long discussions about CONSTANT =
as an alternative spelling for</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">the PARAMETER attribute spring to =
mind.&nbsp; It was rejected in the</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">late phases of defining Fortran 90, =
and we believe it was discussed</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">and rejected again for Fortran =
95.</FONT>
</P>
<BR>

<P><FONT SIZE=3D2 FACE=3D"Arial">4. Some of the most popular languages =
around, among them C, C++, and</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">Java, use CURLY BRACES { } to enclose =
the array elements in an array</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">notation, and that is not the only =
use of braces in these languages.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">In these and many other languages =
since Algol 60, square brackets [ ]</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">are used for array dimensioning and =
indexing, but NOT for array</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">construction.&nbsp; Pascal also uses =
square brackets to construct sets, but</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">not arrays (Pascal does not provide =
array constructors).&nbsp; Modula-2</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">does not provide array constructors =
either, but switches to braces</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">for set construction, having =
discontinued the use of braces for</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">comments.&nbsp; Square brackets are =
used for subrange types and for array</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">indexing in Modula-2.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Interestingly enough, Ada folows the =
example of Algol 68 and uses</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">normal parentheses ( ) for array =
constructors.&nbsp; However, this is</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">not an option in Fortran since it =
would result in ambiguities.</FONT>
</P>
<BR>

<P><FONT SIZE=3D2 FACE=3D"Arial">5. Array constructors were only =
introduced into Fortran through the</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">Fortran 90 standard, and the decision =
then was that Fortran (or</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">computers or the world) were not =
ready to use previously unused</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">characters for this purpose.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">What has changed since the late =
80's?&nbsp; Not much, really, except</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">that the percentage of systems that =
do not have square brackets and</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">curly braces in their character set =
has dwindled even further.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Is that a reason to use these =
characters now?&nbsp; Not necessarily, but</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">their use should certainly be =
considered.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">If Fortran really wants to, after =
almost 50 years of existence, start</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">using these &quot;new&quot; =
characters, then it should do so very carefully and</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">very deliberately, and with the =
consciousness that [ ] and { } are</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">probably the ONLY bracketing =
characters besides ( ) there will ever</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">be (for all practical =
purposes).&nbsp; </FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Does Fortran really want to waste one =
of these two pairs of symbols</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">on a redundant notation, thus =
precluding much more interesting uses,</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">e.g. in parallel and high performance =
computing, for intervals, etc. ?</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">We do not see Fortran ready to take =
this historic step at this time.</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">Before making such an irreversible =
decision, we strongly recommend a </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">thorough investigation and discussion =
of the potential uses of these</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&quot;precious&quot; symbols.</FONT>
</P>
<BR>

<P><U><B><FONT FACE=3D"Arial">Japan</FONT></B></U><B></B>
<BR><FONT SIZE=3D2 FACE=3D"Arial">On approval, Japan's vote is =
&quot;Yes with comments&quot;.&nbsp; The comments are </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">all typographical or editorial and =
ordered by [page:line] as follow:</FONT>
</P>

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

<P><U><B><FONT FACE=3D"Arial">United Kingdom</FONT></B></U><B></B>
<BR><FONT FACE=3D"Times New Roman">UK Comments.</FONT>
<BR><FONT FACE=3D"Times New Roman">The BSI Fortran Panel wishes to =
congratulate the Fortran primary<BR>
development body on bringing this major revision of the ISO Standard =
to<BR>
the public ballot stage on schedule.<BR>
<BR>
A number of changes are proposed in the UK comments. These are in =
the<BR>
nature of regularizing, simplifying and/or clarifying the language =
and<BR>
do not introduce new concepts. It is intended, if they are =
approved,<BR>
that their adoption should not delay final publication of the =
revised<BR>
Standard. Members of the BSI Fortran Panel will provide detailed =
edits<BR>
for all proposed technical changes in papers to be submitted to the<BR>
joint WG5/J3 meeting in March and April 2003.<BR>
<BR>
The comments are divided into three groups: technical changes, =
minor<BR>
technical changes and edits. Detailed edits for the first two =
groups<BR>
will be provided later. Comments in the 'edit' group mostly relate =
to<BR>
minor corrections or clarifications. Where the reason is not<BR>
self-evident, a short rationale is attached; where detailed text is =
not<BR>
supplied, it will be provided before the March/April 2003 meeting.<BR>
<BR>
<BR>
TECHNICAL CHANGES<BR>
<BR>
TC1 Provide more support for ISO 10646.<BR>
<BR>
ISO 10646 support is incomplete in that there is no support for:<BR>
- any of the file formats defined by ISO 10646; different file<BR>
format choices will inhibit portability,<BR>
- reading/writing numeric data to/from 10646 variables, and<BR>
- mixing ASCII and 10646 data, despite 10646 being a superset of =
ASCII.<BR>
Additionally, there are restrictions on reading/writing ASCII<BR>
characters in a 10646 environment which appear to be impossible to<BR>
check.<BR>
<BR>
The following features should be added to the standard to correct =
this:<BR>
- allow the file format to be specified (to be UTF-8).<BR>
- reading/writing numeric data to 10646 variables.<BR>
- reading default character or ASCII data into 10646 variables.<BR>
- assignment of default character or ASCII variables to 10646 =
variables.<BR>
These requirements only to apply to processors which support ISO =
10646.<BR>
<BR>
Edits will be needed to sections 4.4.4, 7.4.1, 9.4.5.8 and 10.6<BR>
(pages 38, 139-140, 183 and 224).<BR>
<BR>
TC2 Remove the option of re-specifying the accessibility and =
default<BR>
initial value for the parent component when a type is extended<BR>
<BR>
This complicates the language with little benefit.<BR>
<BR>
TC3 Allow default initialization of parameter values of derived =
types<BR>
<BR>
This is an editorially easy change to make and will lead to<BR>
consistency with the properties of intrinsic types.<BR>
<BR>
TC4 Change type-bound generics to be sets of specific named =
type-bound<BR>
procedures.<BR>
<BR>
The generic type-bound procedure facility is difficult to understand =
and<BR>
unnecessarily difficult to implement. It's confusing for the user =
when<BR>
you explain that generic resolution produces a &quot;slot number&quot; =
in the<BR>
dispatch table instead of a name.<BR>
<BR>
This confusion arises at least partly because although normal =
generics<BR>
are a collection of (named) normal procedures, type-bound generics are =
a<BR>
collection of UNNAMED type-bound procedures created by compiler =
magic<BR>
from the list of the actual procedures implementing them at some =
level.<BR>
<BR>
It's also difficult to understand when, during inheritance, one is<BR>
extending the generic vs. overriding an already-existing specific,<BR>
precisely because the specifics don't have names.<BR>
<BR>
Section 4.5.1<BR>
Page 44<BR>
Syntax change: Instead of GENERIC :: &lt;generic-spec&gt; =3D&gt; =
&lt;procedure-list&gt;<BR>
have GENERIC :: &lt;generic-spec&gt; =3D&gt; =
&lt;type-bound-proc-list&gt;<BR>
<BR>
Concomitant change:<BR>
(a) The GENERIC statement always adds new specifics to the list, it<BR>
never overrides them.<BR>
(b) To override a specific within a generic, you use the specific =
name<BR>
on the PROCEDURE statement, just like nongeneric tbps.<BR>
i.e. to override a specific, you specific *the specific name*,<BR>
to extend the generic, you specify *the generic spec*.<BR>
<BR>
Advantages:<BR>
(1) Simpler exposition.<BR>
(2) Simpler implementation.<BR>
(3) Programs will be simpler to understand and maintain, because of =
the<BR>
differentiation between overriding and extending.<BR>
<BR>
Disadvantages:<BR>
(1) The user has to name the specifics instead of the compiler =
doing<BR>
all the work.<BR>
(2) The specific names have to be public if the user wants them to =
be<BR>
overridable.<BR>
<BR>
TC5 Remove the facility to add type parameters during type =
extension.<BR>
<BR>
A derived type statement with an EXTENDS clause shall not declare<BR>
any type parameters.<BR>
<BR>
The current description is incorrect, as SELECT TYPE provides no<BR>
way to discover the values of any kind type parameters that were<BR>
added during type extension. Furthermore, this feature complicates<BR>
the language and adds little benefit.<BR>
<BR>
TC6 Allow a CLASS(*) pointer to point to an object of any type,<BR>
including an intrinsic type.<BR>
<BR>
The restrictions are not necessary and exclude useful<BR>
functionality. An example is for sorting of data of any type for<BR>
which the ordering operators are defined.<BR>
<BR>
One should be able to select for intrinsic types in a SELECT TYPE<BR>
construct.<BR>
<BR>
Pointer assignment should allow &lt;data-pointer-object&gt; to be of =
a<BR>
non-extensible derived type when &lt;data-target&gt; is a pointer =
of<BR>
CLASS(*) and has the dynamic type of &lt;data-pointer-object&gt;.<BR>
<BR>
TC7 Allow any non-SEQUENCE type to be extended.<BR>
<BR>
There is no technical reason for the requirement that only<BR>
extensible types can be extended; therefore it should be possible<BR>
to extend any non-SEQUENCE derived type. However, SELECT TYPE<BR>
should continue to require that its type guards specify extensible<BR>
types (or intrinsic types).<BR>
<BR>
TC8 Remove the TYPEALIAS facility<BR>
<BR>
This complicates the language and adds little benefit.<BR>
<BR>
TC9 Remove the ENUM facility.<BR>
<BR>
ENUM complicates the language and adds little to the Fortran<BR>
language per se; it appears to be of use only in conjunction with<BR>
C. Moreover this definition inhibits future development of a more<BR>
useful enumeration type.<BR>
<BR>
TC10 Treat the assignment to an allocatable array in the same way as =
to<BR>
an allocatable array component<BR>
<BR>
Allocatable array assignment should be user-friendly the same way =
that<BR>
allocatable component assignment is; that is, the destination array<BR>
should be reallocated to the correct shape if it is of the incorrect<BR>=

shape. Thus, instead of having to say:<BR>
DEALLOCATE (A)<BR>
ALLOCATE (A(SIZE(COMPRESS(B))))<BR>
A =3D COMPRESS(B)<BR>
one should be able to say<BR>
A =3D COMPRESS(B)<BR>
and have the same effect (except that if A has the TARGET attribute<BR>
and is already the same size as B, it should be reused rather than<BR>
go through the allocate-deallocate cycle - for compatibility with<BR>
F90/95).<BR>
<BR>
TC11 Allow reallocation of allocatable arrays<BR>
<BR>
It should be possible to reallocate arrays; given the existence of<BR>
the RESHAPE function this should apply to arrays of any rank. The<BR>
value preserved should be via array element ordering, as with<BR>
RESHAPE. We prefer a REALLOCATE procedure but could accept a<BR>
facility like the SWAP_ALLOCATION procedure which has been<BR>
suggested.<BR>
<BR>
<BR>
<BR>
MINOR TECHNICAL CHANGES<BR>
<BR>
MTC1 Reword &quot;NONKIND&quot; as &quot;EXTENT&quot;<BR>
<BR>
NONKIND excludes the possibility of extending to other non-<BR>
kind parameters in future.<BR>
<BR>
<BR>
MTC2 Remove ambiguities re VOLATILE<BR>
<BR>
The text needs to be clarified to avoid the problem of a variable =
being<BR>
referenced while it is in the process of being changed.<BR>
<BR>
Possible edits are the following:<BR>
<BR>
Page 83: 8+ Add:<BR>
If the value or properties of an object with the VOLATILE attribute<BR>
are changed by means not specified in this standard, any change<BR>
shall appear to the Fortran program as if it had taken place<BR>
immediately before or immediately after the execution of an =
executable<BR>
Fortran statement. Furthermore, when executing the statement<BR>
immediately following such a change, the object shall be in a<BR>
consistent state as if it had been changed by operations defined by<BR>
this standard.<BR>
<BR>
and replace Note 5.23 by:<BR>
The Fortran processor should use the most recent definition of a<BR>
volatile object when a value is required, should make the most<BR>
recent Fortran definition available, and should ensure that the<BR>
above consistency rule holds. It is the programmer's<BR>
responsibility to manage the interactions with the non-Fortran<BR>
processes and to obey any constraints documented by the Fortran<BR>
processor.<BR>
<BR>
MTC3 Resolve ambiguity re asynchronous i/o<BR>
<BR>
It is not clear whether pending i/o operations must be performed in<BR>
order of program execution, in order for each unit, or may be<BR>
performed in any order. The sentence 189:2-4 is ambiguous and<BR>
needs to be changed.<BR>
<BR>
MTC4 Resolve ambiguity re error handing with asynchronous i/o<BR>
<BR>
What happens if an error occurs while several i/o statements are<BR>
pending?<BR>
<BR>
A possible edit is the following:<BR>
Page 189: 15+. Add new note 9.30a:<BR>
If an asynchronous data transfer is pending when a synchronous data<BR>
transfer is started on the same unit, or multiple asynchronous data<BR>
transfer statements are waited on out of order, and an error<BR>
condition occurs on any of them, it is processor dependent on which<BR>
of the transfer or transfers it will be indicated, though it shall<BR>
be indicated at least once.<BR>
<BR>
MTC5 Allow edit descriptors such as 1P2E12.4<BR>
<BR>
This was a Fortran 66 facility which appears to have been omitted<BR>
by oversight.<BR>
<BR>
A possible edit is the following:<BR>
Page 219:19. Change &quot;descriptor&quot; to &quot;descriptor, =
possibly preceded<BR>
by a repeat specifier&quot;<BR>
<BR>
MTC6 Change ACHAR(10) syntax within stream i/o<BR>
<BR>
Special handling of ACHAR(10) is unnatural to Fortran programmers.<BR>
We recommend replacement by an intrinsic function such as<BR>
NEW_LINE([KIND]), perhaps recommending that it have the value<BR>
ACHAR(10).<BR>
<BR>
MTC7 Allow input/output of IEEE exceptional values<BR>
<BR>
Input/output of IEEE &quot;exceptional&quot; values should be =
specified.<BR>
Currently, if the user has an IEEE infinity (or NaN), i/o is =
completely<BR>
non-standard. Now that the standard supports IEEE arithmetic, it =
should<BR>
specify the i/o results, and at least for the infinities should =
specify<BR>
what they are (for NaNs it would be acceptable to make it =
&quot;processor-<BR>
dependent&quot;. Similarly, the results of various intrinsic functions =
(e.g.<BR>
EXPONENT and FRACTION) should be specified for these values.<BR>
<BR>
MTC8 Add the value IEEE_NOT_IEEE to IEEE_CLASS_TYPE<BR>
<BR>
This is needed for implementing the module on systems which are<BR>
basically IEEE, but do not implement all of it. It is analogous to<BR>
IEEE_OTHER for IEEE_ROUND_TYPE. It might be needed, for example, if<BR>
an unformatted file were written in a program executing with<BR>
gradual underflow enabled and read with it disabled.<BR>
<BR>
MTC9 Allow for IEEE extended format<BR>
<BR>
IEEE_SUPPORT_DATATYPE and IEEE_SELECTED_REAL_KIND should handle<BR>
IEEE 754 compliant &quot;extended&quot; types. We see no need to make =
a<BR>
distinction between the extended and non-extended IEEE types here.<BR>
<BR>
MTC10 Add a facility for controlling IEEE underflow<BR>
<BR>
There should be a standard way of finding out, and setting on<BR>
systems that permit it, the underflow handling mode. Many machines<BR>
have settable &quot;abrupt underflow&quot; vs. &quot;gradual =
underflow&quot; and can<BR>
run noticeably faster in abrupt underflow mode. We suggest<BR>
adding procedures IEEE_SET_DENORMAL_MODE(HANDLED) and<BR>
IEEE_GET_DENORMAL_MODE(HANDLED) with HANDLED of type default<BR>
logical. The inquiry function IEEE_SUPPORT_DENORMAL_CONTROL() would<BR>
also be appropriate.<BR>
<BR>
MTC11 Have separate types for C data and procedure pointers<BR>
<BR>
Function C_LOC operates on either pointers or functions. In C,<BR>
pointers and functions are separate and it is confusing to mix them<BR>
in Fortran. There should be a separate type C_FUNPTR for C<BR>
function pointers.<BR>
<BR>
MTC12 Make TYPE(C_PTR) be an opaque derived type<BR>
<BR>
TYPE(C_PTR) should be required to be an opaque derived type. =
Allowing<BR>
it to be an (alias for) integer invites unreliable programming<BR>
practices.<BR>
<BR>
MTC13 Require the prototype of an interoperable C function not have<BR>
the inline function specifier<BR>
<BR>
This is needed to remove possible linkage difficulties<BR>
<BR>
A possible edit is the following:<BR>
Page 389:18+. Add:<BR>
(7) The C function prototype does not have the inline function<BR>
specifier.<BR>
<BR>
MTC14 Add further requirement for C interoperability<BR>
<BR>
Certain aspects of C interoperability have not been addressed: the<BR>
following additional requirements appear to be needed:<BR>
<BR>
A C procedure shall not:<BR>
(1) invoke longjmp where this would imply leaving an active Fortran<BR>
procedure.<BR>
(2) use signal (C std, 7.14.1) to change the handling of any =
exception<BR>
that occurs in a Fortran routine or which is being handled by the<BR>
Fortran processor.<BR>
(3) perform i/o to a file that is currently connected to a Fortran<BR>
unit, if a Fortran procedure has performed or will perform i/o<BR>
to that unit.<BR>
(4) close a file that is currently connected to a Fortran unit.<BR>
(5) alter the floating-point status other than by setting an<BR>
exception flag to signalling.<BR>
<BR>
If a C procedure reads the floating-point exception flags on entry,<BR>
the result is processor-dependent.<BR>
<BR>
MTC15 Specify that the PROCESSOR_DEPENDENT i/o rounding mode should<BR>
not depend on the rounding mode used for arithmetic<BR>
<BR>
It appears that there are no requirements on the =
&quot;PROCESSOR_DEPENDENT&quot;<BR>
i/o rounding mode, so this could vary depending on the rounding =
mode<BR>
used for arithmetic. That would be unfortunate and confusing.<BR>
Suggested edit:<BR>
Page 229:10<BR>
Change &quot;other modes&quot; to &quot;other modes, and is not =
affected by the<BR>
rounding mode used for arithmetic (14.3)&quot;.<BR>
<BR>
<BR>
<BR>
<BR>
EDITS<BR>
<BR>
E1 Sections 4.5.1 and 12.3.2.1<BR>
Generic bindings and abstract interfaces are inadequately =
described.<BR>
Further notes and examples are needed.<BR>
<BR>
E2 Sections 4.5.1.4 and 4.5.8<BR>
Page 49 - Note 4.28 and page 59 Note 4.55<BR>
Change the variable name 'abstract' in the example to 'summary' or<BR>
'synopsis' so as to avoid confusion with abstract interfaces in a =
text<BR>
search.<BR>
<BR>
E3 Section 6.3.1.1<BR>
Page 111:4<BR>
Before &quot;except&quot; insert &quot;corresponding to a =
nonallocatable dummy<BR>
argument&quot;.<BR>
<BR>
E4 Section 8.1.4<BR>
Page 160:2-4<BR>
There is need for a rationale for using this construct along the =
lines<BR>
of its increasing efficiency and avoiding the need for using the =
TARGET<BR>
attribute. More detailed text will be submitted in due course.<BR>
<BR>
E5 Section 9<BR>
Page 171:16<BR>
After &quot;file storage units&quot; add &quot;(9.2.4)&quot;<BR>
<BR>
E6 Section 9<BR>
Page 171:21<BR>
Change &quot;external file&quot; to &quot;external file (9.2)&quot; and =
change &quot;internal<BR>
file&quot; to &quot;internal file (9.3)&quot;<BR>
<BR>
E7 Section 9.4.1<BR>
Page 179:8<BR>
Change &quot;, pad mode (9.5.3.4.2), and scale factor (10.7.5)&quot; to =
&quot;and pad<BR>
mode (9.5.3.4.2)&quot;<BR>
<BR>
Page 179:15<BR>
Delete the sentence &quot;The scale factor ... 0.&quot;<BR>
Rationale: Correction. The scale factor is not accessed by the OPEN<BR>
statement.<BR>
<BR>
E8 Sections 9.5.3.7 and 10.6.5<BR>
The description of user-defined derived-type input/output at =
9.5.3.7,<BR>
although lengthy, is not very clear. The description at 10.6.5 is<BR>
inadequate. In both cases further examples would be helpful, either =
in<BR>
the text or in Annex C.<BR>
<BR>
E9 Section 9.5.3.7.2<BR>
Page 199:8<BR>
Change &quot;dtio-generic-spec&quot; to =
&quot;dtio-generic-spec(R1208)&quot;<BR>
Page 199:16 and 199:32<BR>
Change &quot;generic_spec&quot; to &quot;dtio_generic_spec&quot;<BR>
<BR>
E10 Section 9.5.3.7.2<BR>
Page 201:17+<BR>
In Note 9.45 change &quot;chose&quot; to &quot;choose&quot;.<BR>
<BR>
E11 Section 9.6.2<BR>
Page 204:23<BR>
Change: &quot;A wait operation terminates a pending data transfer<BR>
operation&quot; to &quot;A wait operation terminates (9.5.4) a pending =
data<BR>
transfer operation&quot;.<BR>
Rationale: Without careful reading of 9.6.1, this could be<BR>
interpreted to mean that the wait interrupts and stops a data<BR>
transfer operation.<BR>
<BR>
E12 Section 9.7.1<BR>
Page 206:0+<BR>
Change: &quot;ERR=3D20&quot; to &quot;IOSTAT=3DN&quot;<BR>
<BR>
E13 Section 9.8<BR>
Page 207:17+<BR>
Change in Note 9.59: &quot;ERR=3D20&quot; to &quot;IOSTAT=3DN&quot;<BR>
<BR>
E14 Section 9.8<BR>
Page 207:17+<BR>
Change in Note 9.58: &quot;left vague&quot; to &quot;not closely =
defined&quot;<BR>
<BR>
E15 Section 11.2<BR>
Page 246:6<BR>
Change &quot;not themselves&quot; to &quot;not necessarily =
themselves&quot;<BR>
<BR>
E16 Section 14<BR>
Page 355:20+. Add new note:<BR>
NOTE 14.1a The reason that IEEE_INVALID is not required always in<BR>
IEEE_EXCEPTIONS is to allow a non-IEEE processor to provide support<BR>
for overflow and divide_by_zero. On an IEEE machine, invalid is an<BR>
equally serious condition.<BR>
<BR>
E17 Section 14.2<BR>
Page 357:17<BR>
Change &quot;examples&quot; to &quot;possible examples&quot;<BR>
Rationale: Not all CPUs will flag over-large integer values as an =
error.<BR>
<BR>
E18 Section 14.3<BR>
Page 359:20+<BR>
Add at the end of the paragraph: &quot;The rounding mode may affect =
the<BR>
result of an intrinsic function.&quot;<BR>
<BR>
E19 Section 14.7<BR>
Page 360:18-19<BR>
Replace &quot;arithmetic operators&quot; by &quot;operators of =
addition, subtraction<BR>
and multiplication&quot;<BR>
Page 360: 23-25<BR>
Replace &quot;For each ... normalized&quot; by &quot;For each of the =
operators for<BR>
addition, subtraction and multiplication, the result shall be as<BR>
specified in the IEEE standard whenever the operands or arguments =
and<BR>
IEEE result are normalized (if a floating-point value) or valid and<BR>
within range (if some other type of value).<BR>
Rationale: Exponentiation is not an IEEE operation. Fortran division =
is<BR>
defined differently from IEEE division.<BR>
<BR>
E20 Section 14.7<BR>
Page 360: 28-29 and page 361:3.<BR>
Change 'is as specified in the IEEE standard' to 'shall be<BR>
consistent with the specifications in the IEEE standard'.<BR>
Rationale: The IEEE does not specify all the Fortran intrinsics.<BR>
<BR>
E21 Section 14.7<BR>
Page 361:3+<BR>
Add new paragraph: &quot;The inquiry function IEEE_SUPPORT_DENORMAL =
is<BR>
provided to inquire whether the processor supports IEEE denormals. =
Where<BR>
these are supported, their behavior for unary and binary =
operations,<BR>
including those defined by intrinsic functions and by functions in<BR>
intrinsic modules, is as specified in the IEEE standard.&quot;<BR>
Rationale: Provides description for IEEE_SUPPORT_DENORMAL and<BR>
regularizes situation compared to IEEE_SUPPORT_NAN and =
IEEE_SUPPORT_INF.<BR>
<BR>
E22 Annex E<BR>
Page 533<BR>
Asterisk is used for so many different purposes in addition to<BR>
multiplication, it is confusing to select only one of them for the<BR>
index. The entry should be removed or should be made comprehensive.<BR>
------------------------------end of UK =
comments-------------------------</FONT>
</P>
<BR>

</BODY>
</HTML>
------_=_NextPart_001_01C2B8B0.2F0189A0--