Dear Commentors,

Thank you for your public review comments on ISO/IEC CD 1539-1, Information technology - Programming languages - Fortran.,

Responses to comments ( 5, 7, 10, 11) from J3 members that are contained in J3 papers from meeting 163 are indicated by a link to the paper. These papers and others are available from http://www.j3-fortran.org.

All J3 reference papers are attached at the end of this document.

Please note, this is the J3's response to your comments.  Unless you notify us that your public review comment has been satisfied or withdrawn, it will remain in the records as an unresolved comment.

In accordance with ANSI requirements, we are advising you in this letter of the Appeals Processes, see attached.

Once again, thank you for your interest in the " ISO/IEC CD 1539-1, Information technology - Programming languages - Fortran."draft standard.

Sincerely,
  Dan Nagle
  J3

Chairman

 cc: Deborah Donovan, INCITS Secretariat

Appeals Processes

1) You may appeal an action of INCITS or its Secretariat, the INCITS Appeals Procedures are in Section 5.9 of the INCITS/SD-2.

2) Notification of Right to Appeal to the ANSI Board of Standards Review (http://web.ansi.org/public/library/std_proc/anspro.html)

Please note, in accordance with BSR Procedures, those objecting to the approvals or withdrawals are hereby notified of their right of appeal. The appeal must be based on due process or lack of consensus and include a statement as to why the BSR action should be modified.  The BSR will not render decisions on the relative merits of technical matters, but it shall consider whether due process was afforded technical concerns.

If you have not completed the appeals process at the standards developer, you are normally not
eligible to appeal to the BSR.

J3's Responses to Public Comments

Public Review Comment #1 - Received on October 9, 2002 from T. Plessel

J3 Response to point 1

J3 has chosen to allow more continuation lines instead. We feel that longer lines will not be readable by humans (including when listed in error messages). We recognize that preprocessors will need to be aware of the 132 character limit, but they would also need to be aware of any other limit and do some sort of special casing where the line is too long.

J3 Response to point 2

WG5 has chosen to standardize a more Fortran-like preprocessor as a separate standard.

J3 Response to point 3

Design by Contract was not part of the requirements for Fortran 2000 and is too large to add at this time. We will recommend that it be added to the list of features for consideration for the next revision of the Fortran standard.

J3 Response to point 4

These features are not present as specified. However, we have added a set of intrinsic subroutines that provide the same functionality as the argc/argv method. Please see section 13.5.17, command_argument_count, get_command, get_command_argument.

Adding an integer return value was not part of the requirements for Fortran 2000. We believe it is too system dependent for consideration at this time. We will recommend that it be added to the list of features for consideration for the next revision of the Fortran standard.

J3 Response to point 5

The get_command and get_command_argument intrinsic subroutines provide this capability.

J3 Response to point 6

This functionality was not part of the requirements for Fortran 2000. However, procedure pointers and C interoperability provide much of the functionality.

Public Review Comment #2 - Received on October 17, 2002 from A. Donev

J3 Response

J3 will more carefully consider the issue of when polymorphic variables need to be explicitly cast into non-polymorphic ones, and recommend how to clarify this in and improve the consistency of the Fortran 2000 Committee Draft if needed.

Public Review Comment #3 - Received on October 17, 2002 from A. Donev

J3 Response

J3 will more carefully consider the issues raised here and will recommend how to modify the Fortran 2000 Committee Draft if needed.

Public Review Comment #4 - Received on October 18, 2002 from A. Donev

J3 Response

J3 will recommend that deferred bindings be added to the Fortran 2000 Committee Draft, using the proposed specifications as a design guide.

Public Review Comment #5 - Received on October 22, 2002 from A. Donev

J3 Response

Your idea raises interesting possibilities that require further careful consideration. We will recommend that it be added to the list of features for consideration for the next revision of the Fortran standard.

Corrected Public Review Comment #6 - Received on November 1, 2002 from J. Vezina

J3 Response to point 1

We agree and we will recommend this change in the Fortran 2000 Committee Draft.

J3 Response to point 2

Thank you for this idea. This feature was on the proposed list of features for Fortran 2000, but it did not receive enough support to make it into this revision of the Fortran standard. We will recommend that it be added to the list of features for consideration for the next revision of the Fortran standard.

J3 Response to point 3

Thank you for this idea. This feature was on the list of features for Fortran 2000, but it did not receive enough support in order to make it into this revision of the Fortran standard. We will recommend that it be added to the list of features for consideration for the next revision of the Fortran standard.

J3 Response to point 4

Your idea raises several interesting related possibilities. We will recommend that it be added to the list of features for consideration for the next revision of the Fortran standard.

J3 Response to point 5

We will recommend that these features be added to the list of features for consideration for the next revision of the Fortran standard.

Public Review Comment #7 - Received on October 24, 2002 from A. Donev

J3 Response

The proposed functionality was not in the list of requirements for this revision of the Fortran standard. J3 will recommend that it be added to the list for consideration for the next revision of the Fortran standard.

Public Review Comment #8 - Received on October 25, 2002 from R. James

J3 Response to point 1

Please see J3 paper 02-330r2 from meeting 163 for the detailed response.

J3 Response to point 2

Please see J3 paper 02-303r2 from meeting 163 for the detailed response.

J3 Response to point 3

Please see J3 paper 02-304r1 from meeting 163 for the detailed response.

J3 Response to point 4

Please see J3 paper 02-305r1 from meeting 163 for the detailed response.

J3 Response to point 5

Please see J3 paper 02-306r1 from meeting 163 for the detailed response.

J3 Response to point 6

Please see J3 paper 02-307r1 from meeting 163 for the detailed response.

J3 Response to point 7

J3 will recommend that intrinsic functions IOSTAT_END and IOSTAT_EOR be added to the Fortran 2000 Committee Draft. These intrinsic functions replace the named constants in the current draft and return .TRUE. if the actual argument satisfies the condition.

J3 Response to point 8

J3 will recommend that this edit be made.

J3 will recommend that this issue be fixed in the Fortran 2000 Committee Draft.

J3 Response to point 9

Please see J3 paper 02-308r1 from meeting 163 for the detailed response.

J3 Response to point 10

Please see J3 paper 02-296r3 from meeting 163 for the detailed response.

Public Review Comment #9 - Received on October 31, 2002 from A. Markus

J3 Response to point 1

J3 feels this is too system dependent to be standardized. Many processors provide for dealing with this as a command line or OPEN option. Fortran has resisted standardizing details of implementation at this level.

J3 Response to point 2

J3 will recommend that constants be defined by the Fortran 2000 Committee Draft that specify the size in bits of the file storage unit, the numeric storage unit, and the character storage unit.

J3 Response to point 3

J3 will not recommend this feature since it is difficult to standardize. Some systems do not have a directory concept, nor is it guaranteed that if they do, the separator will be a single character.

J3 Response to point 4

J3 will not recommend this feature since it isn't generally possible. Some IOMSG strings are composed by the processor on the fly, perhaps containing the format, the line in error, or the file name. Also, user defined IO routines can return an IOMSG string of arbitrary length.

J3 Response to point 5

Any unit may be specified for the FLUSH statement. The results are system dependent, but means are provided to detect "inappropriate" but "harmless" use of a FLUSH.

J3 Response to point 6

The IEEE modules provide for run-time control of rounding. See section 14.3

J3 Response to point 7

This is outside the scope of the Fortran standard; but J3 does not believe we have done anything that would preclude existing practice in this area. The new C interoperability features should remove (most of) the need for system dependent coding.

Public Review Comment #10 - Received on November 1, 2002 from R. Maine

J3 Response

Please see J3 paper 02-321r2 from meeting 163 for the detailed response.

Public Review Comment #11 - Received on November 8, 2002 from K. Hirchert

J3 Response

Please see J3 paper 02-314r1 from meeting 163 for the detailed response.

Public Review Comment #12 - Received on November 12, 2002 from W. Walster

J3 Response

J3 is aware of the conflict with this syntax. Historically, some processors have used square brackets for other purposes, such as array constructors or co-arrays. J3 and WG5 have carefully considered this issue. J3 and WG5 prefer the use of square brackets for array constructors in preference to competing vendor extensions.

Public Review Comment #13 - Received on November 12, 2002 from W. Hayes

J3 Response

J3 is aware of the conflict with this syntax. Historically, some processors have used square brackets for other purposes, such as array constructors or co-arrays. J3 and WG5 have carefully considered this issue. J3 and WG5 prefer the use of square brackets for array constructors in preference to competing vendor extensions.

Public Review Comment #14 - Received on November 13, 2002 from D. Bogle

J3 Response

J3 is aware of the conflict with this syntax. Historically, some processors have used square brackets for other purposes, such as array constructors or co-arrays. J3 and WG5 have carefully considered this issue. J3 and WG5 prefer the use of square brackets for array constructors in preference to competing vendor extensions.

Public Review Comment #15 - Received on November 4, 2002 from R. Moore

J3 Response

J3 is aware of the conflict with this syntax. Historically, some processors have used square brackets for other purposes, such as array constructors or co-arrays. J3 and WG5 have carefully considered this issue. J3 and WG5 prefer the use of square brackets for array constructors in preference to competing vendor extensions.

Public Review Comment #16 - Received on November 15, 2002 from A. Neumaier

J3 Response

J3 is aware of the conflict with this syntax. Historically, some processors have used square brackets for other purposes, such as array constructors or co-arrays. J3 and WG5 have carefully considered this issue. J3 and WG5 prefer the use of square brackets for array constructors in preference to competing vendor extensions.

Public Review Comment #17 - Received on November 15, 2002 from J. v. Gudenberg

J3 Response

J3 is aware of the conflict with this syntax. Historically, some processors have used square brackets for other purposes, such as array constructors or co-arrays. J3 and WG5 have carefully considered this issue. J3 and WG5 prefer the use of square brackets for array constructors in preference to competing vendor extensions.

Public Review Comment #18 - Received on November 18, 2002 from W. Walter

J3 Response

J3 is aware of the conflict with this syntax. Historically, some processors have used square brackets for other purposes, such as array constructors or co-arrays. J3 and WG5 have carefully considered this issue. J3 and WG5 prefer the use of square brackets for array constructors in preference to competing vendor extensions.

Public Review Comment #19 - Received on November 18, 2002 from K. Bierman

J3 Response to point 1

J3 is aware of the conflict with this syntax. Historically, some processors have used square brackets for other purposes, such as array constructors or co-arrays. J3 and WG5 have carefully considered this issue. J3 and WG5 prefer the use of square brackets for array constructors in preference to competing vendor extensions.

J3 Response to point 2

Thank you for your comment. Part 2 and Part 3 of the Fortran standard are not the subject of this public review. Therefore, J3 will not make recommendations regarding them.

J3 Response to point 3

The Object Oriented Programming features of Fortran proposed by the Fortran 2000 Committee Draft are specific requirements and have strong and enduring support. J3 will not recommend a change.

Public Review Comment #20 - Received on November 18, 2002 from R. Corbett

J3 Response to point 1

J3 agrees that there is a problem in this area and will recommend that it be repaired.

J3 Response to point 2

J3 does not agree that there is a problem.

J3 Response to point 3

J3 does not agree that there is a problem.

J3 Response to point 4

J3 does not agree that there is a problem with the description of the use of BOZ literal constants as arguments to the CMPLX, DBLE and REAL intrinsic functions, but investigation of your comment reveals that there is a problem with DATA: The constant ought to be interpreted to have the same kind as the corresponding variable. J3 will recommend that this be repaired.

J3 Response to point 5

J3 does not agree that there is a problem. This was addressed by Fortran 90 Interpretation 12.

J3 Response to point 6

J3 does not agree that there is a problem.

J3 Response to point 7

J3 does not agree that there is a problem.

J3 Response to point 8

J3 believes the feature should stay as it is defined.

J3 Response to point 9

J3 does not agree that there is a problem.

J3 Response to point 10

J3 does not agree that there is a problem.

J3 Response to point 11

J3 agrees that there is a problem here. J3 will recommend the following edits: At 253:20 replace "a subroutine or a function" by "an external subroutine or an external function". At 250:21, after "it" insert "; the interface of an external function that does not have a separate result name is implicit within the subprogram that defines it".

J3 Response to point 12

The proposed functionality was not in the list of requirements for this revision of the Fortran standard. This is being addressed by Type II Technical Report 19767, entitled "Enhanced Module Facilities in Fortran."

J3 Response to point 13

J3 does not agree that there is a problem.

J3 Response to point 14

J3 will recommend that this be corrected.

J3 Response to point 15

J3 does not agree that there is a problem.

Public Review Comment #21 - Received on November 22, 2002 from D. Nagle

J3 Response

The proposed functionality was not in the list of requirements for this revision of the Fortran standard. J3 will recommend that these features be added to the list of proposed requirements for the next revision of the standard.

End of J3's Responses to Public Comments

Reference Documents
 

J3/02-296r3

Date:     15 November 2002
To:       J3
From:     Aleksandar Donev
Subject:  Reinstating Deferred Bindings
Reference: J3-007R3, J3/02-271r1

______________________________________
Summary
______________________________________
I propose to do the work necessary to bring back deferred bindings into F2x, and the specific syntax arrived at during a discussion with Kurt and Van.
______________________________________
J3 response:
______________________________________
J3 will recommend that deferred bindings be added to the draft standard, using the proposed specifications as a design guide.

______________________________________
Motivation
______________________________________
We want three useful debugging/diagnostic tools for deferred bindings:
1. They must be part of the syntax so that from the declaration of an extensible type it is clear that a particular type-bound procedure is deferred.
2. They must provide compile-time checks when extending the type, forcing the user to do something with the deferred procedure (either defer it again or override)
3. They should provide a runtime debugging protection/traceback if the deferred procedure is envoked.
______________________________________
Solution
______________________________________
We allow the following two forms of deferred binding:
a)
PROCEDURE, DEFERRED :: proc=>my_error_handler
The deferred attribute here means that upon extension another deferral or explicit override is required. This is a compile time check to the programmer.
b)
PROCEDURE, DEFERRED :: proc=>abstract_interface
In this case the compiler will automatically provide a *real* procedure with the specified interface which will do some kind of error-handling, and we say that invocation of this procedure will terminate execution (like invalid IO statements). This is a runtime aid to the programmer.

