From owner-sc22docs@dkuug.dk Mon Apr 7 23:04:45 2003 Received: (from majordom@localhost) by dkuug.dk (8.12.8p1/8.9.2) id h37L4jnL013236 for sc22docs-domo; Mon, 7 Apr 2003 23:04:45 +0200 (CEST) (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.12.8p1/8.9.2) with ESMTP id h37L4Xnj013230 for ; Mon, 7 Apr 2003 23:04:34 +0200 (CEST) (envelope-from mdeane@ANSI.org) Received: by email1.ansi.org with Internet Mail Service (5.5.2653.19) id ; Mon, 7 Apr 2003 17:04:57 -0400 Message-ID: <2F81C8110D55D411882A0020356797B20413BE87@email1.ansi.org> From: Matthew Deane To: "'SC 22 Distribution List'" Subject: SC 22 N 3560 - Disposition of Comments Report for ISO/IEC CD 1539 -1, Fortran Date: Mon, 7 Apr 2003 17:04:56 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2FD49.57CB5AE0" 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_01C2FD49.57CB5AE0 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 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: mdeane@ansi.org ____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. ------_=_NextPart_001_01C2FD49.57CB5AE0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable SC 22 N 3560 - Disposition of Comments Report for ISO/IEC CD = 1539-1, Fortran

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:          &nb= sp;  (212) 840-2298
Email:  = mdeane@ansi.org


____end of cover page, beginning = of document______



           &= nbsp;           &= nbsp;           &= nbsp;  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:

..................................................................<= /FONT>

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.

..................................................................<= /FONT>

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.

..................................................................<= /FONT>

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.

..................................................................<= /FONT>

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 (=3D 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.



..................................................................<= /FONT>

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

------_=_NextPart_001_01C2FD49.57CB5AE0--