Subject: SC 22 N 3560 - Disposition of Comments Report for ISO/IEC CD 1539 -1, Fortran

From: Matthew Deane <[email-masked]>
Date: Mon, 7 Apr 2003 17:04:56 -0400

ISO/IEC JTC 1/SC22
Programming languages, their environments and system software interfaces
Secretariat:  U.S.A.  (ANSI)
 
ISO/IEC JTC 1/SC22 N3560
 
TITLE:
Disposition of Comments Report for ISO/IEC CD 1539-1, Fortran

DATE ASSIGNED:
2003-04-07
 
SOURCE:
SC 22/WG 5 Convenor (J. Reid)

BACKWARD POINTER:
 
DOCUMENT TYPE:
Disposition of Comments Report

PROJECT NUMBER:
22.02.01.01
 
STATUS:
Disposition of Comments report in response to document SC 22 N3535.   

ACTION IDENTIFIER:
FYI
 
DUE DATE:
  
DISTRIBUTION:
Text

CROSS REFERENCE:
N3535

DISTRIBUTION FORM:
Defined
 
Address reply to:
ISO/IEC JTC 1/SC22 Secretariat
Matt Deane
ANSI
25 West 43rd Street
New York, NY  10036
Telephone:  (212) 642-4992
Fax:             (212) 840-2298
Email:  [email-masked]

____end of cover page, beginning of document______

                                      ISO/IEC JTC1/SC22/WG5 N1520 

Disposition of comments on the Committee Draft of Fortran 2000 

		       John Reid

WG5 thanks the national bodies that provided comments with their 
ballots (N1506 and N1509) and the Australian national body for
providing an unofficial comment (N1499). WG5 responds as follows:

..................................................................

US

A. WG5 considered the following suggestions explicitly and accepted 
them except where indicated otherwise.

1.12 Add KIND parameter to IACHAR

1.14 Cater for the C types int8_t, int16_t, int32_t, int64_t, and
intptr_t

1.20 Rename NONKIND as EXTENT. Not accepted. WG5 preferred to rename 
this as LEN. 

1.21 Do not allow the parent component of a type to
be specified as private

2.1 and 2.7a Give any object of CLASS(T) a component named T that
represents its TYPE(T) subobject

2.2a Add optional MOLD argument to ALLOCATE to specify the dynamic
type in the polymorphic case

2.2b Make intrinsic assignment apply to the dynamic type. Not accepted.
The US delegation withdrew this request. 

2.3 Reinstate deferred bindings

2.5 Require the BIND attribute in the ENUM feature 

2.7b Disallow type mismatches when the dummy argument is declared
with TYPE rather than CLASS

2.8 Should the transformational intrinsics such as CSHIFT be
applicable to array of types with allocatable component? If so, exactly
what is meant?

2.9 Replace the constants IOSTAT_END and IOSTAT_EOR by intrinsic
functions

2.13 Add constants to specify the size in bits of the file storage
unit, numeric storage unit, and character storage unit

2.14 Decide whether a program can have an intrinsic and nonintrinsic
module of the same name

2.15 Allow BOZ constants to have a kind type parameter value. Not accepted.
WG5 did not consider that this is needed. 

B. WG5 passed the following suggested changes to the Primary 
Development Body (J3) for consideration since they were
editorial suggestions or very minor technical suggestions. 

All of section 1, except 1.12, 1.14, 1.20, and 1.21. Sections 2.4, 2.6,
2.10, 2.11, 2.12, 2.16.

..................................................................

UK

A. WG5 considered the following suggestions explicitly and accepted 
them except where indicated otherwise.

TC1 Provide more support for ISO 10646

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

TC3 Allow default initialization of parameter values of
derived types

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

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

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

TC7 Allow any non-SEQUENCE type to be extended.

TC8 Remove the TYPEALIAS facility

TC9 Remove the ENUM facility. Not accepted. WG5 considers that this
feature is important for interoperability with C.  

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

TC11  Allow reallocation of allocatable arrays

MTC1 Reword "NONKIND" as "LEN"

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

MTC7 Allow input/output of IEEE exceptional values

MTC9 Allow for IEEE extended format

MTC10 Add a facility for controlling IEEE underflow

MTC11 Have separate types for C data and procedure pointers

MTC12 Make TYPE(C_PTR) be an opaque derived type

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

MTC14 Add further requirement for C interoperability

MTC15 Specify that the PROCESSOR_DEPENDENT i/o rounding mode should 
    not depend on the rounding mode used for arithmetic.
    Not accepted. WG5 did not think that this change is needed.

B. WG5 passed the following suggested changes to the Primary 
Development Body (J3) for consideration since they were
editorial suggestions or very minor technical suggestions. 