With this scheme deferred type-bound procedures are treated exactly like regular type-bound procedures, so the standard is simpler and there is no runtime segfaults. The same syntax applies to type-bound generics. There some of the specifics can be explicitly provided by the user, and others can be default debugging ones provided by the compiler.
______________________________________
Edits
______________________________________
Question:
1. How do we ensure that all DEFERRED bindings are overriden at compile time? The old text does not seem to have a numbered constraint for this.

44: 20-21 Replace:
If =><binding> does not appear and the binding does not override an inherited deferred binding,

45: 3+ Add:
or DEFERRED

45: 18+ Add:
or <deferred-procedure-name>

<deferred-procedure-name> is <name>

45: 10+ Add:
(Cxxx) If DEFERRED appears, either =><binding> shall appear, or the binding shall override an inherited binding.
       DEFERRED and NON_OVERRIDABLE shall not both appear in the same <binding-attr-list>.

20+: Add:
(Cxxx) The <deferred-procedure-name> shall be the name of an abstract interface.
(Cxxx) The <deferred-procedure-name> shall appear only if a DEFERRED binding attribute appears and the binding does not override an inherited binding.

49: 4 Add to the end of the sentence:
or <deferred-procedure-name>.

49:5+ Add:
A binding that specifies the DEFERRED attribute is said to be deferred. If a deferred type-bound procedure is invoked execution is terminated.

