--------------------------------------------------------------------------------
083
Add an Accessibility Attribute Corresponding to READONLY
Registered
1
Related to pFR 33 (Object Oriented Fortran, OOF),
pFR 43 (OOP Capabilities),
pFR 54 (Complete Set of Explicit Attributes),
N970-18 (Object Oriented Programming),
Draft NP for TR2 on Data type enhancements.
[ Bertrand Meyer
"Object-Oriented Software Construction,"
Prentice-Hall, New York, 1988
ISBN:0-13-629049-3
]
Allow the developer of a module to specify a finer degree of control over the
accessibility of objects declared in a module. Specifically, allow the
developer to indicate that certain variables (including components of
variables of derived-type) when accessed by use association may not be
defined or redefined. An example of a possible syntax is shown after the
suggested implementation.
Currently the only control the developer of a module has over the
accessibility of individual objects is either to allow complete access,
PUBLIC, or forbid any access, PRIVATE. This can lead to awkward or
inefficient module implementations. The best example of this is a data object
whose value should only be changed through its interface, but other than
that should be retrievable by the user of the module. If declared with the
PUBLIC attribute, consistent use of the interface is not guaranteed, If
declared with the PRIVATE attribute, the value can only be retrieved by
creating a procedure whose sole use is to return the data value. It is
difficult, in the second case, to optimize away the procedure overhead
implied by the resulting semantics, and the creation of the procedure is an
unnecessary burden on the programmer.
There are two methods of accessing an object, reading a value and writing a
value. For simplicity, restrictions on a method should be confined to the
values never, once, or always. However, an access restricted to once via
procedural encapsulation has little impact on the overall performance of the
code. This suggests that the effective combinations read always + write
always, read always + write never, read never + write always, and read never
+ write never are sufficient. The present access attributes effectively allow
only two of the above attributes, PUBLIC (read always + write always), and
PRIVATE (read never + write never).
The above analysis suggests that two more accessibility attributes could be
added to Fortran, with the semantics of read always + write never, and read
never + write always. An attribute with read always + write never semantics
in particular appears to be very useful and has been implemented in several
languages.
It should also be noted that in many ways a READONLY attribute is similar in
semantics to a function without arguments, i.e., a function whose computed
value depends only on global values. The principle of encapsulation suggests
that the user of the module should not be able to tell the difference between
a data object that can only be read and such a parameterless function. Such
a lack of distinction has been implemented in a few languages.
The committee should consider adding an accessibility attribute to the
present language with read always + write never semantics, to be applied
initially only to data entities. This attribute will be discussed below
under the name READONLY (PUBLIC(READ), or READ_ONLY are other possible
terms). Should READONLY be adopted and prove useful, then the extension of
READONLY to parameterless functions and an additional attribute, WRITEONLY,
with read never + write always semantics, may also be considered for
adoption.
The suggested syntax is for illustration only, exact syntax not part of
requirement:
MODULE FLEET
TYPE CAR
READONLY
INTEGER :: CYLINDERS, MAX_PASSENGERS
CHARACTER(LEN=15) :: MANUFACTURER, MODEL_NAME
END TYPE CAR
TYPE (CAR) :: CAMARY
...
INTEGER, READONLY :: FLEET_SIZE
CONTAINS
TYPE(CAR) FUNCTION REPLACEMENT_CAR(CYLINDERS, &
MAX_PASSENGERS, MODEL_NAME)
...
END FUNCTION REPLACEMENT_CAR
... ! Several other subroutines and functions
END MODULE FLEET
The module procedures defined within FLEET can define the components of
CAMARY and can define the variable FLEET_SIZE. Scoping units accessing CAMARY
or FLEET_SIZE by use association can use the values of the FLEET_SIZE and the
values of the components of CAMARY, but cannot directly update those values.
The values can be indirectly updated by such units, either as a side effect
of invoking one of FLEET's procedures, or, in the case of CAMARY, by using
CAMARY as an argument to a procedure, whose corresponding dummy argument has
type CAR and an INTENT other than IN, or by an assignment with entities on
both sides having type CAR. A procedure with an INTENT other than IN for a
dummy argument of type CAR must either be one defined in the MODULE FLEET or,
if one defined outside of FLEET, must be one that directly, or indirectly
through a chain of calls, performs its update by invoking such a procedure
with PUBLIC accessibility. The semantics for updating an entity having a type
with READONLY components is intended to correspond to the semantics for
updating the components of an entity having a type with PRIVATE components.
Similarly a module that uses FLEET can declare entities of type CAR, but can
only modify their components by using such entities as argument to procedures
satisfying the restrictions on updating components of CAMARY
MODULE OUR_FLEET
...
USE FLEET
...
TYPE(CAR) :: COMPACT_MODEL=CAMARY
...
CONTAINS
...
SUBROUTINE CHANGE_COMPACT_MODEL(DESIRED_MODEL, &
DESIRED_CYLINDERS, DESIRED_CAPACITY, ALLOWED)
TYPE(CAR), INTENT(IN) :: DESIRED_MODEL
...
IF (ALLOWED) THEN COMPACT_MODEL = &
REPLACEMENT_CAR(DESIRED_MODEL, DESIRED_CYLINDERS, &
DESIRED_CAPACITY, MODEL_NAME)
...
END SUBROUTINE CHANGE_COMPACT_MODEL
...
END MODULE OUR_FLEET
This ensures that all components remain consistent, while allowing increased
flexibility.
The restriction READONLY has been implemented in a number of languages,
object oriented languages in particular, e.g., Eiffel, Sather, and Oberon. It
has consistently proved useful in such languages. Allowing parameterless
functions to also have the equivalent of the READONLY attribute has been
implemented in fewer languages, e.g., Eiffel and Sather, but has also proved
useful in those languages. I do not known if WRITEONLY has ever been
implemented in any major language.
A good description of the semantics of READONLY as implemented in Eiffel,
(where it is spelled READ_ONLY), appears in Bertand Meyer, "Object-Oriented
Software Construction," Prentice-Hall, New York, 1988, ISBN:0-13-629049-3.
The suggested requirements should have no impact on the efficiency or
compatibility of existing code. The modifications required in the standard
and compilers should be small for READONLY. The text in the standard that
needs to be revised appears to be well localized. Implementors already have
to make a semantic distinction between used and local entities, and place
restrictions on used entities. The additional restrictions are similar to
those specified by the INTENT attributes of the dummy arguments of
procedures, and require a similar analysis. The modifications required in
the standard and compilers should be small to moderate for "READONLY"
functions and WRITEONLY entities. The modifications are not as well
localized as for READONLY.
William B. Clodius
phone: (505) 662-3243
email: Wclodius@aol.com
email received 22-Dec-1995
The following is a suggested partial editing of the standard to include the
READONLY attribute for entities. It is based on the draft Fortran 95 standard
as published in the Fortran Forum in June 1995. A more detailed final editing
will, of course, eventually be necessary. Additional modifications would
need to be included if READONLY functions, or WRITEONLY entities were added
to the standard.
----- Section 4.4.1
----- line 16, p. 38: replace "[ private-sequence-stmt ]" with "[
access-sequence-stmt ]"
----- lines 21-22, p. 38: replace with
R424 access-sequence-stmt is component-access-stmt
or SEQUENCE
R424a component-access-stmt is PRIVATE
or READONLY
----- line 23, p. 38: replace "PRIVATE statement" with "component access
statement"
----- p. 38: Add the following to the constraints after R424
Constraint: A component-access-stmt shall not appear more than once in a
given derived-type-def.
----- p. 38: Add the following to the constraints after R427
Constraint: If a component of a derived type is of a type whose components
are declared to be readonly, either the derived type definition shall contain
a component access statement or the derived type shall be private.
----- p. 40: Add after line 23
If a type definition contains a READONLY statement, except within the module
containing that type definition, an entity of that type or any components of
such an entity behave as thought they have the PARAMETER attribute, e.g.,
such entities cannot appear on the left hand side of an assignment, and can
only be used as the actual argument to a procedure if the corresponding dummy
argument has intent IN, even if the type itself is public (5.1.2.2).
----- Section 4.4.2, p.43
----- line 14: Place "or READONLY" between "PRIVATE accessibility".
----- line 16: Replace "that are PRIVATE." with "that are PRIVATE or
READONLY."
----- Section 5.1, p. 48
----- line 14: Replace "PUBLIC attribute" in "Constraint: An entity shall
not have the PUBLIC attribute if ..." with "PUBLIC or READONLY attributes".
----- the following should be added to the list of constraints after R506
Constraint: A named constant shall not have a READONLY attribute.
----- Section 5.1.2.2 should be replaced by
5.1.2.2 Accessibility attribute
The accessibility attribute specifies the accessibility of entities
R511 access-spec is PUBLIC
or PRIVATE
or READONLY
Constraint: An access-spec shall appear only in the specification-part of a
module.
Constraint: READONLY cannot be the access-spec in a derived-type-stmt.
Entities that are declared with a PRIVATE attribute are not accessible
outside the module. Entities that are declared with a PUBLIC or READONLY
attribute may be made accessible in other program units by the USE statement.
Entities without an explicitly specified access-spec have default
accessibility, which is PUBLIC unless the default has been changed by a
PRIVATE statement (5.2.3). Entities with a READONLY attribute, in other
program units behave as though they are declared with a PARAMETER attribute,
e.g., such entities may not appear on the left hand side of an assignment,
and may only be used as actual arguments if the corresponding dummy arguments
have intent IN.
Note 5.9
An example of an accessibility specification is
REAL, PRIVATE :: X, Y, Z
----- Section 5.2.3 p. 58 After the constraints following R523
Constraint: The READONLY access-spec shall not appear if a use-name refers to
a procedure, a named constant, derived type, or namelist group.
----- In Section 6, p. 71: the following should be added to the list of
constraints after R601
Constraint: array-variable-name shall not have the READONLY attribute if it
is made accessible through a USE statement.
Constraint: scalar-variable-name shall not have the READONLY attribute if it
is made accessible through a USE statement.
Constraint: subobject shall not be a subobject designator whose parent has
the READONLY attribute if the parent is made accessible through a USE
statement.
Constraint: subobject shall not be a subobject designator whose parent has a
type contains a READONLY statement if the type is made accessible through a
USE statement.
----- p.71: the following should be added after line 14, i.e., after the
constraints which follow R601.
R601 readable is scalar-readable-name
or array-readable-name
or readable-subobject
Constraint: array-readable-name shall be the name of a data object that is
an array.
Constraint: scalar-readable-name shall be the name of a data object with the
READONLY attribute or whose type contains a READONLY statement, and the
object or type is made accessible through a USE statement.
Constraint: array-readable-name shall be the name of a data object with the
READONLY attribute or whose type contains a READONLY statement, and the
object or type is made accessible through a USE statement.
Constraint: readable-subobject shall be the name of a subobject whose parent
has the READONLY attribute or whose type contains a READONLY statement, and
whose parent or type is made accessible through a USE statement.
----- Section 7.1.1.1, p. 84, lines 2-8: add to R701 the line
or readable
----- Section 12.4.1.1, p. 199, after line 29
If the actual argument is a readable object, the dummy argument is not
definable and shall not have INTENT(OUT) or INTENT(INOUT). When a readable
object is used as an actual argument, the value associated with the readable
object at the time of invocation of the procedure shall be the value
associated with actual argument.
------------------------------------------------------------------------------
084
Make Allocatable Objects More Flexible
Registered
1
Related to pFR 33 (Object Oriented Fortran, OOF),
pFR 43 (OOP Capabilities),
pFR 54 (Complete Set of Explicit Attributes),
N970-16 (Allow ALLOCATABLE Derived Type Components),
N970-18 (Object Oriented Programming),
Draft NP for TR2 on Data type enhancements.
Allow the programmer to utilize allocatable objects in a variety of
situations where currently pointers are required. Specifically, in addition
to the present plan to allow allocatable objects in derived types and allow
allocatable dummy arguments, the standard should allow the developer to have
allocatable scalars, and specify parametrized values in an allocation. An
example of the possible syntax is shown after the rational.
Fortran 90 introduced three forms of dynamic objects, i.e., automatic arrays,
allocatable arrays, and pointers. Automatic arrays have a syntax and
semantics that is relatively straightforward, however, the syntactical and
semantic difference between allocatable arrays and pointers is not clear. It
appears that the capabilities of allocatable arrays were limited solely
because as some capabilities could be implemented with pointers it was not
believed to be necessary to give those capabilities to pointers.
This basis for the limitation was a mistake. Pointers, because of their
aliasing properties, will always be able to do things that allocatable
objects can do, but also, because of their aliasing properties, will be
difficult to optimize for many tasks that allocatable objects can also do.
Allocatable arrays should be available for all objects which need to be
implemented dynamically, but for which aliasing is not an essential aspect of
the object's task. Pointers should only be used when aliasing is an
essential part of the object's task.
Under the constraints of Fortran 90 and the Fortran 95 draft, pointers must
be used instead of allocatable arrays in many situations where aliasing is
not an essential part of the object's task. As a result, in many contexts
the processor generates inefficient code. Further, the many limitations on
allocatable arrays are non-intuitive, and it is common for the programmer to
attempt to use an allocatable array when the standard does not allow such
usage, resulting in wasted development time. The current plan for Fortran
2000 recognizes some of these problems and plans to remove the restrictions
on including allocatable components in derived types and on allocatable dummy
arguments. This proposal simply suggests that other unnecessary restrictions
be removed
The committee should consider removing many of the restrictions on
allocatable "arrays". The following two modifications in the standard are
suggested
1. Allow allocatable entities to be scalars. (This facilitates efficient
linked lists, trees, etc., but does not, by itself, facilitate efficient two
way linked lists and similar structures where a "component" needs to refer to
its container. Such structures will continue to need pointers absent other
modifications in the standard.)
2. Allow allocation (for both allocatable arrays and pointers) to specify
parametrized values. This adds more flexibility to CHARACTER entities and
derived types. The suggested syntax for such an allocation is
R622 ALLOCATE ( allocation-list [ , STAT = stat-variable ] )
R624 allocation is allocate-object [ ( allocate-spec-list ) ] [ * char-length
]
Note that at present this implies that allocated parametrized value can only
be LEN, but this will not continue to be the case if parametrized derived
types are included in the standard.
Each of these modifications probably requires a separate vote.
The suggested syntax is for illustration only, exact syntax not part of
requirement:
MODULE EFFICIENT_LINKED_LIST
...
TYPE LINKED_LIST
CHARACTER(LEN=:), DIMENSION(:), ALLOCATABLE :: NAMES
TYPE(LINKED_LIST), ALLOCATABLE :: NEXT
END TYPE LINKED_LIST
...
TYPE(LINKED_LIST) :: START
...
CONTAINS
...
RECURSIVE SUBROUTINE ADD_TO_LIST(LIST)
TYPE(LINKED_LIST), INTENT(IN OUT) :: LIST, SUBLIST
CHARACTER(LEN=:), DIMENSION(:), ALLOCATABLE :: NEW_NAMES
INTEGER :: MAX_LENGTH, NUM_LINES
LOGICAL :: DONE
...
MAX_LENGTH = 0
NUM_LINES = 0
DONE = .FALSE.
CALL GET_NAMES (SUBLIST, NEW_NAMES)
IF (.NOT. ALLOCATED(NEW_NAMES)) THEN
DONE = .TRUE.
ELSE
IF (SIZE(NEW_NAMES,1) <= 0) DONE = .TRUE.
END IF
IF (.NOT. DONE) THEN
ALLOCATE(LIST%NEXT)
ALLOCATE( LIST % NEXT % NAMES (SIZE(NEW_NAMES,1)) &
(LEN(NEW_NAMES(1))))
LIST%NEXT%NAMES = NEW_NAMES
CALL ADD_TO_LIST ( LIST%NEXT )
END IF
RETURN
...
CONTAINS
RECURSIVE SUBROUTINE GET_NAMES(TEMP, TEMP_NAMES)
TYPE(LINKED_LIST) :: TEMP
CHARACTER, ALLOCATABLE :: TEMP_NAMES(:)(:)
INTEGER LINE_LENGTH, STATUS, LINE_NUMBER
CHARACTER(LEN=80) :: LINE
LENGTH_LINE = 0
LINE = ' '
READ (FILE,*,IOSTAT=STATUS) LINE
IF (STATUS /= 0) LENGTH_LINE = LEN_TRIM(LINE)
IF (LENGTH_LINE <= 0 .OR. STATUS /= 0) THEN
ALLOCATE ( TEMP_NAMES(NUM_LINES)(MAX_LENGTH) )
ELSE
IF (LENGTH_LINE > MAX_LENGTH) MAX_LENGTH = LENGTH_LINE
NUM_LINES = NUM_LINES + 1
LINE_NUMBER = NUM_LINES
ALLOCATE( TEMP % NEXT )
ALLOCATE( TEMP % NEXT % NAMES(1)(LENGTH_LINE) )
TEMP % NEXT % NAMES = TRIM(LINE)
CALL GET_NAMES(TEMP%NAMES)
TEMP_NAMES(LINE_NUMBER) = TEMP % NEXT % NAMES
END IF
END SUBROUTINE GET_NAMES
END SUBROUTINE ADD_TO_LIST
...
END MODULE EFFICIENT_LINKED_LIST
Note that lists implemented using allocatable components appear to require
recursive subprograms to manipulate the list.
None of the above additions has any impact on the conformance of existing
code. They appear to have no impact on the performance of existing code.
The first addition is well localized and has a small impact on the language
reference and the design compilers, but the second addition has more
extensive impact on the language. Combined the two additions appear to have a
moderate to large impact on the language reference and the design of
compilers.
William B. Clodius
phone: (505) 662-3243
email: Wclodius@aol.com
email received 13-Jan-1996
The following is a suggested partial editing of the standard to include all
of the above modifications. Because these modifications also interact with
the planned allocatable components of derived types and allocatable dummy
arguments, suggested edits for implementing allocatable dummy arguments and
components of derived types are also included. It is based on the draft
Fortran 95 standard as published in the Fortran Forum in June 1995. A more
detailed final editing will, of course, eventually be necessary. (Note it is
not clear to me whether it would be useful for the sake of syntactic
consistency, to have allocatable objects have the NULL() initialization
function of pointer objects. This is not required under the present
semantics.)
Section 4.4.1 p. 38
replace lines 21-22 with
R424 component-attribute-spec is ALLOCATABLE
or POINTER
or DIMENSION ( component-array-spec )
before line 38 add the constraint
Constraint: An array shall not have both the ALLOCATABLE attribute and the
POINTER attribute.
in the constraints on lines 38-42 insert "ALLOCATABLE or " before "POINTER"
replace lines 43-46 with
Constraint: If the ALLOCATABLE or POINTER attribute is specified, either the
component-array-spec will have a deferred-shape-spec-list, or the
char-len-parameter (5.1.1.5) value will have a deferred-len-param for each
entity in the component-decl-list with a component-array-spec, or
char-len-parameter value.
Constraint: If the ALLOCATABLE or POINTER attribute is not specified, each
component-array-spec will have an explicit-shape-spec list, and each
char-len-parameter value will be a specification-expr.
p.39 replace lines 2 and 3 with
R428 component-decl is component-name [ ( component-array-spec ) ] [ *
char-length ] [ component-initialization ]
in line 8 after "expression (7.1.6.2)" add " or a deferred-len-param".
after line 8 add
Constraint: If the character length is a deferred-len-param, either the
ALLOCATABLE or POINTER attribute shall appear in the
component-attr-spec-list.
p.40
add after line 7
A component is allocatable if its component-attr-spec-list contains the
ALLOCATABLE attribute. Allocatable entities have an allocation status of
allocated or unallocated. The default allocation status of an allocatable
entity is unallocated.
p. 42 line 1 replace "A pointer" with "An allocatable or pointer"
replace lines 6-7
TYPE NODE
INTEGER :: VALUE
TYPE (NODE), ALLOCATABLE :: NEXT_NODE
END TYPE
OR
TYPE POINTER_NODE
INTEGER :: VALUE
TYPE (POINTER_NODE), POINTER :: NEXT_NODE => NULL()
END TYPE
Types such as these may be used to construct linked lists of OBJECTS of type
NODE and POINTER_NODE respectively. Type NODE will typically have the best
run time efficiency as it does not have aliasing. Type POINTER_NODE can be
useful if storage requirements are critical as the same object can be a value
for many POINTER_NODEs. See C.13 for an example.
p. 48
delete lines 1 and 2
Section 5.1.1.5 p. 50 after line 36 add
or assumed-len-param
or deferred-len-param
An assumed-length entity is a non-allocatable/non-pointer dummy argument
entity that takes its length from the associated actual argument.
R510a assumed-len-param is :
A deferred-length entity is a character pointer or allocatable entity.
A character allocatable entity is a named character entity with the
ALLOCATABLE attribute. When declared with a deferred-len-param, its length
is determined when space is allocated for the entity by execution by an
ALLOCATE statement (6.3.1), with the length attributes value associated in
with the LEN specifier in the ATTRIBUTES specifier.
A character pointer is a character entity with the POINTER attribute. When
declared with a deferred-len-param, its length is determined when it is
associated with a target by pointer assignment (7.5.2), or when space is
allocated for the entity by execution by an ALLOCATE statement (6.3.1), with
the length attributes value associated in with the LEN specifier in the
ATTRIBUTES specifier.
R510b deferred-len-param is :
The length of an unallocated allocatable character entity declared with a
deferred-len-param is undefined.
The length of the target of a disassociated character pointer declared with a
deferred-len-param is undefined. The length of such a character parameter
may be specified in two ways:
(1) It is specified in an ALLOCATE statement (6.3.1) when the target is
allocated, or
(2) It is specified in a pointer assignment statement.
The length of the character target or allocatable character entity is
unaffected by an subsequent redefinition or undefinition of variables
involved in the length.
p. 51 after line 2 add
Constraint: If the character length is a deferred-len-param, either the
ALLOCATABLE or POINTER attribute shall appear in the
component-attr-spec-list.
p. 53, line 2 replace, " or a dummy pointer" with ", a dummy pointer, or a
dummy allocatable object,"
Section 5.1.2.4.2 p. 54 line 41 after ", but " add "if declared with a
deferred shape specifier "
p. 55, line 3 replace "deferred-shape-spec-list" with "combination of a
deferred-shape-spec-list or a deferred-len param. The
deferred-shape-spec-list, if present, shall be declared".
line 4 add after "(5.2.8).", "The deferred-len-param, if present, shall be
declared in the CHARACTER type declaration statement.".
line 8 after ", but " add "if declared with a deferred shape specifier "
line 11 replace "shall" with "may"
lines 15 and 20 before " are undefined" add "if declared with a deferred
shape specifier "
Section 5.1.2.7, p. 56 line 28-29 replace the last sentence "If the pointer
is ..." with "If the pointer is a scalar character object it shall be
declared with a deferred length. If the pointer is a non-character array,
the array shall be declared with a deferred-shape-spec. If the pointer is a
character array it shall have a deferred length or the array shall be
declared with a deferred-shape-spec."
Section 5.1.2.9 p. 57 replace the paragraph on lines 2-4 with
"An object with the ALLOCATABLE attribute shall neither be referenced nor
defined unless space has been allocated for the object by execution of an
ALLOCATE statement (6.3.1). If the allocatable object is a scalar character
object it shall be declared with a deferred length. If the allocatable
object is a non-character array, the array shall be declared with a
deferred-shape-spec. If the allocatable object is a character array it shall
have either a deferred length or the array shall be declared with a
deferred-shape-spec. The full shape and length of the object may only be
determined when space has been allocated for the object by execution of an
ALLOCATE statement."
Section 6.1.2 p.73 replace line 5 with
R613 part-ref is [ part-name ] [( section-subscript-list ) ]
Section 6.3 p. 77 line 22 replace the word "arrays" with the word "objects"
Section 6.3.1 p. 77 line 27 replace the word "arrays" with the word "objects"
replace line 30 with
R624 allocation is allocate-object, [ ( allocate-spec-list ) ] [ *
char-length ]
after line 35 add
R628b char-length is scalar-int-expr
in line 36 replace the word "array" with the word "object"
after line 36 add the constraints
Constraint: An allocate-spec-list shall appear if the object was declared
with a deferred array-spec-list.
Constraint: An allocate-spec-list shall not appear if the object was not
declared with a deferred array-spec-list.
Constraint: An * char-length shall appear if the object is a character
object declared with a deferred char-length.
Constraint: An * char-length shall not appear if the object is not a
character object declared with a deferred char-length.
Section 6.3.1.1 p. 78 lines 20-26, replace every occurrence of the word
"array" with the word "object"
Section 6.3.1.2 p. 78 lines 27-43, replace every occurrence of the word
"array" with the word "object"
Section 6.3.1.2 p. 79 lines 1-5, replace every occurrence of the word "array"
with the word "object"
Section 6.3.3 p. 80 lines 11 and 14, replace every occurrence of the word
"array" with the word "object"
Section 6.3.3.1 p. 80 lines 29-42, replace every occurrence of the word
"array" with the word "object"
Section 6.3.3 p. 81 line 4, replace the word "array" with the word "object"
Section 12.4.1.1 before line 38 add the paragraph
If the dummy argument is an allocatable object, the actual argument shall be
either an allocatable object or a pointer and the types, type parameter, and
ranks shall agree. At the invocation of the procedure, the dummy argument
receive the allocation status of the actual argument. If the actual argument
is currently allocated, the dummy argument becomes associated with the same
object. The allocation status may change during the execution of the
procedure, and may become undefined (14.7.6).
Section 12.6 p. 211-212 replace every occurrence of "POINTER attribute" with
"ALLOCATABLE or POINTER attributes"
Section 12.7 p. 212 lines 45-46 replace every occurrence of "POINTER
attribute" with "ALLOCATABLE or POINTER attributes"
Section 13.11.15 p 223, delete line 27
p 224 before Section 13.11.20 line 8 add the section
13.11.19a Object allocation status functions
ALLOCATED(OBJECT) Object allocation status
Section 13.4.9 p 228 lines 20-26 replace every occurrence of the words
"ARRAY" and "array" with "OBJECT" and object respectively.
Annex A p 289 replace lines 12-13 with
allocatable object (5.1.2.4.3): A named object having the ALLOCATABLE
attribute. Only when it has space allocated for it may it be referenced or
defined. If it is an array, only when it has space allocated for it does it
have a shape.
------------------------------------------------------------------------------
085
Allow Separate Accessibility Attributes for Derived Type Components
Registered
1
Related to pFR 33 (Object Oriented Fortran, OOF),
pFR 43 (OOP Capabilities),
pFR 54 (Complete Set of Explicit Attributes),
N970-18 (Object Oriented Programming),
Draft NP for TR2 on Data type enhancements.
Allow the developer of a module to specify a finer degree of control over the
accessibility of components of a derived type as declared in a module.
Specifically, allow the developer to indicate that certain components of
variables of derived-type when accessed by use association may not be defined
or redefined, although other components when accessed by use association may
be defined or redefined. An example of a possible syntax is shown after the
suggested implementation.
Currently the components of PUBLIC types are either accessible when the
module containing the type is used, the default, or none of them are
accessible, if a PRIVATE statement is included in the type definition. This
can lead to awkward or inefficient derived type implementations. The best
example of this is a data object some of whose values should only be changed
through the type interface, but other values can be safely modified by the
user. The default does not garantee consistent use of the interface. If a
PRIVATE statement is included, then use of procedures must be used to access
any component. It is difficult, in the second case, to optimize away the
procedure overhead implied by the resulting semantics, and the creation of
the procedure is an unnecessary burden on the programmer.
The components of a derived type should be defined with a syntax as similar
as possible to that of module specification part. An access statement near
the beginning of the derived type definition defines the default, while an
access specifier in a component definition statement defines the specific
accessibility of the components defined by the statement.
The use of detailed component accessibility specification has been used in
several object oriented languages, in particular, e.g., Eiffel, Sather, and
C++. It has consistently proved useful in such languages.
Small. The amount of text in the standard that needs to be revised appears to
be well localized. Implementors already have to make a semantic distinction
between used and local variables, and intrinsic and derived types, and place
restrictions depending on these restrictions. They should have no impact on
the efficiency or compatibility of heritage code.
William B. Clodius
phone: (505) 662-3243
email: Wclodius@aol.com
email received on 15-Jan-1996
The following is a suggested partial editing of the standard to allow
accessibility distinctions between different components of a derived type. It
is based on the draft Fortran 95 standard as published in he Fortran Forum in
June 1995. A more detailed final editing will, of course, eventually be
necessary.
----- replace 4.4.1 ----- line 16, p. 38: replace "[ private-sequence-stmt ]"
with "[ access-sequence-stmt ]"
----- lines 21-22, p. 38: replace with
R424 access-sequence-stmt is component-access-stmt
or SEQUENCE
R424a component-access-stmt is PRIVATE
or PUBLIC
----- line 23, p. 38: replace "PRIVATE statement" with "component access
statement"
----- p. 38: Add the following to the constraints after R424
Constraint: A component-access-stmt shall not appear more than once in a
given derived-type-def.
Constraint: A component-access-stmt shall not appear if the access-spec of
the type is PRIVATE.
----- lines 31-32, p. 38: replace R426 with
R426 component-attr-spec is access-spec
or POINTER
or DIMENSION ( component-array-spec )
----- p. 38: Add the following to the constraints after R427
Constraint: An access-spec shall not appear if the access-spec of the type
is PRIVATE.
----- lines 19-23, p. 38: This paragraph shall be replaced by
Each component of a derived type has associated with it an accessibility
attribute (5.1.2.2). If a component has the PRIVATE attribute, the component
name is accessible only within the module which contains the derived type
definition, even if the type itself is public (5.1.2.2). The component name
is inaccessible in any scoping unit accessing the module via a USE statement.
The structure constructor for a type that contains private components shall
be employed only within the defining module.
The accessibility attribute is associated with a component in several ways.
All components of a derived type whose derived type statement has a PRIVATE
access-spec have the PRIVATE attribute. Components of a derived type whose
derived type statement has a PUBLIC access-spec can have either the PRIVATE
or PUBLIC attribute. If the component-def-stmt has an access-spec then its
accessibility attribute is that given by the access-spec. A
component-access-stmt specifies the default accessibility that applies to all
components of the derived type. The statement
PUBLIC
specifies a default of public accessibility. The statement
PRIVATE
specifies a default of private accessibility. If no such statement appears
in a derived type whose derived type statement has a PUBLIC access-spec, the
default is public accessibility.
------------------------------------------------------------------------------
086
STREAM I/O
Registered
1
A extension to the OPEN statement to enable "byte stream" I/O on that logical
unit.
C-style "byte stream" has become a de facto standard far beyond the direct
scope of the C environment. In a scientific application it is not surprising
to have a sensor feeding a stream of data to a processor which in turn feeds
the results over a heterogeneous network for additional processing. Fortran
record structure provides the user with an obstacle to overcome in this
scenario (the processors may not have the same record conventions (even when
the CPU architecture is the same), etc.)
A special specifier on the OPEN statement to provide (formatted or
unformatted, direct or sequential) stream I/O. It is intended that such I/O
be compatible with that processors equivalent C environment.
A possible implementation might look like:
OPEN (unit=5, file = "stdin", form = "formatted", style = "stream")
As there will be no record information stored, BACKSPACE will be prohibited
on this unit. There may well be other limitations.
(Note: this is not the same as non-advancing I/O. In that case, there is a
record structure, even if the programmer only operates on a single record
during an entire run. Though the difference may be moot in some operating
environments, it may be critical in others. In addition, the extra record
information could present difficulties to other Fortran processors or to
processors other than Fortran.)
Keith Bierman, X3J3
Feb-1996, meeting 136, paper 96-044
------------------------------------------------------------------------------
087
Volatile
Registered
1
A new data attribute, volatile, to allow a user to instruct the processor
that a variable may have it’s value changed at any time by means other
than Fortran.
When writing device drivers and for some forms of shared memory, it is
necessary to treat some memory as "volatile" that is it may be changed by
means other than Fortran at "any" time. Some implementations have a special
declaration "VOLITILE" which notifies the processor that the variable in
question must be treated specially (especially by the optimizer). That
implementations have seen fit to provide such facilities for many years,
suggests that there is a legitimate need.
Note that while it can be argued that device driver style code is inherently
non-portable, shared memory (at least on a family of operating systems) is
often portable across processors.
Keith Bierman, X3J3
Feb-1996, meeting 136, paper 96-044
------------------------------------------------------------------------------
088
User specified precedence
Registered
1
A method to allow users to specify operator precedence rules for user
specified operations on derived types.
It is unhelpful to offer users the ability to extend their system to have new
datatypes and operations, but to have no control over operator precedence. It
is implausible for projects such as INTERVAL ARITHMETIC to establish their
interfaces as good candidates for eventual standardization if the prototypes
cannot look and feel as if they are part of the language.
(Note: It has been suggested that the built in arithmetic operators should
retain their precedence rules for derived types, this would limit this new
feature to user defined operators of the .op. form. This may be acceptable,
but it should be noted that not all mathematical datatypes/operators have the
same mathematical properties. It would be nice if Fortran could reflect
this).
At the point at which a user defined operator is defined, a user specified
precedence could be assigned, something of the form:
..., PRECEDENCE =n
where n is an integer constant, where 1 has the highest precedence and each
larger value is lower. Ties to be broken using a simple left to right rule.
Keith Bierman, X3J3
Feb-1996, meeting 136, paper 96-044
------------------------------------------------------------------------------
089
Generic pointers
POINTER, GENERIC, OBJECT ORIENTED, POLYMORPHISM
Registered
/OOF
1
Allow a generic pointer, which could point to targets of
multiple types. The set of allowed target types is
specified at compile time.
To simplify both the descriptive model and the implementation,
the set of allowed operations with generic pointers is
restricted. The general restriction is that a generic
pointer can not be used in any context that requires
a reference to the target. The only things allowed with
such a pointer would be nullification, pointer assignment,
and argument passing.
It is very common to define procedures that conceptually
apply to any data type and that need know virtually nothing
about the details of a data type; all they need to know is
how to point to an object of such a type. Classic examples
of such procedures include ones implementing stacks, lists,
trees, and other such data structures. A single program
might well want to apply such a procedure to many different
types.
For example, I have a module that is used to associate names with
objects. (These names are run-time-defined character values, not
variable names known at compile time). Several thousand objects
of a given type might exist in a run of the program. Each object
is assigned a name when it is created at run-time. One procedure
in the module is called to "associate" the object with the name.
The user can then later reference the object by name; another
procedure in the module is used to return a pointer to the
object of a specified name. There are about a dozen different
types of objects which use this naming service.
This is a basic form of polymorphism that could be achieved
with a generic pointer. Pointer assigment or argument
association would be used to "transfer" between the generic
pointers and regular, specifically typed pointers.
With f95, such polymorphism is extremely awkward. I can come
up with 3 general approaches, but none of them are satisfactory.
One approach is to just write N copies of the desired code,
where N is the number of types to be handled. The N copies
can define specific versions of a generic procedure. This
approach is awkward enough when there are "only" a dozen
or so versions needed as in my application; the problem
rapidly expands as soon as there can be combinations of
types involved. In addition to the code maintenance
problems, this approach ends up with needless duplication
of virtually identical executable code.
Another approach, suggested in several of the f90 textbooks, is
to make use of the TRANSFER intrinsic. I've tried this. The code
necessary to actually do it is incredibly complicated and
obscure. I have to wonder if those people recommending this have
never actually tried it (and without making the non-standard
assumption that pointers to different types were always the same
physical size, which f95 specifically says need not be the case).
The code to do this is so ugly that I'll not try to include it
here; I've done a sample as a separate paper. I don't think anyone
will ever point to it as a reasonable approach. Additionally,
such code makes semantic assumptions about the effects of
TRANSFER that are not really guaranteed by the standard; it also
almost invariably breaks garbage collectors.
The third approach is to "punt" back to Fortran 77 style
and use array indices instead of pointers. This basically
takes advantage of the fact that the same integer type can
be used as an index into an array of any type. This approach
can be made to work (witness lots of F77 code), but is pretty
restrictive in many ways, and can cause performance problems
(if you keep having to resize arrays because you don't know
ahead of time how many objects of the type you will need).
All of the above approaches strike me as being "object-hostile"
instead of object oriented. That they can be made to work at
all just reflects the cliche that you can write code to do
almost anything in almost any language - but you probably
wouldn't want to. Generic pointers would provide a relatively
simple way to make at least this limitted form of object
orientation viable in Fortran.
The restrictions placed on generic pointers allow processors
to avoid the issues of binding. A processor never really
needs to know what the actual type of the target is. The
processor may keep track of the type of the target at run
time to check for user errors, but this is not required
(much like a processor may check for exceeding array bounds,
but it is not required).
The following are preliminary concepts of the limitations
placed on generic pointers.
A generic pointer can be pointer-assigned to point to a target
of any of the specific types for the generic; rank agreement is
required. A pointer assignment statement of the form
specific-pointer => generic-pointer
can be executed only if generic-pointer is either disassociated
of is associated with a target of the same type as specific-pointer.
Note that the only way to dereference a generic pointer is to
pointer-assign a specific pointer to it and then dereference
the specific pointer.
A generic pointer could appear as an actual or dummy argument;
the corresponding dummy or actual argument would have to be a
pointer of the same rank, but could be of any of the specific
types for the generic. While a generic pointer dummy argument
is associated with a specific pointer actual argument, it
may become pointer-associated only with targets of the
type of the actual argument. If a generic pointer actual
argument is associated with a specific pointer dummy argument,
the initial association status of the dummy argument is
undefined if the generic pointer points to a target of
an inappropriate type (this last rule could be strengthened
to disallow the mismatch in the first place; that would
force users to nullify generic pointers before using them
as actual arguments in some cases).
Richard Maine, maine@altair.dfrc.nasa.gov
Feb 96, Meeting 136: Submitted as X3J3/96-046
-------------------------------------------------------------------------------
090
Optional "START" Statement
Registered
1
Allow an optional start statement between data declarations and
executable statements and constructs. This statement must follow PARAMETER
statements, derived-type definitions, interface blocks, type declaration
statements, specification statements, and statement function statements.
This statement must precede executable constructs.
This feature would improve readability and may marginally improve
compiler performance. I expect that it would be required in educational
environments. It provides a compiler check that a similar comment line
would not give.
The statement would take the form of:
START [program-class [name] ]
where the program-class is PROGRAM, SUBROUTINE, or FUNCTION. The syntax
should be similar to the END statement. name, if present, must match the
name of the program, subroutine, or function.
Loren Meissner, Professor of Computer Science
University of San Francisco
meissner@usfca.edu
February 1996, meeting 136: submitted 96-042
-------------------------------------------------------------------------------
091
Extend MAX, MIN, etc. to CHARACTER Data Type
Registered
1
Extend the intrinsic functions MAX, MIN, MAXVAL, MINVAL, MAXLOC,
and MINLOC to accept arguments of CHARACTER data type.
Regularity is the primary reason for this requirement. These
intrinsic functions accept arguments of two other intrinsic data types,
REAL and INTEGER. Accepting this proposal would recognize first class
status of the CHARACTER data type and would extend these functions to all
intrinsic data types for which they would make sense.
This requirement would considerably simplify the implementation of
generic sort algorithms that are sometimes applied to CHARACTER data.
Loren Meissner, Professor of Computer Science
University of San Francisco
meissner@usfca.edu
February 1996, meeting 136: submitted 96-042
-------------------------------------------------------------------------------
092
Permit (LEN=*) for Initialized CHARACTER Variables
Registered
1
Permit (LEN=*) designation for initialized CHARACTER variables
with the specific length to be determined from the initialization expression.
This feature would primiarily benefit programs in which all string
values have the same actual length with padding or truncation occurring
rarely. It simplifies program construction because it is not necessary to
count characters in the initialization expression. It adds a bit of
regularity in analogy with PARAMETERs of CHARACTER type.
Loren Meissner, Professor of Computer Science
University of San Francisco
meissner@usfca.edu
February 1996, meeting 136: submitted 96-042
-------------------------------------------------------------------------------
093
Extend Non-advancing I/O to List-Directed I/O
Registered
1
Permit list-directed formatting with the ADVANCE="NO" specifier.
This feature adds regularity. It simplifies frequently occurring
operations where parts of an output record are generated in successive
statements by permitting it to be list-directed. It also permits input
from a single record to occur in separate statements. In this latter case,
the input might include tests based on the first part of the input data.
Proof that this would be feasible can be found in most freshman
Pascal programs. In such programs, the most common I/O operation is
equivalent to Fortran list-directed non-advancing.
Loren Meissner, Professor of Computer Science
University of San Francisco
meissner@usfca.edu
February 1996, meeting 136: submitted 96-042
-------------------------------------------------------------------------------
094
Extend Initialization of COMPLEX Variables
Registered
1
Permit initialization of COMPLEX constants with named constant in
either part. Alternatively, permit the intrinsic function CMPLX in
initialization expressions.
Applications which make extensive use of conplex numbers need
maximum flexibility to permit suitable programming style. Such applications
occur in a wide variety of fields such as electrical engineering, as seen in
the example below.
The current standard requires
REAL, PARAMETER :: Omega = 1.23E6
COMPLEX :: J_Omega = (0.0, 1.23E6)
which means that the same constant must be declared twice, once real
and again in the imaginary part of the complex constant. This could lead to
inadvertent programming errors.
The first method would allow the following syntax:
REAL, PARAMETER :: Omega = 1.23E6
COMPLEX :: J_Omega = (0.0, Omega)
The alternative method would allow the following syntax:
REAL, PARAMETER :: Omega = 1.23E6
COMPLEX :: J_Omega = CMPLX (0.0, Omega)
Loren Meissner, Professor of Computer Science
University of San Francisco
meissner@usfca.edu
February 1996, meeting 136: submitted 96-042
-------------------------------------------------------------------------------
095
Lower Case Syntax Elements
Registered
1
A Fortran processor should recognize the use of lower case letters in all
Fortran syntax elements. This should include all keywords and symbolic names.
In all cases the use of lower case letters should be equivalent to upper case
letters except in a character context (i.e., Fortran syntax would continue to
be case insensitive). There may be a need for a second exception as part of
the functionality needed to implement interoperability with C.
Examples in the standard should include mixed case syntax.
The need to restrict syntax elements to upper case letters is a relic from
the 1960s. Up until the early 1980s, some machines did not support lower
case letters in their character sets. Now, such a restriction is no longer
necessary; all platforms with a Fortran 90 processor include support for
lower case letters.
Removing the upper case only restriction would allow programmers to write
more visually appealing code. All other major languages already support
lower case letters in their syntax elements.
Removing this restriction would help remove the image that Fortran still has
of being a "Stone Age" relic.
All that would be necessary would be to make the appropriate edits to
the text in section 3.1.1.
Minimal. Almost all modern Fortran processors already support mixed
case syntax elements as an extension.
Craig T. Dedo
17130 W. Burleigh Place
Brookfield, WI 53005
(414) 783-5869
E-mail: Craig.Dedo@mixcom.com
ISO/IEC 1539:1991 (E) 3.1.1
February 1996, meeting 136: submitted 96-049
------------------------------------------------------------------------------
096
Any Kind of Integer for I/O Specifiers
Registered
1
I/O specifiers which use INTEGER data objects should be able to use any kind
of INTEGER which is defined on the processor. The current restriction which
requires the use only of default INTEGER data objects should be removed.
Recent e-mail discussion brought attention to the fact that that the Fortran
90 standard permits any kind of integer for some I/O keywords while it
requires the use of default integer data objects for other I/O keywords.
This is an unnecessary irregularity.
Some Fortran processors use a default integer size of 4 bytes (32 bits)
always but also allow the user to specify an 8 byte (64 bit) integer data
object. Other Fortran processors also support 8 byte integers but offer the
user a choice of a default integer size of either 2 bytes or 4 bytes. On
these processors, certain large size I/O operations (i.e., those with a
number of records or a record size greater than 2.147 billion) are more
difficult than they need to be. Although workarounds are possible, they are
clumsy and error prone.
Replace scalar-default-int-variable with scalar-int-variable wherever it
occurs in connection with an I/O specifier.
Minimal. Many Fortran processors already support this feature as an
extension.
Craig T. Dedo
17130 W. Burleigh Place
Brookfield, WI 53005
(414) 783-5869
E-mail: Craig.Dedo@mixcom.com
February 1996, meeting 136: submitted 96-049
------------------------------------------------------------------------------
097
Standardized and Unique KIND Numbers
Registered
1
The next Fortran standard should require that certain KIND numbers always
represent specific representations of data types.
If unsigned integers become part of Fortran, they should also have the same
standard KIND numbers as the same sized signed integers.
The standard should also reserve certain ranges of KIND numbers for use by
future Fortran standards while reserving other ranges for processor dependent
data representations.
All KIND number assignments to data representations should be unique; i.e.,
for a particular intrinsic data type, there should be a one-to-one
correspondence between KIND numbers and data representations.
Portability is the main reason for this feature. An application programmer
who uses one of the standardized KIND numbers can be guaranteed that the
standard KIND will behave the same regardless of processor.
As a first proposal, the standard should assign KIND numbers to data type
representations as follows:
Data Type KIND Representation
LOGICAL 1 8 bit logical
INTEGER 1 8 bit signed integer
INTEGER 2 16 bit signed integer
INTEGER 4 32 bit signed integer
INTEGER 8 64 bit signed integer
REAL 4 32 bit IEEE representation
REAL 8 64 bit IEEE representation
REAL 16 128 bit IEEE representation
COMPLEX 4 32 bit IEEE representation each for real and imaginary
parts
COMPLEX 8 64 bit IEEE representation each for real and imaginary
parts
COMPLEX 16 128 bit IEEE representation each for real and imaginary
parts
CHARACTER 1 ASCII
CHARACTER 2 ISO 10646 (2 byte), a.k.a. Unicode
CHARACTER 3 C language character set (8 bit)
This feature should have minimal to moderate impact. Most of the proposed
KIND number assignments are already in use in most Fortran 90 processors. A
few vendors will have to change the KIND numbers of their non-IEEE
representations in order to satisfy the uniqueness requirement.
Craig T. Dedo
17130 W. Burleigh Place
Brookfield, WI 53005
(414) 783-5869
E-mail: Craig.Dedo@mixcom.com
February 1996, meeting 136: submitted 96-049
------------------------------------------------------------------------------
098
Required INTEGER and LOGICAL Kinds
Registered
1
The new Fortran standard should require Fortran processors to support one
kind of LOGICAL and four kinds of INTEGER data objects, as shown in the
following table. If unsigned integers become part of Fortran, they should
also be supported in the same manner as for signed integers.
Data Type KIND Representation
LOGICAL 1 8 bit logical
INTEGER 1 8 bit signed integer
INTEGER 2 16 bit signed integer
INTEGER 4 32 bit signed integer
INTEGER 8 64 bit signed integer
This feature will greatly aid portability. An application programmer who
uses one of the required kinds can be guaranteed that the standard kind will
be available regardless of processor.
Minimal. Some vendors may have to develop support for one of the kinds on
the list. In some cases the hardware will not support one of the kinds so
the processor will have to emulate the kind in software.
Craig T. Dedo
17130 W. Burleigh Place
Brookfield, WI 53005
(414) 783-5869
E-mail: Craig.Dedo@mixcom.com
February 1996, meeting 136: submitted 96-049
------------------------------------------------------------------------------
099
Include "Sets" and "Subsets"
Registered
1
Related to pFR 1 (Bit Data Type, Non-string)?,
pFR 12 (Condition Handling),
pFR 17 (Bit Data Type, String),
pFR 33 (Object Oriented Fortran),
N970-5 (Exception Handling),
N970-11 (Aliasing Type Definitions),
N970-14 (Parameterized Derived Types),
N979-18 (Object Oriented Programming),
Draft NP for TR2 on Data type enhancements.
Provide a means of specifying a collection of objects, and other collections
that may only contain a subset of that collection of objects, or collections
that contain a superset of that collection of objects. Collections that are
subsets of the same collection should be allowed the normal binary set
operations, e.g., union, disjoint union, difference, symmetric difference,
intersection, and inquiries as to whether one is a subset or superset of the
other, or whether the sets are equivalent. Elements of a set and subsets of
the set should be subject to the operations of element insertion, element
deletion, and inquiries as to whether the element is also an element of the
subset.
The concept of set is intrinsic to many aspect of programming languages,
e.g., type systems, and many problems addressed by programming languages.
Typically this concept is implicit in programming languages, but some
languages have benefited by explicitly including the concept, e.g., SETL and
the set types of Modula 3. Fortran would benefit in several ways by
explicitly including the set concept. Direct benefits could include serving
as the basis of an exception handling mechanism, implementing the
capabilities of bit data types, providing the capabilities of the
enumerations of other languages in a safer form, providing a type with a KIND
value that can map to some implementations of C's enums, and as a means of
expressing typed polymorphism. It would benefit Fortran indirectly by
serving as a reminder to those involved with the language of the set basis of
every programming language.
The question might arise as to whether the inclusion of sets in the language
is the best means of obtaining the desired benefits. Of the noted
applications, only the bit data type appears to be implementable as a library
or user defined module. The other applications typically involve name
recognition or syntax of a form that must be implemented either by a compiler
or by a preprocessor. Although these capabilities can individually be made
part of the language with their set relationship invoked abstractly if at
all, if more than one or two of these capabilities are to be added to the
language it appears to be simpler to give the language an overall framework
for their description.
There are at least two ways Fortran would benefit by incorporating the set
concept. One is as a special form of user defined type, defining a finite
set of values, the other is as an entity attribute, which defines an entity
that may contain more than one value of a type. It is simplest to restrict
the second concept to subsets of a type defined via the first concept, as
that avoids any problems associated with dealing with very large value sets,
e.g., INTEGERs and REALs. This is similar to the set concept of Modula 3.
Both implementations should be subject to the normal operations of sets,
e.g., union, disjoint union, difference, symmetric difference, intersection,
inquiries as to whether one set is a subset, superset, or equivalent to
another, element insertion, element deletion, and inquiries as to whether the
element is also an element of the set. However, unlike normal sets, which
may contain any object and hence are considered untyped, for efficiency and
type safety the syntax and semantics should restrict the possible contents of
the sets so that the sets can be considered typed objects. It should also be
possible to index arrays with elements of set.
It is possible that Fortran would also benefit from sets of entities, similar
to SETL's implementation of sets. In particular such sets would facilitate
some forms of parallelization. However, inclusion of that capability would
have much larger impact, both on the language and on compilers and should
only be considered after other approaches have failed.
The impact on the efficiency or compatibility of heritage code should be
negligible. The effect on the text of the standard and compilers can be
anywhere from very small, if the sets are confined to user defined types, to
moderate, if subsets are made an attribute of entities of such user defined
types, to very large if subsets of large value sets or of sets of entities
are added to the language.
William B. Clodius, "Comments on sets and their inclusion in Fortran,"
X3J3/96-060.
J.M. Sipelstein and G.E. Blelloch, "Collection-Oriented Languages," Carnegie
Mellon University, School of Computer Science report, CMU-CS-90-127, March
18, 1991.
W. Kirk Snyder, "The SETL2 Programming Language," Technical Report 490,
Courant Institute of Mathematical Sciences, New York University, September 9,
1990.
Samuel P. Harbison, "Modula-3." pp. 92-97, Prentice-Hall, Engelwood Cliffs,
New Jersey, 1992.
William B. Clodius
phone: (505) 662-3243
email: Wclodius@aol.com
email received on 13-Mar-1996
------------------------------------------------------------------------------
100
Implementing an Arbitrary Number of Nested DO Loops
Registered
1
Permit a programmer to use an instruction allowing implementation
of an ARBITRARY number of nested DO loop statements.
Usually, any problem which needs a given number of nested DO statements
in the current compilers cannot be programmed in a general manner, unless
a convenient algorithm is used. The users cannot simply program an
expression, called a NESTED SUMMATION SYMBOL (NSS), like:
(summation from j1) (summation from j2) ... (summation from jn),
being n a variable. The aim of a NESTED DO LOOP (NDL) statement is to
provide automatic Fortran implementation of this kind of general
instruction. This statement is more universal than the FORALL one. A NDL
sentence is fully parallellizable.
All Fortran users can benefit of a sentence like that. Fortran, at this
moment, has not a direct capability to implement algorithms involving a
variable number of DO loops. Providing an automatic way to program such a
sentence will ease the implementation of many mathematical, physical, che-
mical, and many other problems related to nested sums.
This feature should be a Fortran standard because it provides in a unique
sentence the possibility to translate a wide variety of mathematical formu-
lations.
The implementation costs of satisfying this requirement cannot be very big,
because once the FORALL sentence is already accepted, then a small modifica-
tion will tremendously enhance the existing and new codes.
The impact of including NESTED DO LOOP sentences will be so wide that it
will encompass all the hardware supports, from sequential to parallell
machines.
The inclusion of NDL senteces will not invalidate any existing program.
Additional information:
BACKGROUND OF NESTED DO LOOPS (NDL)
A new mathematical concept, the Nested Summation Symbol (NSS) is proposed
here. This concept is attached to a mathematical linear operator
directly related to the summation symbols. We insist over this symbol
potential usefulness to develop sequential and parallel computational
algorithms, constituting a powerful link between mathematical formalism and
high level languages programming. A NSS is well suited in order to express
some kind of mathematical formulae and to implement them in any computational
environment. In this sense, NSS's are directly related to Artificial
Intelligence techniques. Nested sums are connected with NDL structures.
A) DEFINITION
A NDL is the algorithmic implementation of a set of NESTED SUMATION
SYMBOLS (NSS) like:
(summation from j1=i1 to f1 step s1) (summation from j2=i2 to f2 step s2)
...
(summation from jn=in to fn step sn) [EXPRESSION(j1,j2,...,jn)]
In a NDL one must describe the following parameters:
j : A vector which returns at every time the summation symbol index values
i : A vector containing the initial values for the indices collected in
vector j
f : A vector containing the final values for the indices collected in
vector j
s : A vector containing the increment values for the indices collected in
vector j
n : The so called dimension of the NDL, that is, the number of DO
sentences to nest. n is the dimension of all the previous vectors.
B) UTILITY
Among other mathematical and general applications, using a NDL you can solve
several problems such as:
* How to simulate n DO sentences ?
* How to count and generate all the combinations of m elements taken
in groups of n ?
Answers:
* How to simulate n DO sentences ?
Program 1 codifies in FORTRAN language a simple algorithm which generates
all the j index vectors arising from a general NSS. The step vector s can
have positive or negative indices. The values of the parameters depend on
the particular application one wants when running the algorithm. A call to
the Application routine is performed for every form of the vector j.
! Program 1. Fortran 90 version.
!-------------------------------------------------------------------------
! This is a solution using NDL.
! This produces n=3 nested DO instructions.
! The value range for each index is from 0 to 1 with an increment of 1.
!-------------------------------------------------------------------------
Parameter (n=3) ! Dimension of the NSS
Integer*1 j(n),i(n),f(n),s(n) ! Parameters of the NSS
! < Initial parameter values >
i(:)=0 ! Initial value
f(:)=1 ! Final value
s(:)=1 ! Step increment
j(:)=i(:) ! Initialization of NSS variable
! < NDL procedure >
k=n ! k signals the active summatory number
NDL: do while (k>0)
if ((j(k)-f(k))*s(k)>0) then ! Index out of range ?
j(k)=i(k); k=k-1
else ! executes and application using the n vector j indices
write (*,*) j ! Here the Expression(j) is evaluated
k=n
end if
if (k>0) j(k)=j(k)+s(k) ! Step Increment
end do NDL
END
!-----------------------------------------------------------------------
! The output of this program is
!
! 0 0 0
! 0 0 1
! 0 1 0
! 0 1 1
! 1 0 0
! 1 0 1
! 1 1 0
! 1 1 1
!
* How to count and generate all the combinations of m elements taken
in groups of n ?
!-------------------------------------------------------------------------
! This is a solution using a revised version of a NDL.
! This simulates how to count and GENERATE the 10 combinations of M=5
! elements taken in groups of N=3
!-------------------------------------------------------------------------
integer*1 J(0:2),F(2)
!
M=5
N=2 ! Is the dimension of the NDL
MN=M-N
J(0)=0; DO I=1,N; J(I)=J(I-1)+1; F(I)=MN+i; END DO ! Initializes NDL
!
ICOUNTER=0; K=N
NDL: DO WHILE (K/=0)
IF (J(K)>F(K)) THEN
K=K-1; J(K)=J(K)+1
DO I=K+1,N; J(I)=J(I-1)+1; END DO ! Redefines internal indices
ELSE
ICOUNTER=ICOUNTER+1 !
WRITE(*,'(I3,2X,3I3)') ICOUNTER,(J(I),I=1,N) ! Application
K=N; J(K)=J(K)+1
END IF
END DO NDL
END
!-----------------------------------------------------------------------
! The output of this program is
!
! 1 1 2
! 2 1 3
! 3 1 4
! 4 1 5
! 5 2 3
! 6 2 4
! 7 2 5
! 8 3 4
! 9 3 5
! 10 4 5
A NDL is a general algorithm, which enables to perform a parallel
EXPRESSION(j1,j2,...,jn) implementation, if the available hardware allows to
run it in this manner. This is so because the NDL internal statements may
always run independently on separate CPUs. That is, despite the forms of the
vector j are generated in a sequential manner, the evaluation of the code in
EXPRESSION(j1,j2,...,jn) using a vector j form can be done independently of
the remaining vector forms.
In fact, it can be said that any formula or algorithm which can be written in
terms of NSS can be written in a NDL form and parallelized.
Some Fortran or C compilers, by the way, have no capacity of processing more
than a limited number of classical do loops in a nest. Thus, a simple scheme
as the one shown in Program 1 is a good candidate to circumvent this
limitation in any compiler, if it is present.
But the principal characteristic of a NDL is that a single routine serves
to simulate 1, 2, ... or n NESTED DO LOOP statements.
See Program 2 for details about the practical implementation of a NSS in terms
of a NDL in the C++ language. There it is shown how the NSS codification can
be easily used as a pseudoinstruction. It can be seen how once the Header of
the program is defined, the use of the NDL appears to be an 'ad hoc' language
capability.
As an example, Program 2 shows a main program using Header 1: It defines a
NDL and calls the application procedure. There the application is a routine
showing the current values of the NDL index vector j. In Program 2 the Header
has been used and it has been defined a NDL with the parameters n=3,
j=(0,0,0), i=(1,1,1), f=(1,1,1) and step vector s=(1,1,1). This NDL generates
all the 3 digit binary numbers in canonical order (variations generation).
// Program 2
//------------------------------- Program in C++ version ------------
#include
#include
#include
#include
#include "ndl.h" // NDL methods: Header 1 code
// Application shows the J vector index values of the NDL
void Application(NDL &A)
{
for (int i=1 ; i<=A.DIMENSION() ; i++) cout << A.J(i);
puts("");
}
void main()
{
// Defines the 3-dimensional NDL called A
NDL A(3, 0,0,0, 1,1,1, 1,1,1);
// Generates forms of vector J and calls Application
while (A.RUNNING()) Application(A);
}
//------------------------------------------------------------------
//The output generated by Program 2 is:
//
// 000
// 001
// 010
// 011
// 100
// 101
// 110
// 111
Header 1 shows the header file needed to implement the NDL object and related
methods. This implementation covers the ability to define arbitrary
dimensional NDL's. Error tests have been omitted in order to simplify the
program listing and make it more transparent.
// Header 1
//--------------------------------------------------------------------------
class NDL // Defines the NDL object
{
int dimension,n,k; // n, k: Auxiliar variables
int *j,*i,*f,*s; // Pointers to the Parameters of the NDL
public:
NDL(const int, ...); // Constructor
~NDL(void); // Destructor
unsigned int RUNNING(void); // Generates next leader vector
void INITIALIZE(void); // Initializes NDL
int DIMENSION(void); // Returns NDL dimension
int J(int); // Return NDL J index value
};
//------------------------------------------------------------------------
// Nested Do Loop (NDL) algorithm
unsigned int NDL::RUNNING(void) // Generates next leader vector form
{
if (k>=0) *(j+k)+=*(s+k); // Step
while (k>=0)
if ( (*(j+k)-*(f+k))*(*(s+k))>0 ) // Limit exceeded: index out of range
{
*(j+k)=*(i+k);
k--;
if (k>=0) *(j+k)+=*(s+k); // Step
}
else
{
k=n;
return 1; // Another vector J form is achieved
}
NDL::INITIALIZE(); // Initialize NDL for further use
return 0; // Ends NDL vector generation
}
//--------------------------------------------------------------------------
int NDL::DIMENSION(void) { return dimension; } // Returns the NDL dimension
//--------------------------------------------------------------------------
// Returns the NDL vector index m value (indices numbered from 1 to dimension)
int NDL::J(int m) { return *(j+m-1); }
//--------------------------------------------------------------------------
// NDL definition
NDL::NDL(const int dim, ...) // Constructor
{
va_list index;
va_start(index,dim);
j=new int[dim]; // Allocate needed vectors
i=new int[dim];
f=new int[dim];
s=new int[dim];
dimension=dim; // Store auxiliar variables
n=dim-1;
// Initial, Final and Step vectors (variable number of arguments)
for (int m=0;m
1. Nested Summation Symbols and Perturbation Theory.
R.Carbo and E.Besalu. J.Math.Chem. 13 331-342 (1993)
2. Definition, Mathematical Examples and Quantum Chemical Applications of
Nested Summation Symbols and Logical Kronecker Deltas.
R.Carbo and E.Besalu. Computers & Chemistry 18 (2) 117-126 (1994)
3. Applications of Nested Summation Symbols to Quantum Chemistry:
Formalism and Programming Techniques.
R.Carbo and E.Besalu in
Strategies and Applications in Quantum Chemistry: from Astrophysics
to Molecular Engineering. M.Defranceschi and Y.Ellinger (Editors).
Kluwer Ac.Pub. Amsterdam (1993)
Emili Besalu & Ramon Carbo
Phone: 34 72 226366 or 34 72 418362
Fax: 34 72 418357
Address: emili@stark.udg.es or director@iqc.udg.es
Postal Add.: Institute of Computational Chemistry
University of Girona
17071 Girona
Spain
email from US2RMC::"admpap@xamba.udg.es" "Pilar del Acebo" on
12-Mar-1996
------------------------------------------------------------------------------
101
Permit BOZ constants in the TRANSFER function
Registered
1
Permit BOZ literal constants to be used in the SOURCE argument of
the TRANSFER function, either as scalar values or within array
constructors. Prohibit the use of such constants in the TRANSFER
function if they are too long to fit in any available integer
representation method.
EDITS (based on X3J3/94-007R4):
1. [32:1-2] Section 4.3.1.1: Replace the paragraph beginning "In a
DATA statement..." with,
An unsigned binary, octal, or hexadecimal literal
constant may be used as a data-stmt-constant>
corresponding to an integer scalar variable in a DATA
statement (5.2.9) or in the SOURCE argument to the
TRANSFER function (13.13.110).
2. [32:6] Section 4.3.1.1: In the constraint following R407, after
"DATA statement" add "or in the SOURCE argument of the TRANSFER
function".
3. [44:40+] Section 4.5: Insert after the first line of R433,
or> boz-literal-constant>
4. [45:5+] Section 4.5: Add the following constraints:
Constraint: An array-constructor> shall not
contain a boz-literal-constant> unless
it is the actual argument corresponding to
the SOURCE dummy argument of the TRANSFER
function (13.13.110).
Constraint: All boz-literal-constant>s used in an
array-constructor> must explicitly
specify the same number of bits.
5. [271:10+] Section 13.13.110: Add the following new paragraph to
the end of the "Result Value" section:
If SOURCE is specified as a boz-literal-constant>
(4.3.1.1), or as an array-constructor> containing
boz-literal-constant>s, these constants shall be
treated as integer values in the representation method
having the smallest value for the model parameter,
s> (13.5.7), that is at least as large as the number
of bits explicitly specified in the constant. For
example, if SOURCE is specified as Z'00FF', it is treated
as 255_K16, where K16 is whatever integer kind type
parameter gives the smallest value of BIT_SIZE(0_K16)
that is greater than or equal to 16. A
boz-literal-constant> specifying more bits than
allowed by any available integer representation method
shall not be used in SOURCE.
Leonard J. Moss
Stanford Linear Accelerator Center
MS 97; P.O. Box 4349; Stanford, CA 94309
email received from LJM@SLACVM.bitnet on 15-Dec-1994
------------------------------------------------------------------------------
102
Delete Arithmetic IF
Registered
1
The Fortran 2000 standard should delete the arithmetic IF construct
(8.2.4, B.2(1)).
The arithmetic IF is a construct left over from the 1950s when Fortran
was designed to run on a particular machine, i.e., the IBM 704, which had
an instruction set which was particularly well suited to this form of
branching. Continued use of this feature encourages the construction of
difficult to follow, spaghetti-style control flow.
The arithmetic IF can be replaced by the block IF construct, which is an
easier to use and more generalized form of the IF control structure. The
availability of sophisticated, highly reliable code restructuring tools means
that converting arithmetic IF constructs to block IF constructs can be done
automatically, efficiently, and economically.
Delete section 8.2.4 from the standard. Enter the text of 8.2.4 into
Annex B as part of section B.1 for the benefit of those vendors who wish to
continue supporting the arithmetic IF feature. Most likely, the person who
does the work will have to find the other places in the standard where this
construct is mentioned.
Minimal. As noted above, users of older codes can easily convert their
arithmetic IF constructs to block IF constructs.
Craig T. Dedo
17130 W. Burleigh Place
Brookfield, WI 53005
(414) 783-5869
E-mail: Craig.Dedo@mixcom.com
X3J3 / 96-007r0 8.2.4, B.2(1)
May 1996, meeting 137: submitted 96-070
------------------------------------------------------------------------------
103
Delete Non-Block DO Constructs
Registered
1
The Fortran 2000 standard should delete the non-block form of the DO
construct (8.1.4.1.2, 8.1.4.2, B.2(2)).
The non-block form of the DO construct is a construct left over from the
1950s and 1960s when little was known about how to write code so that it
would be easy to follow. The high cost of main memory and disk space in
those years also put a high premium on writing Fortran so that it would
occupy as little space as possible. Continued use of this feature encourages
the construction of difficult to follow, spaghetti-style control flow.
The non-block form of the DO construct can be replaced by the block
form of the DO construct, which is an easier to use form of the DO control
structure. The availability of sophisticated, highly reliable code
restructuring tools means that converting non-block DO constructs to block
DO constructs can be done automatically, efficiently, and economically.
Delete section 8.1.4.1.2 and the second paragraph of 8.1.4.2 from the
standard. Move the text of both parts into Annex B as part of section B.1
for the benefit of those vendors who wish to continue supporting the non-block
DO construct. Most likely, the person who does the work will have to
find the other places in the standard where this construct is mentioned.
Minimal. As noted above, users of older codes can easily convert their
non-block DO constructs to block DO constructs.
Craig T. Dedo
17130 W. Burleigh Place
Brookfield, WI 53005
(414) 783-5869
E-mail: Craig.Dedo@mixcom.com
X3J3 / 96-007r0 8.1.4.1.2, 8.1.4.2, B.2(2)
May 1996, meeting 137: submitted 96-070
------------------------------------------------------------------------------
104
Delete Computed GO TO Statements
Registered
1
The Fortran 2000 standard should delete the computed GO TO
statement (8.2.3, B.2.2).
The computed GO TO statement is a construct left over from the 1950s
and 1960s when little was known about how to write code so that it would
be easy to follow. The high cost of main memory and disk space in those
years also put a high premium on writing Fortran so that it would occupy
as little space as possible. Continued use of this feature encourages the
construction of difficult to follow, spaghetti-style control flow.
The computed GO TO statement can be replaced by a CASE construct,
which is an easier to use and more generalized form of the same kind of
control structure. The availability of sophisticated, highly reliable code
restructuring tools means that converting computed GO TO constructs to
CASE constructs can be done automatically, efficiently, and economically.
Delete section 8.2.3 from the standard. Move the text of section 8.2.3
into Annex B as part of section B.1 for the benefit of those vendors who
wish to continue supporting the computed GO TO construct. Most likely,
the person who does the work will have to find the other places in the
standard where this construct is mentioned.
Minimal. As noted above, users of older codes can easily convert their
computed GO TO constructs into CASE constructs.
Craig T. Dedo
17130 W. Burleigh Place
Brookfield, WI 53005
(414) 783-5869
E-mail: Craig.Dedo@mixcom.com
X3J3 / 96-007r0 8.2.3, B.2.2
May 1996, meeting 137: submitted 96-070
------------------------------------------------------------------------------
105
Delete Fixed Form Source
Registered
1
The Fortran 2000 standard should delete fixed form source (3.3.2,
B.2.6).
Fixed form source was designed when the principal machine-readable
input medium for new programs was punched cards. Now that new and
amended programs are generally entered via keyboards using text editing /
word processing software and stored on disk files, it is unnecessary
overhead and error prone, to have to locate positions 6, 7, and 72 on a line.
Free form source was designed expressly for this more modern technology.
Fixed form source can be replaced free form source, which is an easier
to use and more generalized form of source code. The availability of
sophisticated, highly reliable code restructuring tools means that converting
fixed form source to free form source can be done automatically, efficiently,
and economically.
Delete section 3.3.2 from the standard. Move the text of section 3.3.2
into Annex B as part of section B.1 for the benefit of those vendors who
wish to continue supporting fixed form source. Most likely, the person who
does the work will have to find the other places in the standard where this
construct is mentioned.
Minimal. As noted above, a software tool can easily convert from fixed
to free form source.
Craig T. Dedo
17130 W. Burleigh Place
Brookfield, WI 53005
(414) 783-5869
E-mail: Craig.Dedo@mixcom.com
X3J3 / 96-007r0 3.3.2, B.2.6
May 1996, meeting 137: submitted 96-070
------------------------------------------------------------------------------
106
Delete Alternate Return
Registered
1
The Fortran 2000 standard should delete alternate return (12.4,
12.4.1.3, B.2.1).
Alternate return is a construct left over from the 1950s and 1960s when
little was known about how to write code so that it would be easy to follow.
The high cost of main memory and disk space in those years also put a high
premium on writing Fortran so that it would occupy as little space as
possible. Continued use of this feature encourages the construction of
difficult to follow, spaghetti-style control flow.
Alternate return specifiers can be replaced by a status variable which
indicates the completion status of the subroutine and what, if any problems
occurred during its execution. The status variable can be evaluated by
either a CASE construct or block IF construct immediately after the call to
the subroutine. Either of these block structures is an easier to use and
more structured method of evaluating a completion status. The availability
of sophisticated, highly reliable code restructuring tools means that
converting alternate return constructs to CASE constructs or block IF
constructs can be done automatically, efficiently, and economically.
Delete rule R1215 and the last constraint following R1215 from the
standard. Delete section 12.4.1.3 from the standard. Move this text into
Annex B as part of section B.1 for the benefit of those vendors who wish to
continue supporting alternate returns. Most likely, the person who does the
work will have to find the other places in the standard where this construct
is mentioned.
Minimal. As noted above, a software tool can easily convert alternate
return constructs to CASE or block IF constructs.
Craig T. Dedo
17130 W. Burleigh Place
Brookfield, WI 53005
(414) 783-5869
E-mail: Craig.Dedo@mixcom.com
X3J3 / 96-007r0 12.4, 12.4.1.3, B.2.1
May 1996, meeting 137: submitted 96-070
------------------------------------------------------------------------------
107
Delete Statement Functions
Registered
1
The Fortran 2000 standard should delete statement functions (12.5.4,
B.2.3).
Statement functions are subject to a number of non-intuitive restrictions
and are a potential source of error since their syntax is easily confused with
that of an assignment statement.
The internal function is a more generalized form of the statement
function and completely supersedes it.
Delete section 12.5.4 from the standard. Move this text into Annex B as
part of section B.1 for the benefit of those vendors who wish to continue
supporting statement functions. Most likely, the person who does the work
will have to find the other places in the standard where statement functions
are mentioned.
Minimal.
Craig T. Dedo
17130 W. Burleigh Place
Brookfield, WI 53005
(414) 783-5869
E-mail: Craig.Dedo@mixcom.com
X3J3 / 96-007r0 12.5.4, B.2.3
May 1996, meeting 137: submitted 96-070
------------------------------------------------------------------------------
108
Delete DATA Statements Among Executable Statements
Registered
1
The Fortran 2000 standard should delete the appearance of DATA
statements among executable statements (2.3.1, 2.3.2, Table 2.1, B.2.4).
The statement ordering rules of FORTRAN 66, FORTRAN 77, and
Fortran 90 allowed DATA statements to appear anywhere in a program
unit after the specification statements. The ability to position DATA
statements among executable statements is very rarely used, is
unnecessary, and is a potential source of error. It is generally considered
good programming practice to position specification statements such as
DATA statements, before the first executable statement.
DATA statements which now occur among executable statements can
easily be moved into the declarations part of a program without any loss of
functionality or program effectiveness. The availability of sophisticated,
highly reliable code restructuring tools means that moving DATA
statements can be done automatically, efficiently, and economically.
Delete the references to DATA statements among executables in
sections 2.3.1 and 2.3.2 from the standard. Delete the entry in Table 2.1
which shows "DATA statements" to the left of "Executable constructs".
Move this text into Annex B as part of section B.1 for the benefit of those
vendors who wish to continue supporting DATA statements among
executable statements. Most likely, the person who does the work will have
to find the other places in the standard where statement functions are
mentioned.
Minimal.
Craig T. Dedo
17130 W. Burleigh Place
Brookfield, WI 53005
(414) 783-5869
E-mail: Craig.Dedo@mixcom.com
X3J3 / 96-007r0 2.3.1, 2.3.2, Table 2.1, B.2.4
May 1996, meeting 137: submitted 96-070
------------------------------------------------------------------------------
109
Binary stream I/O
Registered
1
Implement a binary stream I/O facility to allow writing and reading
to/from unformatted files without any internal structure.
Traditionally, Fortran I/O facilities have been record oriented.
Fortran 90 has introduced a non advancing I/O facility that provides
for reading and writing partial records in formatted sequential files.
However, thers is a category of files that are definitely not record
oriented. This category is called "binary stream files". These files
are merely constituted of a continuous sequence of storage units,
without any internal structure. Stream files are prevalent in many
operating systems such as Unix, DOS, Windows and OS/2. Also, there
are "industry-standard" file formats that are not record oriented,
such as GIF and TIFF formats for digital images.
Accessing stream files with standard Fortran I/O facilities is often
difficult: unformatted sequential access may fail because the file
contains no record delimiters. Using unformatted direct access is also
awkward since the data cannot be accessed easily with fixed record
lengths. In short, a new file access is needed.
Many vendors have already extended their compilers to provide
this facility by allowing "binary" or "transparent" file access
methods, showing a need for standardization.
The feature could be implemented without introducing any new statements:
only new keywords and options in OPEN, READ, WRITE, and INQUIRE
are needed.
A binary stream file consists of a sequence of processor-dependant
storage units. These units must be the same to those used to define
the record length of an unformatted direct file. The storage units
are numbered from 1 to n, n being the last unit written. Two concepts
are present in a stream file. A file position pointer is used to locate
the next storage unit to be read or written. Following the last storage
unit of the file, there is an end-of-file marker that may physically
exist or not. This marker can be checked in a READ statement by END
or IOSTAT specifiers. The file position pointer may point to the
end-of-file marker.
Opening a binary stream file could be done by simply adding
ACCESS='STREAM' in the OPEN statement. The POSITION specifier
is valid for these files.
Binary stream I/O should work following in an hybrid fashion between
sequential and direct access. Sequential access should be done by
using the syntax of unformatted sequential READ and WRITE, except
that the unit is connected to a binary stream file. The file position
pointer is moved by the amount of data storage units transferred
by each READ or WRITE statements executed. Random access should be
provided by adding a POS=location specifier to the READ or WRITE
statements. Mixed access should be allowed for the same unit.
When a WRITE statement overwrites a portion of a stream file,
only the amount of storage tranferred should replace the existing
locations; the remaining storage units should remain intact
(in the contrary of conventional unformatted sequential WRITEs).
READ and WRITE statement with POS specifiers but with an empty
I/O list merely move the pointer inside the file. In the case
of a WRITE statement, if the position pointer is moved with
the POS specifier beyond the end-of-file marker, the gap is filled
with unitialized data.
The BACKSPACE statement should be disallowed for such files, since
there is no record delimiters.
The ENDFILE statement is used to truncate the binary stream file
at the current file pointer position.
New specifiers should be added to the INQUIRE statements.
In particular, a CURRPOS specifier to obtain the current position
of the pointer, and a FILESIZE specifier that returns the amount
of units written to the file. The ACCESS specifer should also be
extended to allow ACCESS='STREAM' to be returned.
None. This new feature can be blended easily with the existing I/O
facilities, as described above.
The new feature affects the OPEN, READ, WRITE, and INQUIRE statements.
The ENDFILE statement will acquire a new functionality.
Implementing this feature should be very easy, since a similar
functionality is already provided as an extension by many vendors.
The implementation of the FILESIZE specifier in the INQUIRE statement
shouldn't also cause problems since virtually all operating systems
provide a facility to obtain the size of a file in bytes or words.
Jean Vezina (phone: (514) 256-6698; email: patrjacq@abl.ca)
6292 Villanelle
St-Leonard, Quebec
Canada
H1S 1W1
email received on 23-Apr-1996
------------------------------------------------------------------------------
110
In-line procedures
PROCEDURE, IN-LINE
Registered
1
Provide a means for a programmer to specify that the desired implementation
of that procedure is by in-line expansion of the code at the point of
reference to the procedure rather than branch to and return from a single
code image.
In almost any programming method involving significant data abstraction
(including, but not limited to, object-oriented programming), there tend
to be a number of procedures which bridge levels of abstraction, but which
do little "real" work. In-line expansion of such procedures significantly
reduces their cost. In addition, there tends to increased opportunities for
optimization in the calling scoping unit. [The value of in-line expansion
of statement functions is well known and an example of what this requirement
would provide in a somewhat broader context.]
Allow a keyword such as INLINE on the procedure header.
Since we cannot reasonably directly require in-line expansion, the semantics
of this keyword are to prohibit obstacles to in-line expansion:
o The INLINE keywords would be permitted on module procedures and internal
procedures, but not external procedures or interface bodies.
o A procedure could not be both INLINE and RECURSIVE.
o An INLINE procedure could not be associated with a dummy procedure (nor
with a pointer to a procedure, if we add those).
We would have to leave it to market pressure to actually ensure that INLINE
procedures are expanded in-line.
The impact on the document should be well localized.
Impact on existing processors will vary: A processor wishing to meet the
literal requirements (without actually doing in-line expansion) could do
so with a small amount of syntax checking.
Typically, existing processors already do at least some in-line expansion
(for statement functions) and some do in-line expansion of arbitrary
procedures, but it seems likely that it will vary from processor whether
the existing in-line expansion infrastructure is sufficient for doing
the kind of expansion expected in this requirement.
Kurt W. Hirchert, hirchert@ncsa.uiuc.edu
29 April 96: submitted
------------------------------------------------------------------------------
111
Local declaration block
SCOPING
Registered
1
Provide a mechanism for declaring entities with a more limited scope than
an entire procedure or main program.
When a program requires an explicitly named temporary, the nature of that
entity is clearer to both the compiler and human readers if its scope can
be limited.
A SCOPE ... END SCOPE construct with usual nesting rules relative to other
block constructs.
Impact on the document should be localized.
Impact on existing processors involves stealing heavily from the
implementation of internal procedures.
Kurt W. Hirchert, hirchert@ncsa.uiuc.edu
29 April 96: submitted
------------------------------------------------------------------------------
112
"Clean up" conformance rules
CONFORMANCE
Registered
1
Review conformance rules with an eye towards making them more regular,
easier to understand, more useful, etc.
The standard would be easier to understand, more useful, etc.
Specific issues I would suggest looking at include the following:
o If a Fortran program uses a procedure defined by means other than
Fortran, it can still be a standard-conforming program. However,
if the vendor changes that procedure to an intrinsic procedure to
make it more efficient, the program becomes nonconforming. We
should try to treat these cases similarly.
o If a format is written as a FORMAT statement, the processor is required
to be able to check it for correctness, but if it is written as
a CHARACTER constant, the processor is not.
o If we should separate the concepts of a program which is standard
conforming in form (i.e., on a static basis) from whether or not
the execution of that program conforms.
Much of this could be done with only localized changes to the document,
but identifying the difference between static and dynamic requirements
in the standard might be more widespread.
Most of this should have very limited impact on existing processors. The
obvious exception would be a requirement that processors check the
correctness of formats expressed as character constant expressions.
Kurt W. Hirchert, hirchert@ncsa.uiuc.edu
29 April 96: submitted
------------------------------------------------------------------------------
113
Allow MERGE in constant expressions
MERGE, EXPRESSIONS, PARAMETER, CONSTANT
Registered
1
Modify the limitations on initialization expressions in some way that would
allow the MERGE intrinsic to be used.
It is possible to work around the lack of MERGE, at least for integer
relations, but the result tends to be obscure in the extreme.
The document changes will likely be difficult to formulate, but well
localized. The changes to existing processors should be similarly localized.
Kurt W. Hirchert, hirchert@ncsa.uiuc.edu
29 April 96: submitted
------------------------------------------------------------------------------
114
Extend ALLOCATE to specify non-KIND type parameters
ALLOCATABLE, POINTER, ALLOCATE, CHARACTER,
PARAMETERIZED DERIVED TYPES
Registered
1
Extend the ALLOCATE statement to allow specification of type parameters.
Allow POINTER or ALLOCATABLE to be used with declaration forms used to
"assume" type parameters.
In the current standard, this affects only the LEN parameter of the
CHARACTER type, but it would extended to parameterized derived types.
This should be an obvous part of parameterized derived types. E.g.,
if one creates a parameterized MATRIX type, it should be obvious that
one might want an allocatable matrix for much the same reasons one wants
allocatable arrays.
The ISO varying string module demonstrated the difficulty of having to
allocate a character array when what you really needed was a string
whose length you could control.
CHARACTER(*), ALLOCATABLE :: C
...
ALLOCATE ((LEN=L)C)
Kurt W. Hirchert, hirchert@ncsa.uiuc.edu
29 April 96: submitted
------------------------------------------------------------------------------
115
Mixed function/subroutine generics
GENERIC
Registered
1
Allow generic names (but not operators or assignment) to apply to functions
and subroutines at the same time, with function vs. subroutine being an
added way to distinguish two specific procecures.
Review whether intrinsics such as MVBITS, PACK, and UNPACK should have both
function and subroutine interfaces.
Subroutine interfaces can be more efficient if only part of what could be
modified will actually be modified in a given call. Functions are more
suited for allowing operations to be composed. Allowing both interfaces
to be provided avoids the necessity of prejudging which issue is going to
be most important in the programs of people using the interface.
Impact on both the document and existing processors should be localized.
(Some existing processors already have generic intrinsics that mix
functions and subroutines.)
Kurt W. Hirchert, hirchert@ncsa.uiuc.edu
29 April 96: submitted
------------------------------------------------------------------------------
116
"Simultaneous" assignment
Registered
1
Provide some mechanism for more general "simultaneous" assignment, i.e.
evaluating all "right hand sides" before modifying the "left hand sides".
It is a common problem to have a set of variables that must be updated
based on their collective current state. Introducing explict temporary
variables to achieve this obscures the logic and may produce less efficient
code than what a compiler can do with architecture-specific temporary
generation.
I can think of several very different notation approaches. One would be
to allow derived type "pseudo-variables" on the left hand side of an
assignment (making use of the simultaneity within a derived type assignment):
SWAP(X,Y)=SWAP(Y,X)
Another would be to try to extend the simultaneity of the FORALL statement:
FORALL(I=1:2)
SELECT CASE(I)
CASE(1); N=M
CASE(2); M=N+M
END SELECT
END FORALL
Yet another would be to create a new construct for this:
SIMUL
X=X*COS_THETA-Y*SIN_THETA
Y=X*SIN_THETA+Y*COS_THETA
END SIMUL
The impact on the document is likely to be localized. Impact on existing
processors appears potentially significant.
Kurt W. Hirchert, hirchert@ncsa.uiuc.edu
29 April 96: submitted
------------------------------------------------------------------------------
117
Use of the SIZE= Keyword
Registered
1
Allow the use of the SIZE= specifier for both advancing and non-advancing
I/O.
Fortran 90 allows the use of the SIZE= specifier only for non-advancing
I/O. Informal conversations at X3J3 meetings in 1994 suggested that the
developers of the Fortran 90 standard thought that it would be useful mainly
for non-advancing I/O. This is unduly restrictive; users should be able to
use the SIZE= specifier both in advancing and non-advancing I/O.
This could be accomplished by making minor edits to sections 9.2.1.3.1,
9.4.1, and 9.4.1.9.
Minimal. Many Fortran compilers already have some other method for
obtaining the size of the record when using advancing I/O.
Craig T. Dedo
Elmbrook Computer Services
17130 W. Burleigh Place
Brookfield, WI 53005
(414) 783-5869
E-mail: Craig.Dedo@mixcom.com
X3J3 / 96-007r0 9.2.1.3.1, 9.4.1, 9.4.1.9
May 1996, meeting 137: submitted 96-nnn
------------------------------------------------------------------------------
118
Internal File Data Type
Registered
1
Allow the data objects of any KIND of CHARACTER data type that is
defined on the processor to be used as internal files.
Fortran 90 requires that internal files must be of default CHARACTER
type. This is an unnecessary restriction. In the next 10-12 years (i.e., the
expected useful life of the Fortran 2000 standard), I expect that the use of
multi-byte character sets such as Unicode (a.k.a. ISO 10646) will grow to be
of substantial importance in character manipulation. Fortran should
anticipate this development and be prepared to handle it. In addition, not
allowing all KINDs of character variables as internal files creates an
irregularity.
This could be accomplished by making minor edits to sections 9.2.2.1, 9.3,
and 9.4.2.
Minimal. Any Fortran processor which supports different KINDs of
CHARACTER data types already has to deal with issues such as
representation and translation.
Craig T. Dedo
Elmbrook Computer Services
17130 W. Burleigh Place
Brookfield, WI 53005
(414) 783-5869
E-mail: Craig.Dedo@mixcom.com
X3J3 / 96-007r0 9.2.2.1, 9.3, 9.4.2
May 1996, meeting 137: submitted 96-nnn
------------------------------------------------------------------------------
119
Internal Files and List-Directed Formatting
Registered
1
Add a note to the standard which explicitly states that starting with
Fortran 90, it is permitted to do list-directed I/O on internal files.
A frequently asked question about Fortran 90 is whether it is permitted to
perform list-directed I/O on internal files. FORTRAN 77 did not permit this
practice, but Fortran 90 removed this restriction. Unfortunately, the
frequency of the question indicates that many users still doubt whether this
is permitted. A note in the standard should make this point clear.
Create a note at the end of section 9.2.2.2 which would read something
along the lines of, "Starting with Fortran 90, it is permissible to perform
list-directed I/O on internal files."
None. This is mostly an editorial matter. Some vendors may wish to
change their documentation.
Craig T. Dedo
Elmbrook Computer Services
17130 W. Burleigh Place
Brookfield, WI 53005
(414) 783-5869
E-mail: Craig.Dedo@mixcom.com
X3J3 / 96-007r0 9.2.2.2
May 1996, meeting 137: submitted 96-nnn
------------------------------------------------------------------------------
120
Named Scratch Files
Registered
1
Allow the user to specify a file name if a file is opened with
STATUS="SCRATCH".
Fortran 90 does not allow the user to name scratch files. We should lift
this restriction. Allowing the programmer to name scratch files can be
useful, especially if the program crashes. Not allowing the programmer to
name a file in this one case is an unnecessary irregularity. since there is
legacy code which has STATUS="SCRATCH" without a FILE= specifier, the best
solution is to allow the optional use of FILE= with STATUS="SCRATCH".
This could be accomplished by making minor changes to section 9.3.4.
Minimal. Adding this capability should not be very difficult to implement.
Craig T. Dedo
Elmbrook Computer Services
17130 W. Burleigh Place
Brookfield, WI 53005
(414) 783-5869
E-mail: Craig.Dedo@mixcom.com
X3J3 / 96-007r0 9.2.2.2
May 1996, meeting 137: submitted 96-nnn
------------------------------------------------------------------------------
121
Behavior of OPEN with STATUS="UNKNOWN"
Registered
1
If the OPEN statement specifies that a file is opened with
STATUS="UNKNOWN", the standard should specify that if the file exists, it
is opened as if STATUS="OLD", and if the file does not exists, it is opened as
if STATUS="NEW".
Fortran 90 and 95 leave this behavior as processor dependent. This
definition interferes with portability. It also requires the user to
anticipate the processor's behavior instead of relying on a known, standard
behavior. This is an unnecessary irregularity. The recommended change to
the standard behavior is already a popular implementation of OPEN with
STATUS="UNKNOWN". The DEC (VMS, Unix, and NT), IBM AIX, and Lahey Fortran
compilers already use this implementation.
This could be accomplished by making minor changes to section 9.3.4.2.
This change should not pose any serious implementation problems. I
expect that the instances of actual incompatibility will be few. Programmers
should be able to easily resolve any such conflicts. Implementors should be
able to easily and inexpensively change their implementations to conform to
the new rule, which is equivalent to the following code:
CHARACTER (LEN=250) :: FILENAME
INTEGER :: LUN
LOGICAL :: LEXIST
! Define the values of LUN and FILENAME somewhere prior to opening the
file.
INQUIRE (FILE=FILENAME, EXIST=LEXIST)
IF (LEXIST) THEN
OPEN (LUN, FILE=FILENAME, STATUS="OLD")
ELSE
OPEN (LUN, FILE=FILENAME, STATUS="NEW")
END IF
Craig T. Dedo
Elmbrook Computer Services
17130 W. Burleigh Place
Brookfield, WI 53005
(414) 783-5869
E-mail: Craig.Dedo@mixcom.com
X3J3 / 96-007r0 9.3.4.2
May 1996, meeting 137: submitted 96-nnn
------------------------------------------------------------------------------
122
Action of STATUS="REPLACE" with Multiple Version Files
Registered
1
If an operating system or file system supports files with multiple version
numbers, opening a file with STATUS="REPLACE" should create a new file
with the next available version number or version designator.
The standard is silent on what should happen if a file is opened with
STATUS="REPLACE" and the operating system or a file system supported by the
operating system supports multiple version files. Currently, the Fortran 95
DIS says, "If REPLACE is specified and the files does exist, the file is
deleted, a new file is created with the same name, and the status is changed
to old." This appears to imply that on a system that supports multiple
versions of files, the old version should be deleted and an empty file with
the same version number created in its place. However, close consideration
of the text does not make it clear whether:
(1) the old version should be deleted or,
(2) a new file created with he next available version designator.
Here is an example. There is an existing file COMPLEX_FILE.DAT;3,
where the number following the semicolon is the version designator. A Fortran
program opens the file using STATUS="REPLACE". Does the Fortran
program delete COMPLEX_FILE.DAT;3 and re-create it as empty? Or, does
the Fortran program create a new version, e.g., COMPLEX_FILE.DAT;4?
I believe that the more useful choice is to create a new file with the next
available version designator. Choosing this option would preserve the
purpose of multiple versions of files, i.e., to make it easier for users of
all kinds to recover from disastrous mistakes.
For reasons of clarity, regularity, and portability, we should rule on this
issue rather than leaving it as processor dependent.
Some may argue that few operating systems or file systems offer multiple
versions of files right now and therefore this issue is irrelevant for the
vast majority of Fortran programmers. While multiple version file systems
may be few, this feature of a file system may greatly increase in popularity
during the life of the Fortran 2000 standard., which may be as late as 2012.
Therefore, the issue may be very relevant for a significant fraction of
Fortran programmers during the life of the Fortran 2000 standard.
This could be accomplished by making minor changes to section 9.3.4.2.
Minimal. Adding this capability should not be very difficult to implement.
Craig T. Dedo
Elmbrook Computer Services
17130 W. Burleigh Place
Brookfield, WI 53005
(414) 783-5869
E-mail: Craig.Dedo@mixcom.com
X3J3 / 96-007r0 9.3.4.2
May 1996, meeting 137: submitted 96-nnn
------------------------------------------------------------------------------
123
BACKSPACE with List-Directed and Namelist Formats
Registered
1
Remove the restriction which prohibits backspacing over records written
using list-directed and namelist formatting.
There appears to be very little, if any, difference between records written
using formatted I/O and those using list-directed or namelist I/O. Therefore,
this appears to be an unnecessary restriction. Fortran 2000 should remove
this restriction.
This could be accomplished by making minor changes to section 9.5.1
Minimal. Adding this capability should not be very difficult to implement.
Craig T. Dedo
Elmbrook Computer Services
17130 W. Burleigh Place
Brookfield, WI 53005
(414) 783-5869
E-mail: Craig.Dedo@mixcom.com
X3J3 / 96-007r0 9.5.1
May 1996, meeting 137: submitted 96-nnn
------------------------------------------------------------------------------
124
NEXTREC= Specifier in the INQUIRE Statement
Registered
1
Fortran 2000 should allow the use of the NEXTREC= specifier for both
direct access and sequential access files.
The Fortran 95 DIS only allows the use of the NEXTREC= specifier only
for direct access files. This is an unnecessary irregularity.
This could be accomplished by making minor changes to section 9.6.1.14
Minimal. Adding this capability should not be very difficult to implement.
Craig T. Dedo
Elmbrook Computer Services
17130 W. Burleigh Place
Brookfield, WI 53005
(414) 783-5869
E-mail: Craig.Dedo@mixcom.com
X3J3 / 96-007r0 9.6.1.14
May 1996, meeting 137: submitted 96-nnn
------------------------------------------------------------------------------
125
ADVANCE="NO" Specifier and Prompting
Registered
1
Fortran 2000 should guarantee that the use of the ADVANCE="NO"
specifier in I/O statements can be used by programmers to implement a
genuine prompting capability.
Interpretations of the Fortran 90 standard indicate that the of the
ADVANCE="NO" specifier in I/O statements does not guarantee that
programmers can use a combination of such I/O statements in order to
implement a genuine prompting capability.
It is my belief that most users expect ADVANCE="NO" I/O statements to
provide a prompting capability. This difference creates a gap between what
users expect and what the current standard actually provides. The existence
of this gap contributes to the image that Fortran has of being a "Stone Age"
relic. This situation should be corrected.
Although the growing popularity of windowing systems reduces the
severity of this gap, I expect that a need for a genuine prompting capability
will exist for the life of Fortran 2000.
This could be accomplished by making minor changes to sections 9.2.1.3.1
and 9.4.1.8.
Minimal. Adding this capability should not be very difficult to implement.
Craig T. Dedo
Elmbrook Computer Services
17130 W. Burleigh Place
Brookfield, WI 53005
(414) 783-5869
E-mail: Craig.Dedo@mixcom.com
X3J3 / 96-007r0 9.2.1.3.1, 9.4.1.8
May 1996, meeting 137: submitted 96-nnn
------------------------------------------------------------------------------
126
Editorial Changes for Chapter 9
Registered
1
Fortran 2000 should include any of the editorial changes to Chapter 9 that
I recommended in my paper 94-375 at the November of 1994 meeting of X3J3,
and which did not make it into Fortran 95. Many of these changes were not
included in Fortran 95 due to the heavy schedule of other editorial work that
had to be done in order to keep Fortran 95 on schedule.
I recommended these editorial changes in order to make Chapter 9 a much
more coherent and well organized part of the document. Making these changes
would make Chapter 9 much more readable and easier to use.
This could be accomplished by making the recommended changes
throughout Chapter 9.
There would be no impact on the technical content of Fortran 2000. There
could be moderate to extensive editorial work required. X3J3 should ask the
Fortran 2000 Project Editor to provide an estimate of the impact.
Since some of the recommendations reorganize subsections of Chapter 9,
it would be necessary to check other parts of the document to see if
cross-references to the reorganized parts need to be changed.
Craig T. Dedo
Elmbrook Computer Services
17130 W. Burleigh Place
Brookfield, WI 53005
(414) 783-5869
E-mail: Craig.Dedo@mixcom.com
X3J3 / 94-375, "Editorial Changes for 007r3 Chapter 9"
May 1996, meeting 137: submitted 96-nnn
------------------------------------------------------------------------------
127
CPU_TIME Enhancements
Registered
1
The CPU_TIME intrinsic subroutine should be extended to include
additional arguments and to make the TIME argument optional. The
additional arguments would allow for the inquiry and measurement of user
time, system time, and the minimum unit of time in the processor's
measurement system.
It is possible that a precise definition of CPU_TIME will evolve as an ISO
standard in the near future. This capability would allow the Fortran standard
to anticipate and keep up with any such development.
If these extensions become part of CPU_TIME, the TIME argument may
not be relevant in all calls to CPU_TIME.
One method would be to use the following interface:
SUBROUTINE CPU_TIME (TIME, USER, SYSTEM, DELTA)
REAL, OPTIONAL, INTENT (OUT) :: TIME ! Processor time
REAL, OPTIONAL, INTENT (OUT) :: USER ! User time
REAL, OPTIONAL, INTENT (OUT) :: SYSTEM ! System time
REAL, OPTIONAL, INTENT (OUT) :: DELTA ! Minimum time increment
This feature would have no impact on existing implementations. The cost
to vendors to implement this feature should be very low.
ISO/IEC 1539:1996 (E) 13.14.25 (a.k.a. X3J3/95-007r1)
X3J3/95-259
X3J3/95-268
Craig Dedo On behalf of Jens Bloch Helmers
Elmbrook Computer Services Det Norske Veritas Research AS
17130 W. Burleigh Place
Brookfield, WI 53005 N-1322 Hoevik
USA NORWAY
+1 (414) 783-5869 +47 (67) 57 75 31
E-mail: Craig.Dedo@mixcom.com E-mail: helm@vr.dnv.no
------------------------------------------------------------------------------
128
$ Character in Symbolic Names
Registered
1
Fortran 2000 should include the use of $ as a permissible character for
Fortran symbolic names for such things as arrays, variables, COMMON blocks,
modules, etc.
The $ character is a popular extension. David Levine's survey of
extensions found that it is included in the Cray, DEC, EPC, HP, IBM, and
Lahey compilers. Names contain the $ character are often used to name many
operating system functions and subroutines. Including this character in the
standard will make it easier to have Fortran programs use such routines.
Change the list of permissible characters in symbolic names in section 3.1.1
so that $ is in the list.
Minimal.
Craig T. Dedo
Elmbrook Computer Services
17130 W. Burleigh Place
Brookfield, WI 53005
(414) 783-5869
E-mail: Craig.Dedo@mixcom.com
ISO/IEC 1539:1991 (E) 3.1.1
May 1996, meeting 137: submitted 96-074
------------------------------------------------------------------------------
129
Standardized Character Sets Including ASCII
Registered
1
Fortran 2000 should require a compiler to provide full support for the 7-bit
ASCII character set. This would be the ANSI definition, WITHOUT the
National character Set Options. This would mean that 7-bit ASCII would be a
required KIND on a standard conforming compiler. It would not be necessary
for a processor to offer 7-bit ASCII as the default character set or as the
KIND type for Fortran source statements. However, a processor would be
required to include in the Fortran character set all of the characters in
positions 32 - 126 in the ASCII table.
In addition, Fortran 2000 should require support of the ASCII character
set interpreted according to the latest ISO C language standard. This C
language character set would have its own unique KIND number.
As an extension of this requirement, the standard could also require
support for the ISO Latin-1 character set and possibly other ISO character
sets.
Development of this requirement should follow the recommendations of the
ISO TR 10176, Guidelines for the Preparation of Programming Language
Standards.
This requirement would greatly increase portability of code, both from one
platform to another and from one country to another. Although workarounds
exist, they usually are difficult and costly to use. The time and effort of
application developers should be spent solving their problems rather than
fighting the limitations of the programming language.
The increasing use of multiple platforms for software development and the
increasingly international character of general business and trade over time
means that this functionality gets more desirable each year. Use of a wider
variety of characters in ordinary printed materials is becoming far more
widespread than previously. This means that the kluges of the past are
becoming untenable. It also means that portability is becoming far more
important than it used to be.
If this issue is ignored, it will become increasingly difficult and costly
to engage in workarounds.
I do not believe that standards bodies can ignore any longer the need for
some standardized character sets in programming languages. The earlier such
fundamental issues are standardized, the less costly and difficult
implementation will be.
The language of sections 3.1 and 4.3.2.1 can be modified to require support
of the selected ISO character sets. This should be quite simple by making
reference to the necessary ISO standards.
This would require vendors to support several additional KINDs for
CHARACTER data types. It should not be very difficult or costly for vendors
to implement this requirement. Some changes may be required to compilers
in the case of vendors who support ASCII according to the C language
conventions.
This requirement may involve considerable debate in the standards making
process in order to make a high quality selection of required character sets.
Craig T. Dedo
Elmbrook Computer Services
17130 W. Burleigh Place
Brookfield, WI 53005
(414) 783-5869
E-mail: Craig.Dedo@mixcom.com
ISO/IEC 1539:1991 (E) 3.1, 4.3.2.1
May 1996, meeting 137: submitted 96-074
------------------------------------------------------------------------------
130
TAB Character in Fortran Source
Registered
1
Fortran 2000 should allow the use of TAB characters in free source form.
The TAB character should be interpreted as if it was one blank character.
This is a popular extension and often makes the source code easier to read.
Several vendors, including Cray, DEC, EPC, HP, IBM, and Lahey support this
feature.
Add TAB to the list of characters in the Fortran character set. Write a
rule requiring that TAB be treated the same as space.
Minimal.
Craig T. Dedo
Elmbrook Computer Services
17130 W. Burleigh Place
Brookfield, WI 53005
(414) 783-5869
E-mail: Craig.Dedo@mixcom.com
ISO/IEC 1539:1991 (E) 3.1
May 1996, meeting 137: submitted 96-074
------------------------------------------------------------------------------
131
BYTE Data Type
Registered
1
Fortran 2000 should include support for the BYTE data type, defined an a
sequence of 8 bits. The BYTE data type could be used for very small signed or
unsigned integers, for bit masks, and for 8 bit characters. It could be the
TARGET of a POINTER assignment and used in building derived types. It could
be storage associated with any other data type using the EQUIVALENCE
statement. Any kind of data should be able to be assigned to a BYTE data
type or a BYTE array.
The BYTE data type is very useful for building data structures used to
access operating system data structures. It also could be used for building
various derived types that either are cumbersome or impossible to build using
the currently available data types. BYTE arrays can also be used for various
types of low level data manipulation which is difficult to do using the
current data types. The implementation of the BYTE data type in compilers
from Cray, DEC, EPC, HP, IBM, Lahey, and Sun attests to the popularity and
usefulness of the BYTE data type.
This feature should be implemented in the same manner as the BYTE data
type is implemented in the compilers mentioned above. The syntax should
follow the model used for current intrinsic data types.
There should be little impact to current processors. Vendors who do not
support BYTE should find this easy to implement.
Craig T. Dedo
Elmbrook Computer Services
17130 W. Burleigh Place
Brookfield, WI 53005
(414) 783-5869
E-mail: Craig.Dedo@mixcom.com
ISO/IEC 1539:1991 (E) 4.3.2, 5.1, 5.1.1
May 1996, meeting 137: submitted 96-074
------------------------------------------------------------------------------
132
Automatic or Dynamic Data Objects
Registered
1
Fortran 2000 should provide a means of declaring that data objects
definitely disappear when they go out of scope.
In the Fortran 90 standard and the Fortran 95 DIS, it is processor
dependent what happens to data objects if they do not have the SAVE
attribute. Some processors make all data objects static while others make
non-SAVE data objects dynamic (a.k.a. automatic). There should be a way for
an application developer to declare that a data object definitely disappears
when it goes out of scope. This would give the application developer more
control on exactly how data objects are declared and used. Most other
popular languages have this capability.
This feature could be implemented by defining another data object
attribute (5.1.2) and statement (5.2). Probably the best keywords would be
either DYNAMIC or AUTOMATIC. The EPC, HP, IBM, and Sun Fortran
compilers use the AUTOMATIC keyword as an extension to Fortran.
This feature should not cost a great deal to implement. Since its
equivalent appears in most other languages and this feature is already an
extension to several Fortran compilers, the implementation methods are
already well known.
Craig T. Dedo
Elmbrook Computer Services
17130 W. Burleigh Place
Brookfield, WI 53005
(414) 783-5869
E-mail: Craig.Dedo@mixcom.com
ISO/IEC 1539:1991 (E) 5.1.2, 5.2
May 1996, meeting 137: submitted 96-074
------------------------------------------------------------------------------
133
Piecewise Construction of Named Constant Arrays
Registered
1
Fortran 2000 should allow a programmer to construct arrays which are
named constants (i.e., have the PARAMETER attribute) in several statements.
The current Fortran 90 standard and Fortran 95 DIS require that arrays
which are named constants be completely constructed in the same statement
in which they are declared. This restriction places a stringent limit on the
length of such an array. It also increases program complexity and decreases
program understandability since such declarations sometimes require lengthy
declaration statements with many continuation lines.
According to Jens Bloch Helmers of Det Norske Veritas Research, large
sized arrays of named constants are useful in certain fields of research and
engineering.
One possible method would be to remove the restriction that named
constants need to be initialized in the same statement in which they are
declared. Then the application developer could use successive PARAMETER
statements to initialize successive parts of the array.
It is difficult to estimate how much effort it would take for vendors to
implement this requirement.
Craig T. Dedo
Elmbrook Computer Services
17130 W. Burleigh Place
Brookfield, WI 53005
(414) 783-5869
E-mail: Craig.Dedo@mixcom.com
ISO/IEC 1539:1991 (E) 5.1, 5.2.1.2, 5.2.9
May 1996, meeting 137: submitted 96-074
------------------------------------------------------------------------------
134
Period as Derived Type Delimiter
Registered
1
Fortran 2000 should recognize the use of the period (.) as a delimiter in
derived types in addition to the percent sign (%).
The main reason is aesthetic. The period in this context is easier to
read. This is shown by the choice of the period as the derived type delimiter
in most other languages that support derived types, including Pascal, C, and
C++.
Change the rule to allow either a period or percent sign as the delimiter.
This feature may cause a conflict with user-defined operators. This
conflict could be resolved by defining one to have a higher precedence than
the other. Implementation costs should be moderate at worst. There may need
to be some extra syntax checking.
Craig T. Dedo
Elmbrook Computer Services
17130 W. Burleigh Place
Brookfield, WI 53005
(414) 783-5869
E-mail: Craig.Dedo@mixcom.com
ISO/IEC 1539:1991 (E) 6.1.2
May 1996, meeting 137: submitted 96-074
------------------------------------------------------------------------------
135
Floating Point Operations in Initialization Expressions
Registered
1
Fortran 2000 should allow the use of any floating point data objects,
functions, and operations in an initialization expression. I.e., the Fortran
2000 standard should remove all current restrictions on the use of floating
point data objects, functions, and operations in initialization expressions.
The current Fortran 90 standard and the Fortran 95 DIS restricts the use of
floating point data objects in initialization expressions. It does not allow
the use of floating point exponents nor the use of floating point functions.
These limits unnecessarily restrict the freedom of the application developer.
If these restrictions are removed, the application developer can initialize
data objects using more intuitive and straightforward methods. Thus, this
feature would increase programmer productivity.
The current restrictions may have been necessary in earlier days when
machine time was extremely expensive and computing complex floating point
operations would have greatly increased the time required for compilation.
Today, the cost of programmer time greatly exceeds the cost of machine time.
This trend is expected to continue during the expected useful life of the
Fortran 2000 standard (1996-2012).
Remove the current restrictions in section 7.1.6.1.
Compilers could call the relevant run-time math library if necessary in
order to evaluate complex floating point operations or functions. Such
capabilities are already available since at run time it is necessary to
perform such operations.
Minimal. Some Fortran compilers already allow this feature as an
extension. It would be useful to ask implementors what unforseen
complexities could result from this feature.
Craig T. Dedo
Elmbrook Computer Services
17130 W. Burleigh Place
Brookfield, WI 53005
(414) 783-5869
E-mail: Craig.Dedo@mixcom.com
ISO/IEC 1539:1991 (E) 7.1.6.1
May 1996, meeting 137: submitted 96-074
------------------------------------------------------------------------------
136
Indirection and Address Operators and/or Functions
Registered
1
Fortran 2000 should provide operators and/or functions for obtaining the
address of a data item and the value of an item given its address.
Very often, the use of operating systems procedures is made easier if this
functionality is available. This capability could also be used for
applications in which fine control of memory is necessary.
One possibility is to use the number sign (#) as the address operator and
the commercial at sign (@) as the indirection (i.e., value-at-address)
operator. Another option is to standardize the LOC() or %LOC() function.
Unfortunately, there is no widely used function name for the inverse (i.e.,
value-at-address) function.
Implementation costs should be quite low. These capabilities are
implemented in many other languages.
Craig T. Dedo
Elmbrook Computer Services
17130 W. Burleigh Place
Brookfield, WI 53005
(414) 783-5869
E-mail: Craig.Dedo@mixcom.com
ISO/IEC 1539:1991 (E) 7.2
May 1996, meeting 137: submitted 96-074
------------------------------------------------------------------------------
137
BLOCKSIZE= Specifier on OPEN
Registered
1
Fortran 2000 should support the BLOCKSIZE= specifier on the OPEN
statement, as implemented as an extension in several Fortran compilers.
Many file systems allow the user to specify the size of I/O transfer blocks,
i.e., the physical record size of data transfers. This could be used by
knowledgeable programmers to optimize I/O operations.
This could be implemented as a BLOCKSIZE=numeric-expression keyword in the
OPEN statement. If absent, the block size would use a processor-dependent
default value. If the operating system or file system does not support
user-specified block sizes, the use of this keyword would have no effect.
Minimal. This keyword is already supported on several popular compilers.
Craig T. Dedo
Elmbrook Computer Services
17130 W. Burleigh Place
Brookfield, WI 53005
(414) 783-5869
E-mail: Craig.Dedo@mixcom.com
ISO/IEC 1539:1991 (E) 9.3.4
May 1996, meeting 137: submitted 96-074
------------------------------------------------------------------------------
138
BUFFERCOUNT= Specifier on OPEN
Registered
1
Fortran 2000 should support the BUFFERCOUNT= specifier on the OPEN
statement, as implemented as an extension in several Fortran compilers.
Many file systems allow the user to specify the number of I/O buffers. This
could be used by knowledgeable programmers to optimize I/O operations.
This could be implemented as a BUFFERCOUNT=numeric-expression keyword in
the OPEN statement. If absent, the buffer count would use a
processor-dependent default value. If the operating system or file system
does not support user-specified buffer counts, the use of this keyword would
have no effect.
Minimal. This keyword is already supported on several popular compilers.
Craig T. Dedo
Elmbrook Computer Services
17130 W. Burleigh Place
Brookfield, WI 53005
(414) 783-5869
E-mail: Craig.Dedo@mixcom.com
ISO/IEC 1539:1991 (E) 9.3.4
May 1996, meeting 137: submitted 96-074
------------------------------------------------------------------------------
139
CARRIAGECONTROL= Specifier on OPEN
Registered
1
Fortran 2000 should support the CARRIAGECONTROL= specifier on the
OPEN statement, as implemented as an extension in several Fortran
compilers.
Many Fortran processors allow the user to specify the kind of carriage
control which is used on the file during I/O operations. This specifier would
allow the programmer to specify the carriage control rather than being
required to use the carriage control which is mandated by the Fortran compiler
for that particular kind of file.
This could be implemented as a CARRIAGECONTROL=character-expression keyword
in the OPEN statement. The character-expression would take one of the
following values:
FORTRAN Specifies traditional Fortran interpretation of the first
character.
LIST Process with single spacing between records.
NONE Do not use any carriage control processing.
Minimal. This keyword is already supported on several popular compilers.
Craig T. Dedo
Elmbrook Computer Services
17130 W. Burleigh Place
Brookfield, WI 53005
(414) 783-5869
E-mail: Craig.Dedo@mixcom.com
ISO/IEC 1539:1991 (E) 9.3.4
May 1996, meeting 137: submitted 96-074
------------------------------------------------------------------------------
140
INITIALSIZE= and EXTENDSIZE= Specifiers on OPEN
Registered
1
Fortran 2000 should support the INITIALSIZE= and EXTENDSIZE=
specifiers on the OPEN statement, as implemented as an extension in several
Fortran compilers.
Many file systems allow the user to specify the initial size and extend
sizes of file. This could be used by knowledgeable programmers to optimize
I/O operations.
This could be implemented as INITIALSIZE=numeric-expression and
EXTENDSIZE=numeric-expression keywords in the OPEN statement. If absent, the
initial size and extend size would use processor-dependent default values.
If the operating system or file system does not support user-specified
initial or extend sizes, the use of this keyword would have no effect.
Minimal. This keyword is already supported on several popular compilers.
Craig T. Dedo
Elmbrook Computer Services
17130 W. Burleigh Place
Brookfield, WI 53005
(414) 783-5869
E-mail: Craig.Dedo@mixcom.com
ISO/IEC 1539:1991 (E) 9.3.4
May 1996, meeting 137: submitted 96-074
------------------------------------------------------------------------------
141
ORGANIZATION= Specifier on OPEN
Registered
1
Fortran 2000 should support the ORGANIZATION= specifier on the OPEN
statement, as implemented as an extension in several Fortran compilers.
Some file systems allow the user to specify the organization of the file as
either sequential (no fixed size and records are organized sequentially),
relative (fixed number of fixed-length records), or indexed (some fields are
keyed for indexed file access). Knowledgeable programmers would benefit by
being able to specify the organization which is appropriate for the
application, if such organization is available.
This feature could be implemented by an ORGANIZATION=character-expression
keyword in the OPEN statement. The character-expression would take one of
the following values:
SEQUENTIAL The file does not have a fixed size and records are
organized sequentially.
RELATIVE The file has a fixed number of fixed-length records.
INDEXED The file has some fields in each record keyed for
indexed file access.
If the file system in use does not support a particular organization, the use
of the ORGANIZATION keyword would have no effect.
Craig T. Dedo
Elmbrook Computer Services
17130 W. Burleigh Place
Brookfield, WI 53005
(414) 783-5869
E-mail: Craig.Dedo@mixcom.com
ISO/IEC 1539:1991 (E) 9.3.4
May 1996, meeting 137: submitted 96-074
------------------------------------------------------------------------------
142
RECORDTYPE= Specifier on OPEN
Registered
1
Fortran 2000 should support the RECORDTYPE= specifier on the OPEN
statement, as implemented as an extension in several Fortran compilers.
Some file systems allow the user to specify the record type of the file.
Knowledgeable programmers would benefit by being able to specify the record
type which is appropriate for the application, if such record type is
available.
This feature could be implemented by an RECORDTYPE=character-expression
keyword in the OPEN statement. The character-expression would take one of
the following values:
FIXED Specifies fixed length records.
VARIABLE Specifies variable length records.
STREAM Specifies stream records, i.e., records which have no
organization.
As an extension, a processor could offer additional record type values.
Minimal to moderate.
Craig T. Dedo
Elmbrook Computer Services
17130 W. Burleigh Place
Brookfield, WI 53005
(414) 783-5869
E-mail: Craig.Dedo@mixcom.com
ISO/IEC 1539:1991 (E) 9.3.4
May 1996, meeting 137: submitted 96-074
------------------------------------------------------------------------------
143
USEROPEN= Specifier on OPEN
Registered
1
Fortran 2000 should support the USEROPEN= specifier on the OPEN
statement, as implemented as an extension in several Fortran compilers.
Some file systems allow the user to specify a user-written external
procedure which controls the opening of the file.. Knowledgeable programmers
would benefit by being able to specify additional I/O capabilities which are
not available using the regular OPEN keywords.
This feature could be implemented by a USEROPEN=procedure-name
keyword in the OPEN statement. The procedure would be declared
EXTERNAL and, if it is a function, be of a processor-dependent type.
Minimal to moderate.
Craig T. Dedo
Elmbrook Computer Services
17130 W. Burleigh Place
Brookfield, WI 53005
(414) 783-5869
E-mail: Craig.Dedo@mixcom.com
ISO/IEC 1539:1991 (E) 9.3.4
May 1996, meeting 137: submitted 96-074
------------------------------------------------------------------------------
144
UNLOCK Statement
Registered
1
Fortran 2000 should allow a programmer to unlock the most recently read
or written record without depending on processor, operating system, or file
system defaults.
Many operating systems and file systems lock records when they are read
or written. In many cases, the record is unlocked at an indeterminate time.
This can cause problems in shared file applications and certain other
situations. It would be helpful to give to the application programmer the
ability to force the unlocking of records.
This could be implemented by creating a statement of the form:
UNLOCK ([UNIT=]io-unit [, ERR=label] [, IOSTAT=iostatus])
where:
io-unit is an I/O unit number
label is a label of a branch target statement that receives control if
there is an error
iostatus is a scalar integer variable that is defined as a processor-
dependent positive integer if there is an error and as zero if
there is no error
If there is no record locked at the time the UNLOCK statement is
executed, the statement has no effect.
Implementation costs should be quite low since record locking is a
function which is inherent to the READ and WRITE operations.
Craig T. Dedo
Elmbrook Computer Services
17130 W. Burleigh Place
Brookfield, WI 53005
(414) 783-5869
E-mail: Craig.Dedo@mixcom.com
ISO/IEC 1539:1991 (E) 9.3, 9.4
May 1996, meeting 137: submitted 96-074
------------------------------------------------------------------------------
145
$ and \ Edit Descriptors
Registered
1
Fortran 2000 should include support for the $ and \ edit descriptors, as
implemented as extensions in several Fortran compilers.
Both of these edit descriptors suppress end-of-record information at the
end of a record. This makes it possible to concatenate two or more records
in one output line or to create prompting. The $ edit descriptor is an
extension in the Cray, DEC, EPC, HP, IBM, Lahey, and Sun compilers.
The Fortran 2000 standard should implement these edit descriptors as
defined in the above mentioned compilers.
The impact of implementing these edit descriptors should not be great.
The algorithms already exist.
Craig T. Dedo
Elmbrook Computer Services
17130 W. Burleigh Place
Brookfield, WI 53005
(414) 783-5869
E-mail: Craig.Dedo@mixcom.com
ISO/IEC 1539:1991 (E) 10.2.1
May 1996, meeting 137: submitted 96-074
------------------------------------------------------------------------------
146
Q Edit Descriptor (Input Character Count Editing)
Registered
1
Fortran 2000 should support the Q edit descriptor, as implemented as an
extension in several Fortran compilers. This edit descriptor obtains the
number of characters remaining in the current input record.
It is often very useful to obtain a count of the remaining characters in an
input record, right in the middle of the input record. The support for the Q
edit descriptors an extension in the DEC, EPC, IBM, Lahey, and Sun compilers
attests to the popularity and usefulness of this feature.
On input, if a Q edit descriptor corresponds to a scalar integer variable,
the integer variable is set to the number of characters remaining in the
input record. If the corresponding input variable is some other data type,
an error occurs. On output, the corresponding output list element is
ignored.
Since this is a popular extension, the algorithms are well know. Therefore,
it should be fairly inexpensive to implement this feature.
Craig T. Dedo
Elmbrook Computer Services
17130 W. Burleigh Place
Brookfield, WI 53005
(414) 783-5869
E-mail: Craig.Dedo@mixcom.com
ISO/IEC 1539:1991 (E) 10.2.1
May 1996, meeting 137: submitted 96-074
------------------------------------------------------------------------------
147
Field and Record Justification
Registered
1
Fortran 2000 should provide edit descriptors which allow the user to
specify whether a particular field is right justified, center justified, or
left justified. If justification is not specified, it would default to the
current rules.
The current Fortran 90 standard and the Fortran 95 DIS only allow
justification as defined by the standard. If the programmer could specify
field and record justification, s/he could produce much better aligned output
with much less effort. Right now, it takes quite a lot of effort on the
programmer's part in order to justify output, especially if it is to be
centered on a record.
One method would be to precede each field with JR for right justification,
JL for left justification, and JC for center justification, with the target
field immediately following in parentheses. Specifying JR, JC, or JL at the
beginning of a record could specify justification for entire records.
Investigation may reveal more effective methods for implementing each of
these features.
Unknown. This may be fairly easy to implement or there may be
unforseen complications. However, the existence of this feature in almost all
word processing and spreadsheet software indicates that the algorithms are
already highly developed and well known.
Craig T. Dedo
Elmbrook Computer Services
17130 W. Burleigh Place
Brookfield, WI 53005
(414) 783-5869
E-mail: Craig.Dedo@mixcom.com
ISO/IEC 1539:1991 (E) 10.2.1
May 1996, meeting 137: submitted 96-074
------------------------------------------------------------------------------
148
Prohibit Embedded Blanks in Edit Descriptors
Registered
1
Fortran 2000 should require that format edit descriptors not contain
embedded blanks, except for character strings appearing inside quotes or
parentheses.
A Fortran 90 interpretation allowed embedded blanks to appear in format
edit descriptors. This is counter-intuitive. It is contrary to the practice
of the last 1000 years (in Western languages) whereby blanks signify the
separation of words and tokens. A format edit descriptor is a single token
or "word" in the eyes of application developers. Therefore, embedded blanks
should not be allowed inside of edit descriptors.
This could be implemented by changing the rules in section 10.2.1
governing the format of edit descriptors.
Minimal. Some implementors will have to modify their compilers in order
to comply with the new rule. Some users who used blanks embedded in format
edit descriptors will have to restructure their code.
Craig T. Dedo
Elmbrook Computer Services
17130 W. Burleigh Place
Brookfield, WI 53005
(414) 783-5869
E-mail: Craig.Dedo@mixcom.com
ISO/IEC 1539:1991 (E) 10.2.1
May 1996, meeting 137: submitted 96-074
------------------------------------------------------------------------------