Suggestions MTC2, MTC3, MTC4, MTC5, MTC8, E1-E22.

..................................................................

JAPAN

WG5 passed all the suggested changes to the Primary Development Body
(J3) for consideration since they were editorial suggestions or very
minor technical suggestions.

..................................................................

GERMANY

WG5 considered general comments 1. to 4. and suggestions a) to m) in the 
conclusion section.  The WG5 responses are:

1. The proposed Fortran language and document are TOO LARGE AND 
MUCH TOO COMPLEX for anyone to learn or read completely.

WG5 Response: Fortran 2000 was agreed to be a major revision of Fortran 95.
WG5 
has developed the proposals for Fortran 2000, described in WG5-N1259, which
were 
approved by its members at the meeting in February 1997.  It is true of many

modern programming languages that few individuals are familiar, or need to
be 
familiar, with all aspects of the language.

2. The standardization process has become seriously DISCONNECTED 
from the Fortran user community.

WG5 response: This statement is not accepted. Members of the standardization

committees who are employed by processor vendors are continually made aware
of 
user requirements.  Individual members of the standardization committees
make 
frequent, usually daily, contributions to the main user forums for
discussion of 
Fortran matters, viz comp.lang.fortran and comp-fortran-90, and major users
are 
represented directly on the standardization committees.

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.

WG5 response:  Similar assertions about the size of Fortran 90 were made
prior 
to its publication and have proved not to be true.  Development of Fortran
2000 
was guided largely by requirements expressed by users of the language.

4. The current revision does not focus on the PRIMARY INTERESTS 
and the most pressing needs of the Fortran community.

WG5 response:  As noted above, the content of Fortran 2000 was guided
largely by 
users' requirements.  Development of the language has been progressed as
quickly 
as possible, given the constraint of the volunteer resources available.

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

WG5 response: Some reduction has been made in response to the UK comments. 
Further, Section 4.5 (about 20 pages) has been reorganized because it made 
the OOP features seem more complicated than they actually are. 

b) Should we not have initializers?  

WG5 response: WG5 believes that structure constructors already provide
sufficient functionality. This request seems to contradict request a).

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? 

WG5 response: It was agreed in Tokyo in 1995 that features for
interoperability 
with C were required with sufficient urgency for the constuction of a
Technical 
Report with a firm commitment to include its features in the next standard
(see 
N1116, Resolution T9). While there have been difficulties in designing the 
features, the requirement has not been questioned within WG5 since. The
features 
are still needed by the Fortran user community.  Perhaps this is a request
for
simplification of the features, but there is no indication of how this might
be 
done.

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?  

WG5 response: No detailed edits are provided and the suggestion of a
completely 
different way of doing this does not fit with the goal of smooth upward 
compatibility with the existing features.

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?  

WG5 response: With the publication of TR 15580, WG5 committed itself to
the inclusion of these features in the next revision of the standard.

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).  

WG5 response: The language contains the features needed to write operators
such 
as .ADDUP. in a module. 

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.  

WG5 response: John Reid's proposal did not reach a sufficiently polished
state 
for inclusion and WG5 decided instead to follow the IEEE module route. This 
provides most of the necessary functionality and it is much easier to
understand 
exactly what happens. 

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.  

WG5 response: WG5 accepted the UK's technical comment TC10.

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.  

WG5 response: WG5 accepted all these proposals except for TC9. 

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 mimic 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!!  

WG5 response: The absence of proposed edits to implement this suggestion
make it 
impossible to judge the impact of this suggestion on the whole standard. 
However, it is clear that it will further increase the size of the revision
and 
the burden on implementers.   

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.  

WG5 response: WG5 is preparing a Technical Report that it hopes will be 
published at about the same time as the new standard.  This will allow
vendors 
to implement this feature ahead of the next standard with confidence that it

will be included. Furthermore, if the feature is specified in a Technical 
Report, it is more likely to be implemented as an extension to Fortran 95. 

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)?  

WG5 response: WG5 prefers having a new keyword with an obvious meaning to
reusing an old keyword (USE) with a new meaning (host association).

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:

WG5 response: WG5 decided to retain the use of square brackets for array
syntax 
since this is wanted now by the community. If the standard is ever extended
to 
support interval arithmetic, a suitable syntax for this will not be
difficult to 
design. 

..................................................................

AUSTRALIA

The comment from Australia was not official, but it was considered
nevertheless. 

The request to change the remarks on module processing in section C was
passed to the Primary Development Body (J3) for consideration since it
does not involve any normative text.

The request to change the USE default from public to private was not
accepted 
since it involves an incompatibility with Fortran 95 and there is already a 
facility (the PRIVATE statement) to change the default in a module to
private.