[CONSTRAINT?] If a type has a deferred binding then any extension of the type shall override (4.5.3.2) this inherited deferred binding. This new binding may confirm that the binding is still deferred. It is permissible to override an inherited binding with a deferred binding.

NOTE

A deferred binding may be to a procedure or to an abstract interface. Deferred bindings are useful for type-bound procedures that do not have an actual implementation (as in Abstract Programming Interfaces). The user may provide a specific procedure in the binding that may give some useful run-time indication of the deferred character of the binding. But this deferred binding must still be explicitly overriden upon extension of the given type, which is a useful compile time reminder. The user may also just provide an abstract interface for the binding, in which case the processor may supply an error-handling procedure for the binding. This procedure terminates execution, but may also provide useful debugging diagnostics to the user.

56: 1- Add:
If a binding is deferred and does not specify an abstract interface then it inherits the interface from the binding in the parent type.

02-303r2

Date:     November 13, 2002
To:       J3
From:     Rob James
Subject:  The POS= specifier in a data transfer statement

Introduction
------------
In 9.5.1.10, it is said (at page 190, lines 14-15 of the Committee
Draft) that the POS= specifier "may appear only in an input/output
statement that specifies a unit connected for stream access".
This is not quite true.

It's correct that the POS= specifier may appear in a data transfer
statement that specifies a unit connected for stream access, and
that it may not appear in any other data transfer statement.
However, it may also appear in an INQUIRE statement, whether or
not that INQUIRE statement specifies a unit connected for stream
access.
 

Proposed Edits
--------------
Page and line numbers refer to the Committee Draft.

[190:14-15]  Replace the sentence "This specifier may ... access."
  with the following sentence:
    This specifier may appear in a data transfer statement only if
    the statement specifies a unit connected for stream access.

J3/02-304r1

Date:     November 13, 2002
To:       J3
From:     Rob James
Subject:  Allocatable result variables and ENTRY

Introduction
------------
The following code seems to be allowed when it probably shouldn't
be:

FUNCTION foo()
  INTEGER, ALLOCATABLE :: foo
  INTEGER :: bar
  ...
ENTRY bar()
  ...
END FUNCTION

Page 279, lines 18-22 of the Committee Draft state:

    If the characteristics of the result of the function named in
    the ENTRY statement are the same as the characteristics of the
    result of the function named in the FUNCTION statement, their
    result variables identify the same variable, although their
    names need not be the same.  Otherwise, they are storage
    associated and shall be scalars without the POINTER attribute
    and one of the types:  default integer, default real, double
    precision real, default complex, or default logical.

The code above fits into the "otherwise" situation.  So, they
must be scalars (yes, they are) without the POINTER attribute (no
POINTER attribute here), and one of the types mentioned (default
integer is in the list).  Both foo and bar fit those criteria and
are storage associated.  But, for foo, what storage are we talking
about?  Certainly not the dope vector.  Does it mean that the
storage allocated for foo needs to be the same as the storage for
bar?  Does it mean that they can be separate, but need to be kept
synchronized with each other (i.e. the same value at all times)?

All of these suggestions are terrible.  And besides, wasn't this
the reason behind prohibiting the POINTER attribute in this
situation?  The only acceptable solution is to prevent these
function results from having the ALLOCATABLE attribute as well as
the POINTER attribute.
 

Proposed Edits
--------------
Page and line numbers refer to the Committee Draft.

[279:20-22]  The sentence beginning with "Otherwise" doesn't parse
  well as it is, and simply adding "or ALLOCATABLE" would make the
  problem worse.  So, I propose changing this sentence to the
  following:
    Otherwise, they are storage associated and shall all be
    nonpointer, nonallocatable scalars of type default integer,
    default real, double precision real, default complex, or
    default logical.

J3/02-305r1

Date:     November 14, 2002
To:       J3
From:     Rob James
Subject:  Function prefixes and specification inquiries

Introduction
------------
The following code looks like it's allowed, according to the
Committee Draft:

type(dt(1)) function f()
  integer, parameter :: i = f%x
  type :: dt(x)
    integer, kind :: x
    ...
  end type
  ...
end function

The initializer for i (f%x) appears to be a perfectly fine
specification expression, at least according to 7.1.7
(Initialization expression).  However, the type and type
parameters of f haven't even been defined yet.  Sure, they're
specified previously, in the function statement, and that's all
that seems to be required.

In Fortran 95, there didn't need to be a requirement that the
type of a variable needed to be defined.  The only types that had
type parameters were intrinsic types, and therefore always
defined.  With the arrival of derived type parameters in Fortran
200x, however, the type of an object whose type parameter is being
inquired about could be defined later, if the type and type
parameters of the object are specified on a function statement.

The same problem gets some nastier symptoms if you use a type
alias, rather than a parameterized derived type.  Consider the
following code fragment, which again looks legal according to the
Committee Draft:

type(ta) function f()
  integer, parameter :: i = f%kind
  typealias :: ta => integer(i)
  ...
end function

From a legal type parameter inquiry, we get a nasty little
circular definition.

1. The type and type parameters of f are those aliased by the type
   alias ta.
2. The type aliased by ta is integer with kind type parameter
   value equal to the value of i.
3. The value of i is the kind type parameter of f.
4. Go to 1.

This problem can be fixed in one of three ways:

1. Fix the description of specification inquiries to prohibit
   these situations.
2. Fix the description of type parameter inquiries to prohibit
   these situations.
3. Fix 5.1.1.7 to say that, if a derived type is specified on a
   function statement and the derived type is defined within the
   body of the function, the effect is the same as if the result
   variable was specified with that derived type in a type
   declaration statement appearing immediately after the derived
   type definition.  Something analogous would also need to be
   added for type aliases.

Personally, I prefer option 3, as it seems a bit cleaner and it
specifies something that Fortran 95 did not: the exact effect of
specifying a derived type in a function prefix when that derived
type is defined inside the body of the function.
 

Proposed Edits
--------------
Page and line numbers refer to the Committee Draft.

The following edit implements fix #3 described above.  It also
incorporates type aliases into the section about the TYPE type
specifier, and changes the headings of 5.1.1.7 and 5.1.1.8 to
"TYPE" and "CLASS" respectively, since 5.1.1 is titled "Type
specifiers", and these are the corresponding type specifiers
for derived types, type aliases, and polymorphic entities.

[73:16-26] Remove these lines, replacing them with the following:
<<5.1.1.7  TYPE>>

A TYPE type specifier may be used to declare entities of a derived
type or a type that is aliased by a type alias.

If the <derived-type-spec> contains a <type-name>, then the TYPE
type specifier is used to declare entities of the derived type
specified by that <type-name>.  Derived type parameter values for
each such entity may be specified by a <type-param-spec-list> in
the <derived-type-spec>.  The components of each such entity are
declared to be of the types specified by the corresponding
<component-def-stmt>s of the <derived-type-def> (4.5.1).

If the <derived-type-spec> is a <type-alias-name>, then the TYPE
type specifier is used to declare entities of the type and type
parameters aliased by the type alias specified.  It is as if the
<declaration-type-spec> for which the <type-alias-name> is an
alias was used instead.

When a data entity is declared explicitly using the TYPE type
specifier, the specified derived type or type alias shall have
been defined previously in the scoping unit or be accessible
there by use or host association.  If the data entity is a
function result, the derived type or type alias may be specified
in the FUNCTION statement provided the derived type or type alias
is defined within the body of the function or is accessible there
by use or host association.  If the derived type or type alias is
specified in the FUNCTION statement and is defined within the
body of the function, it is as if the function result variable
was declared with that derived type or type alias immediately
following the <derived-type-def> of the specified derived type or
the <type-alias-stmt> that defines the specified
<type-alias-name>.

A scalar entity of derived type is a <<structure>>. If a derived
type has the SEQUENCE property, a scalar entity of the type is a
<<sequence structure>>.

<<5.1.1.8  CLASS>>

J3 Response:  J3 will recommend that this change be made to the
Committee Draft.

J3/02-306r1

Date:     November 14, 2002
To:       J3
From:     Rob James
Subject:  Problems with Type Aliases

Introduction
------------
Type alias names and derived type names should behave essentially
the same in most situations.  They are both just names of types.
They are both used in the same way to declare objects.  They
should abide by the same rules, as far as declaring an entity
goes.  Right now, they don't.
 

Type Alias Problem #1:
----------------------
Type aliases may not be extended.  Don't say otherwise.

Note 4.45 (page 54, after line 5 in the Committee Draft) says that
the name of a parent type might be a type alias name.  This was
true in a previous draft, but not in the Committee Draft.  The
words "a <type-alias> name or" should be removed from this note.
 

Type Alias Problem #2:
----------------------
It's not clear, except from an example in a note, that a
<declaration-type-spec> in a TYPEALIAS statement can specify a
type alias.

Sure, I suppose that if a <declaration-type-spec> in a TYPEALIAS
statement specifies a type alias, it is really specifying the
type and type parameters being aliased by that type alias.  After
all, it does say below that declaration of an entity using a type
alias name has that effect (page 61, lines 12-13 of the Committee
Draft).  But it would really make things more clear if type alias
names were explicitly allowed in this case.

I suggest that constraint C480 (page 61, lines 10-11 of the
Committee Draft) be changed to the following:

    (R453) A <declaration-type-spec> shall specify an intrinsic
    type, a previously defined derived type, or a previously
    defined type alias.

This also covers situations like the following:

TYPE :: dt
  ...
END TYPE
TYPEALIAS :: ta => TYPE(ta2)
TYPEALIAS :: ta2 => TYPE(dt)

Without this change to the constraint, there is nothing
prohibiting the user from specifying a type alias that is defined
later in that scoping unit (there is such a rule for derived
types).
 

Type Alias Problem #3
---------------------
If a derived type is specified in a function prefix, it can be
defined inside the function.  Can the same be done with type
aliases?

I would think the same could be done with type aliases.  The
syntax looks the same for derived types and type aliases on a
function prefix.  One would think that if you specify TYPE(NAME)
in a function prefix, then NAME could be legally defined inside
the function, whether it's a derived type or a type alias.

As it stands, there is nothing that says this is allowed for
type aliases.  I suggest that 5.1.1.7 be renamed to "TYPE" rather
than "Derived type".  5.1.1 is called "Type specifiers".  "TYPE"
is the type specifier for derived types and type aliases.  (In a
similar vein, 5.1.1.8 should be renamed to "CLASS", because it
talks about the CLASS type specifier.)  If this is done, something
about type aliases could easily be added into 5.1.1.7 (such text
doesn't already exist in this chapter).  The part about derived
types that are specified on FUNCTION statements could be expanded
to include type aliases.
 

Proposed Edits
--------------
Page and line numbers refer to the Committee Draft.

To fix problem #1:
[54:5+]  In the first line of Note 4.45, remove
         "a <type-alias> name or".

To fix problem #2:
[61:10]  Replace "or" with ",".
[61:11]  After "type" (before the period), add
         ", or a previously defined type alias".

To fix problem #3:
No edits.  This is covered in another paper ("Function prefixes
and specification inquiries").
 

J3 Response:  J3 will recommend that these changes be made to the
Committee Draft.

J3/02-307r1

Date:     November 13, 2002
To:       J3
From:     Rob James
Subject:  Additional constants for the ISO_C_BINDING module

Introduction
------------
The C_INT_LEAST*_T, C_INT_FAST*_T, and C_INTMAX_T constants that
are provided in the ISO_C_BINDING module are important, but there
are other C99 integral types provided by stdint.h that are not
accounted for in this module.

The types int8_t, int16_t, int32_t, and int64_t will probably be
more widely used than their "least" and "fast" counterparts,
because they provide exactly the number of bits requested.
Admittedly, these types need not exist in a given C99
implementation, but they are still very useful and desirable.

There is also one other signed integer type provided in stdint.h:
intptr_t.  This type, like the int*_t types, does not need to
exist in a C99 implementation.  It could be useful to provide a
constant in the ISO_C_BINDING module that corresponds to this
type as well.  Aside from being useful, it would make this
module more complete, in that the module would provide constants
corresponding to all of the signed integral types provided by
C99's stdint.h.

The values of these additional constants could be -2 if the C
companion processor does not define the types corresponding to
these constants (as opposed to -1, which would mean that the type
is defined by the companion C processor, but there is no
corresponding Fortran integer kind).
 

Proposed Edits
--------------
Page and line numbers refer to the Committee Draft.

[381:20]  After "C_SIZE_T," insert "C_INT8_T, C_INT16_T,
  C_INT32_T, C_INT64_T,".
[381:22]  Remove "and".
[381:22]  After "C_INTMAX_T", insert ", and C_INTPTR_T".
[381:23]  After "-1", insert "if the companion C processor
  defines the corresponding C type and there is no
  interoperating Fortran processor kind or -2 if the
  C processor does not define the corresponding C type".

[385:17+] Add the following rows to Table 15.2 below the row
  for C_SIZE_T:
  (Column 1)   (Column 2)   (Column 3)
  INTEGER      C_INT8_T     int8_t
  INTEGER      C_INT16_T    int16_t
  INTEGER      C_INT32_T    int32_t
  INTEGER      C_INT64_T    int64_t

[385:17+] Add the following row to Table 15.2 below the row
  for C_INTMAX_T:
  (Column 1)   (Column 2)   (Column 3)
  INTEGER      C_INTPTR_T   intptr_t

J3/02-308r1

Date:     November 13, 2002
To:       J3
From:     Rob James
Subject:  Specifying "private" in an extends clause

Introduction
------------
If a parent component is specified as private in an extends
clause, what is the effect?  This is never explained in the
normative text of the Committee Draft.

Given the example in C.1.3, it appears that the parent component
and all components inheritance associated with it are private in
the resulting type.  This is never said anywhere in the normative
text.

Even if this is fixed, there is the problem of type bound
procedures.  Are these all private in the resulting type unless
they are overridden and declared to be public?  If this is the
case, and if a type bound procedure that was declared as public in
the parent type is not overridden and declared to be public in the
child type, then this makes the type bound procedure private in
the child type, which is exactly what page 55, line 18 was trying
to prevent ("If the inherited binding is PUBLIC then the
overriding binding shall not be PRIVATE.").

In light of the fact that this feature is very poorly explained,
maybe it would be best to remove it from this revision of Fortran.
 

Proposed Edits
--------------
Page and line numbers refer to the Committee Draft.

[42:1]   Remove "[<access-spec> ::]" from the syntax rule.
[408:9]  Remove "the parent component or".
[433:8]  Remove "public ::" from the extends clause.
[433:14-17] Remove these lines.
[433:23] Remove this line.
[433:33] Replace "," with ")".
[433:33] Remove "&".
[433:34-36] Remove these lines.

02-310r1

    Technical Changes

To:         J3
From:       Craig Dedo
Date:       November 13, 2002
Subject:    Technical Changes

Date:     28 Oct 2002
To:       J3
From:     Richard Maine
Subject:  Technical changes

The following are proposed public comments relating to technical issues.

1. I believe it to be a mistake to introduce the concept of
   iostat values corresponding to "harmless conditions"
   in the FLUSH statement.  This seems inconsistent with all
   the other IO statements.  For example, rewinding or
   backspacing a file that is already at the initial position
   might be considered a "harmless condition".  Why does it
   have no effect to flush a file that does not exist, but
   causes a "harmless condition" to flush a file that is not
   appropriate for some other reason?  This requirement is also
   arguably contradicted by the first sentence of 9.11.

   Further the normative text describing this condition uses the
   adjective "processor-dependent" so much as to make it
   pointless and ill-defined.  The "such as" does not constitute
   a useful definition, and the bit about inappropriate units is
   in a note, so all we really have is the statement that
   processor-defined negative values indicate processor-defined
   conditions.

   I think this whole concept is a poorly integrated last-minute
   addition that stands out as anomalous.  It is not necessary
   for or unique to the functionality of the FLUSH statement.

J3 recommends the following edits:
[207:11-12] Delete the words starting with "or" and replace with, "or a
processor-dependent negative value if the flush operation is not supported
for the unit specified".

[207:12+]       Delete Note 9.57.

2. I believe the COMPATIBLE rounding mode to be a mistake (and
   to be strangely named).  The only difference between
   COMPATIBLE and NEAREST relies on an exact equality test
   for a floating point value.  Furthermore, this exact equality
   test will often be a test for exact equality to a number that
   cannot be represented exactly (what binary floating-point
   number is exactly halfway between the decimal numbers
   0.1 and 0.2?).  This is the kind of test that programmers
   are incessantly warned against by textbooks and even by some
   compilers.

   It is also manifestly unclear what it is that this mode is
   supposed to be compatible with.  It would seem just as
   meaningful to name the mode RALPH.

J3 Response: J3 believes the feature should stay as it is defined.

References
02-007r3, Fortran 2000 Committee Draft

[End of J3 / 02-310r1]

Subject: Responses to Public Comment #11 (Hirchert)   J3/02-314r1
From: Kurt W. Hirchert                  (Meeting 163) 14 Nov 2002

=========
Responses
=========

1.  J3 will propose changes to WG5 to address this editorial problem.

2.  The omission was unintentional.  J3 will propose to WG5 that such
    a cross reference be included.

3.  J3 believes that this is too large a change to make at this point
    solely to improve readability.  However, it will keep this
    suggestion in mind should this text need to be changed for
    technical reasons.

4.  J3 agrees that there is a problem here and will recommend to WG5
    that it be fixed.  However, that fix may differ from the one
    you propose.

5.  In view of the relative magnitudes of the possible benefit of
    your suggestion and its potential to delay the availability of
    this revision, J3 believes it should not be pursued at this
    time.  It might be pursued in the context of a future revision.

    [This response should also be used for items 9, 12-15, 17-19,
    21-22, and 25-28.]

6.  J3 does not believe that there is a problem with the current
    semantics of IMPORT and is recommending no change in this area.

7.  J3 will recommend that this change be made.

    [This response should also be used for item 11.]

8.  J3 is recommending that NONKIND be changed to EXTENT.

10. J3 feels that the name C_F_POINTER is consistent with the
    naming conventions generally used in the C interoperability
    facility and is recommending no change in this regard.

16. J3 is not recommending the addition of SIZEOF at this time.

20. J3 is preparing recommendations for a reinstatement of deferred
    procedure bindings consistent with your expressed concerns.

23. J3 does not believe that connecting functions to the structure
    constructor syntax offers a significant benefit over the direct
    use of functions to construct derived-type values and is
    recommending no change in this area.

24. J3 does not believe it would be appropriate to significantly
    change the approach to C interoperability used in the draft.
 

===============
Edits and Notes
===============

1.  382:17, 383:11, 384:1  Change these lines to (level 4) section
    headers.

2.  {* Just make sure this gets on the list of things to do. *}

4.  {* Edits will have to developed (by Kurt) between meetings.
    He will circulate drafts of them as soon as possible after
    this meeting. *}

7.  275:12-14  Change to
R1224 <function-stmt> is [<prefix>] FUNCTION <function-name> &
                         & ([<dummy-arg-name-list>]) [<suffix>]

    275:38+  Insert
R1228a <suffix> is <proc-language-binding-spec> [RESULT(<result-name>)]
                or RESULT(<result-name>) [<proc-language-binding-spec>]
{* For only two items, the above approach to the BNF seems simplest.
If there were more, I would suggest the approach used for <prefix>. *}

    277:8-9  Change to
R1231 <subroutine-stmt> is <prefix> SUBROUTINE <subroutine-name> &
              & [([<dummy-arg-list>])[<proc-language-binding-spec>]]

    278:31-35  Change to
R1234 <entry-stmt> is ENTRY <entry-name> [([<dummy-arg-list>])[<suffix>]]
{* Yes, this really replaces _both_ of the existing alternatives. *}

11. 188:8+  Insert
C929a (R914) If <default-char-expr> is an initialization expression
      (7.1.7), the leading part of its value shall be a valid
      format specification (10.1.1).
{* Compare this to the dynamic requirement in 10.1.2. *}

20. {* This is the work Aleksandar is doing. *}

                              - end -

 J3/02-321r2

Date:     15 Nov 2002
To:       J3
From:     Richard Maine
Subject:  Response to public comment #10 from Richard Maine

TYPOGRAPHICAL ERRORS

We will recommend that these errors be fixed in f2k.
(All except the last are also in 02-309).

WORDING PROBLEMS

We have considered the following issues and decided to take
no action on them for the reasons specified.

  W1.  The two contexts are sufficiently different to minimize
    confusion.  Also, there are existing implementations.

  W2.  This wording was used in f95.

  W4.  This wording was used in f95 and is not sufficiently
     confusing to merit the work to change it.

  W10. The duplication is helpful here.

  W16. No better words have been suggested.

  W24. This problem from a previous draft and was fixed in the CD.

We will recommend that the following issues be fixed,
with edits to be determined.

  W8, W9

We will recommend the following edits to fix the indicated comments.

  W3. [33:12] "Variables may be objects or subobjects." ->
        "A variable is a data object."

      [114:25] Delete "or subobject".

  W5. [126:Note 7.9] "activation record" ->
      "instance of a procedure".

  W6. [102:15] "first" -> "value of the first"
      [105:15] "second" -> "value of the second"
      [105:17] "values of the starting and ending point expressions"
             -> "starting and ending points"

  W7. [398:36-38] and [399:3-4] Move "as an argument keyword" to the
      beginning of its sentence, add a comma after it, and adjust
      capitalization.  "As an argument keyword, it" -> "It".  (twice)

  W11. [16:32-33] Delete sentence "In contexts...of the structure."

  W12. [19:5] and [418:26] Change "and" to "or" (twice).

  W13. [19:23,24] change "may be" to "is" (twice).

  W14. Unbold "components" on [41:7].  Move the bold on [59:19]
       to the second instance of "finalized".

  W15. [114:9,10] "an allocated" -> "any allocated" (twice).

  W17. [398:Note 16.6]  "may be found" -> "is".

  W18. [211:30-31] Delete sentence "The value...specified unit."

  W19. [287:10] "unallocated" -> "unallocated allocatables".

  W20. [194:25] "ID= specifier" -> "identifier (9.5.1.8)".

  W21. [230:26] "rounded" -> "rounding mode"

  W22. [231:1] Move ", w-n shall be positive" to after the following
       table, changing the comma to "The value of" and appending
       a period.

  W23. [237:2] After ";" insert "in this case".

  W25. [443:12] "can be used only" -> "may only be used".

  W26. [43:Note 4.18] "a bound for an <explicit-shape-spec> or a
       <type-param-value>" -> "a <type-param-value> or a bound in
       an <explicit-shape-spec>".

  W27. [249:1] Delete "explicitly".

  Another edit.  On the last 2 lines of [xiii], delete
     ", and access ... conditions)".

TECHNICAL ISSUES

The replies to T1 and T2 are in 02-310R1.

We have considered the following issues and decided to take
no action on them for the reasons specified.

  T3, T4.  These were mentioned in F90 and F95.  It would
    be confusing to remove them now.

  T7. This usage is consistent with that of some existing
    implementations.

  T17. Other papers propose to delete these constants
    instead.

  T19. The role of ABSTRACT here is similar to that of
    prefixes in function and subroutine statements.

  T23. The final procedures necessary to support INTENT(OUT)
    might not be available for the DTIO case.

We will recommend that the following issues be fixed,
with edits to be determined.

  T5, T6, T8 (see 02-313r2)

We will recommend the following edits to address the
specified issues.

  T9. [78:35] Insert "abstract" before "interface"

  T10. [252:13-14] Delete the last sentence.

  T11. [269:1] Replace "subobject selector" with
       "component selector, array section selector,
        array element selector, or substring selector".

  T12. [20:15] "In an actual argument list"
       -> "as an actual argument".

  T13. Same issue as answered in 02-278r2.

  T14. [55:5] "specific" -> "nongeneric"

  T15. [260:5] Delete ", an abstract interface".

  T16. [45:27] Append sentence "If the kind selector is omitted,
       the kind type parameter is default integer."

  T18. [255:32] "without a generic specification" ->
       "with neither ABSTRACT nor a generic specification".

  T20. [131:9] "required to evaluate only" ->
       "only required to evaluate".

  T21. [272:22,32] "specific only" -> "only specific" (twice)

  T22. [274:6] Insert "only" before "specific".

  T24. [397:15] Delete "or type-bound".

  T25. [401:28] "contains" -> "is the host of".

FEATURES

The replies to F1 and F2 are in 02-311R1.

J3/02-330r2

Date:     November 15th 2002
To:       J3
From:     Aleksandar Donev
Subject:  The value of something
Reference: J3-007R2, J3/02-302, J3/02-294r1

______________________________________________________
Summary
______________________________________________________

There is a big gap in the draft as to what the typical words "something gets the value of something" really mean for objects of derived types with defined assignment. The wording might also be missing for all objects of derived-types, but the meaning in that case is clear: Do recursive ``bitwise'' copy for each component of intrinsic type, deep copy for allocatables, shallow for pointers. For things that have defined type-bound assignment, even the meaning is not clear, because defined assignment may need to be envoked, which is dangerous. Further issues are brought on if there is a type-bound finalization procedure there and when and if that should be called.

I also point to another issue with defined type-bound assignment which should be considered in conjunction with the above one.

______________________________________________________
J3 response:
______________________________________________________

Your comment raises some important issues that need to be addressed by J3.
______________________________________________________
Notes:
______________________________________________________

In particular, the following needs to be determined:
1. How exactly should SOURCE= in ALLOCATE copy the value of the source-expr? At present we say via intrinsic assignment. We should probably say as if an assignment statement were performed (Van's opinion).
2. Same as (1) for VALUE dummy arguments.
3. Same as (1) for parenthesized expressions.
4. How does the above work for intrinsics in initialization expressions (see item 1 in 02-319).
5. Intrinsic assignment at present invokes defined assignments for certain components. Should this be defined assignment for the declared or the dynamic type.

______________________________________
Problems with "value of"
______________________________________
Take the following example:

TYPE :: my_type
   ...
CONTAINS
   GENERIC :: ASSIGNMENT(=) => my_assignment
END TYPE

INTERFACE
   SUBROUTINE my_assignment(lhs,rhs)
      TYPE(my_type), INTENT(INOUT) :: lhs
      TYPE(my_type), INTENT(IN) :: rhs
   END SUBROUTINE
END INTERFACE

TYPE(my_type) :: R

The problem occurs in many places:
__________________________________
1) Intrinsics (see J3/02-302)
__________________________________
In some intrinsic functions (see J3/02-302) we say the result is obtained from the argument, so some kind of a copy is made. How? The natural thing seems to be to that the copy is made as if intrinsic assignment were performed:
copy_of_object=object
where the declared type of the lhs and rhs is the dynamic type of object.

There are big issues with this. Intrinsic assignment for objects of derived type that contain components of a derived type with an accessible type-bound defined assignment invokes this defined assignment (see 141:13). This was apparently decided during an interp request by J3/WG5. So now take the example:

TYPE(my_type), PARAMETER :: P=my_type()
TYPE(my_type) :: Q=MERGE(P,P,.TRUE.)

Should the initialization of Q invoke the user-defined assignment of P? It better not unless compilers are much smarter then I know them to be.
__________________________________
2) Expression evaluation
__________________________________
How is the expression (R) evaluated? Is my_assignment invoked?
__________________________________
3) VALUE arguments
__________________________________
Assume we pass R as an actual argument for a dummy argument:
TYPE(my_type), VALUE :: S
How is the temporary copy (see 265: 35-37) that is associated with the dummy obtained, exactly?
__________________________________
4) source-variable in ALLOCATE
When cloning an object via SOURCE in ALLOCATE we use intrinsic assignment (see 110:9-10). Is this really what is intended?
__________________________________

______________________________________________________
Access to assignment inside defined assignment
______________________________________________________
When writing subroutines to perform defined assignment, it is often most useful to have access to some kind of ``default'' assignment, and then add some extra statements in there (like usage counting statistics). But as soon as defined assignment is accessible, one cannot access the intrinsic assignment (it would really be a recursive call to the defined one). This is rather unfortunate.

I am bringing this up here because my basic idea to the problem of making copies of objects of defined type is to invent a new term, say "default assignment", which will be like intrinsic assignment, but will not invoke defined assignments. Then we will say that for something to get the value of something really means to use this default assignment. I would eventually want to make this kind of assignment directly accessible to the users too.

End of Reference Documents