Microsoft Word - 99-108.doc

From: Kurt W. Hirchert J3/99-108 (Page 1 of 18)

Subject: INITIAL / FINAL Edits Meeting 148

J3/99-108 (Page 1 of 18)

References: 97-209r1 (rationale), 97-256 (specifications), 98-138 (syntax), 98-229 (draft edits),

98-230 (additional specifications and syntax)

The Main Edit

104:1-5 Revise section to read as follows: “

6.3 Initialization and Finalization

Initialization is the process by which the status of a data object is established prior to any5

explicit operations on that object. Finalization of a data object is the processing that follows

the explicit operations on that object. Every data object in a program undergoes both

initialization and finalization. Data objects shall not be referenced, defined, or used in any

other way before they are initialized or after they are finalized.

Note:10

Although every data object undergoes the conceptual processes of initialization and

finalization, for most objects those processes involve no operations and thus have no affect on

the object.

6.3.1 How initialization is performed

Initialization of an object consists of two steps, performed in order:

(1) Preliminary initialization establishes a default status for the object, based on its

declared attributes.

(2) Overriding initialization may alter that status, based on explicit initialization declared

for the object.

6.3.1.1 Preliminary initialization20

The effect of preliminary initialization depends on whether the storage for the object has just

been allocated. Preliminary initialization for allocated objects is performed if one of the

following is true:

(1) The object has neither the ALLOCATABLE nor the POINTER attribute.

(2) The object has either the ALLOCATABLE or the POINTER attribute and is being25

allocated in an ALLOCATE statement.

Otherwise, preliminary initialization for allocatable objects is performed.

From: Kurt W. Hirchert J3/99-108 (Page 2 of 18)

Subject: INITIAL / FINAL Edits Meeting 148

J3/99-108 (Page 2 of 18)

6.3.1.1.1 Preliminary initialization of allocated objects

Preliminary initialization of allocated objects is performed on each element of the entity

(treating a scalar entity as a single element), based on the type of the entity:

(1) If the data type is the intrinsic type INTEGER, REAL, COMPLEX, or LOGICAL, the

element is undefined.5

(2) If the data type is the intrinsic type CHARACTER, each character position in the

element is undefined.

(3) If the data type is a derived type, the following steps are performed:

(a) If the data type is an extended type, initialization is performed (recursively) for

the parent component subobject of the element.

J3 Note:

It is editorially unclear whether there really is a parent component or only a notation that looks

like such a component exists. (This is unresolved issue 19.) Depending on which way this is

resolved, this text may need to be changed to say something like the “components from the

parent type” instead of the parent component and to allow for their default initialization.15

(b) Initialization is performed (recursively) for the explicitly declared component

subobjects of the element, in the order those components were declared. Default

initialization (4.5) for a component is treated like explicit initialization for the

recursive initialization of the component subobject.

Note:20

The preliminary initialization of an object of derived type includes both the preliminary and

the overriding initialization of its component subobjects.

6.3.1.1.2 Preliminary initialization of allocatable objects

In this context, if the data entity has the ALLOCATABLE attribute, preliminary initialization

affects only its allocation status (6.4.1.2). The allocation status is not currently allocated.25

In this context, if the data entity has the POINTER attribute, initialization affects only its

pointer association status (14.6.2.1). The pointer association status is undefined.

Note:

This section applies only when the ALLOCATABLE or POINTER object is not being allocated

in an ALLOCATE statement. Otherwise, the preceding section applies.30

From: Kurt W. Hirchert J3/99-108 (Page 3 of 18)

Subject: INITIAL / FINAL Edits Meeting 148

J3/99-108 (Page 3 of 18)

6.3.1.2 Override initialization

As with preliminary initialization, the effect override initialization depends on whether the

storage for the object has just been allocated. Additionally, it depends on which of the

following cases is applicable:

(1) There is no explicit initialization (5.1) for the object.5

(2) Explicit initialization for the object occurs in the type declaration statement or

component definition statement for the object. Such explicit initialization always

applies to the entire object.

(3) Explicit initialization for the object occurs in one or more DATA statements (5.3.13).

Each explicit initialization in a DATA statement applies to a scalar object, possibly a

subobject of a named object. There may be subobjects of the object for which no explicit

initialization is provided.

6.3.1.2.1 Override initialization of allocated objects

For objects which have just been allocated, the effect of override initialization is further

determined by whether the type of the object is one for which an initial procedure (4.5.1.5) has15

been specified.

6.3.1.2.1.1 Override by assignment

If the type has no initial procedures, override initialization is handled in accordance with the

rules of intrinsic assignment.

(1) If there is no explicit initialization, the status of the object remains as established by20

preliminary initialization.

(2) If the object is explicitly initialized in a type declaration statement or component

definition statement, that initialization is assigned to the object, as a whole, in

accordance with the rules of intrinsic assignment.

(3) If the object is explicitly initialized in DATA statements, the identified scalar objects25

(possibly elements or component subobjects of the object) are assigned their

corresponding initial value in accordance with the rules of intrinsic assignment. Any

portion of the object not identified in a DATA statement retains its status as established

by preliminary initialization.

6.3.1.1.1.1 Override by initial procedure30

If the type has one or more initial procedure, execution of initial procedures replaces intrinsic

assignment in override initialization.

From: Kurt W. Hirchert J3/99-108 (Page 4 of 18)

Subject: INITIAL / FINAL Edits Meeting 148

J3/99-108 (Page 4 of 18)

(1) If there is no explicit initialization, override initialization is performed by invoking an

initial procedure for this type with an argument list that consists solely of the object

being initialized, or, if no such procedure exists, by the object retaining its status as

established by preliminary initialization.

(2) If the object is explicitly initialized in a type declaration statement or component

definition statement, the initialization shall consist of a single structure constructor for

the type. Override initialization is performed by invoking an initial procedure for the

type with an argument list consisting of the object itself followed by the argument list

from the structure constructor.

(3) If the object is explicitly initialized in DATA statements, those initializations shall not be

for component subobjects of the object. Override initialization is performed separately

for each element of the object. Elements for which an initialization is provided are

processed as in (2). Elements for which no initialization is provided are processed as in

(1).

Proposal Note:15

The above points include technical material that was not in the specification and syntax (filling

in holes).

6.3.1.1.2 Override initialization of allocatable objects

If an object has the ALLOCATABLE attribute, explicit initialization of that object is prohibited.

The status of the object remains as established by preliminary initialization.20

If an object has the POINTER attribute, the only permitted initialization is to NULL( ). If such

an explicit initialization is present, the pointer association status of the object becomes

disassociated. Otherwise, the status of the object remains as established by preliminary

initialization (i.e. undefined)

Note:25

Since any explicit initialization for a pointer applies to its pointer association status, not the

elements it points to, elements allocated through a pointer are always treated as having no

explicit initialization for purposes of determining the nature of their override initialization.

6.3.2 How finalization is performed

As with initialization, the effect of finalization depends on whether the object is processor-30

allocated or allocatable by the program.

From: Kurt W. Hirchert J3/99-108 (Page 5 of 18)

Subject: INITIAL / FINAL Edits Meeting 148

J3/99-108 (Page 5 of 18)

6.3.2.1 Finalization of processor-allocated objects

If the type of the object is an intrinsic type, finalization of the object involves no further

operations.

If the type of the object is a derived type, finalization consists of the following steps, performed

in order:5

(1) If the type has one or more final procedure, a final procedure is invoked with an

argument list that consists solely of the object being finalized.

A standard-conforming program is required to provide for the finalization of each

object that has been initialized and whose finalization would include the execution of a

final procedure.

Note:

For most objects this requirement is fulfilled automatically. The effect of this requirement on a

program is that it must deallocate any object it allocates through a POINTER if the type is one

with a final procedure.

It is not expected that processors will enforce this requirement. Rather, it allows processors,15

when faced with a program that violates this requirement, to process it as it wishes.

Reasonable handling might be to allow the program to “leak memory” and not finalize the

objects so leaked or to perform “garbage collection” to recover such objects so they can be

finalized and deallocated.

(2) Each element of the object is processed as follows:20

(a) Finalization is performed (recursively) for the explicitly declared component

subobjects of the element, in the reverse of the order those components were

declared.

(b) If the data type is an extended type, finalization is performed (recursively) for

the parent component subobject of the element.25

J3 Note:

See note in section 6.3.1.1.1 about parent component subobject.

6.3.2.2 Finalization of explicitly allocatable objects

If an object has the ALLOCATABLE attribute, finalization consists of deallocating the object if

its allocation status is currently allocated. This deallocation, if it occurs, includes the30

finalization of the elements of the object by the process in 6.3.2.1.

From: Kurt W. Hirchert J3/99-108 (Page 6 of 18)

Subject: INITIAL / FINAL Edits Meeting 148

J3/99-108 (Page 6 of 18)

If an object has the POINTER attribute, finalization of the object involves no further

operations.

Note:

If a pointer appears in a DEALLOCATE statement, the pointer itself is not finalized, but the

target object is finalized by the process in 6.3.2.1.5

6.3.3 When initialization and finalization is performed

Initialization and finalization is performed collectively for the data objects declared in a

scoping unit. Additional initialization and finalization may result from the execution of

specific statements.

6.3.3.1 Initialization and finalization of scoping units

Scoping unit initialization and finalization are associated respectively with the creation and

destruction of instances of the main program, subprograms, and modules.

An instance of the main program is created immediately before it is executed and destroyed

when a STOP statement or the END PROGRAM statement is executed.

When a procedure defined by a subprogram is invoked from an instance of a subprogram or

the main program, an instance of that subprogram is created. That instance is said to derive

from the instance that invoked the procedure. The derived instance is destroyed when the

procedure completes.

If a subprogram or main program directly or indirectly references a module, each instance of

the subprogram or main program accesses entities from an instance of the module determined20

as follows. If the instance of a subprogram derives, directly or indirectly, from an instance of a

scoping unit that directly or indirectly references the same module, it accesses entities from the

same instance of the module as the instance from which it derives. Otherwise, a new instance

of the module is created; this new instance of the module is the one accessed by the instance of

the subprogram or main program; it is not destroyed until after the instance of the subprogram

or main program is destroyed.

If a subprogram or main program contains data objects in a named common block or directly

or indirectly references a module containing such data objects, each instance of the

subprogram or main program accesses an instance of the storage sequence for that common

block determined as follows. If the instance of a subprogram derives, directly or indirectly,30

from an instance of a scoping unit that contains that common block or directly or indirectly

references a module containing the common block, it accesses the same instance of the storage

sequence as the instance from which it derives. Otherwise, a new instance of the storage

sequence is created; this new instance of the storage sequence is the one accessed by the

From: Kurt W. Hirchert J3/99-108 (Page 7 of 18)

Subject: INITIAL / FINAL Edits Meeting 148

J3/99-108 (Page 7 of 18)

instance of the subprogram or main program; it is not destroyed until after the instance of the

subprogram or main program is destroyed.

A process is permitted, at its discretion, to merge instances of modules and common block

storage sequences that are not required to exist at the same time, eliminating the destruction

(and associated finalization) of the earlier instance and the creation (and associated

initialization) of the later instance.

Note:

Taken to the extreme, if a processor uses a strategy in which an instance of a subprogram or

the main program always invokes procedures one at a time, none of the instances of modules

and common block storage sequences would be required to exist at the same time, and the10

processor would be permitted to merge all of the instances of a given module or common

block storage sequence into a single instance. Other strategies might allow merging to result

in one instance per hardware processor on a multiprocessor system.

If a subprogram is nested in another scoping unit and thus has access to entities in that scoping

unit by host association, an instance of the subprogram accesses those entities from the same15

instance of the host scoping unit from which the subprogram itself was accessed in order to be

invoked.

Scoping unit initialization and finalization can be further divided into the initialization and

finalization of objects that are distinct in separate instances of the scoping unit and the

initialization and finalization of objects that are shared among all the instances of the scoping20

unit in the program.

6.3.3.1.1 Instance initialization and finalization of scoping units

Instance initialization and finalization of a scoping unit applies to all objects local to the

scoping unit that are not dummy arguments and do not have either the SAVE or the

PARAMETER attribute. Instance initialization of a scoping unit also applies to dummy25

arguments with the INTENT(OUT) attribute, but instance finalization does not.

Instance initialization of a scoping unit occurs after the instance initialization of any module it

references, and instance finalization occurs before the instance finalization of any referenced

module.

Except during the execution of initial and final procedures, instance initialization of a nested30

scoping unit occurs after instance initialization of the host scoping unit and instance

finalization occurs after instance finalization of the host. During execution of initial and final

procedures, the instance of the host scoping unit may be only partially initialized or finalized

and the program is restricted from using those objects which are not yet initialized or already

finalized.35

From: Kurt W. Hirchert J3/99-108 (Page 8 of 18)

Subject: INITIAL / FINAL Edits Meeting 148

J3/99-108 (Page 8 of 18)

Objects in common are initialized before objects not in common and finalized after. Objects in

common are not initialized if the storage sequence is not newly created. Objects in common

are not finalized if the storage sequence is not about to be destroyed.

Objects in common are initialized in order of their first declaration and finalized in the reverse

of that order.

Objects not in common are initialized in order of their first declaration and finalized in the

reverse of that order.

A processor is permitted, as an exception to the above orderings, to initialize function result

variables and INTENT(OUT) dummy arguments before the point indicated by that order and

to finalize function result variables after the point indicated.10

Note:

This exception allows a processor the option to put the initialization and finalization of a

function result and/or the initialization of INTENT(OUT) dummy arguments in the caller of a

procedure rather than the procedure itself.

Note:

The purpose of these orderings is to establish which objects can and cannot be used in initial

and final procedures. Initialization and finalization may be performed in other orders as long

as the same effect is achieved. For example, it is generally possible to perform all initialization

not involving initial procedures before that which does.20

6.3.3.1.2 Program initialization and finalization of scoping units

Program initialization and finalization of a scoping unit applies to all objects local to the

scoping unit that have either the SAVE or the PARAMETER attribute.

Program initialization of a scoping unit occurs before all instance initialization of that scoping

unit, and program finalization occurs after all instance finalization. If there is no instance25

initialization or finalization of a scoping unit (e.g., because a procedure is never called or a

module is unreferenced), it is processor dependent whether the program initialization and

finalization for that scoping unit occurs.

Note:

This allows the processor the choice of either unconditionally performing program30

initialization for all scoping units at the beginning of the program or of deferring program

From: Kurt W. Hirchert J3/99-108 (Page 9 of 18)

Subject: INITIAL / FINAL Edits Meeting 148

J3/99-108 (Page 9 of 18)

initialization of a scoping unit to the beginning of the first instance initialization for that

scoping unit.

Program initialization of a scoping unit occurs after the program initialization of any module it

references, and program finalization occurs before the program finalization of any referenced

module.5

Except during the execution of initial and final procedures, program initialization of a nested

scoping unit occurs after program initialization of the host scoping unit and program

finalization occurs after program finalization of the host. During execution of initial and final

procedures, the program of the host scoping unit may be only partially initialized or finalized

and the program is restricted from using those objects which are not yet initialized or already

finalized.

Objects in common are initialized before objects not in common and finalized after. Objects in

common are not initialized if the storage sequence is not newly created. Objects in common

are not finalized if the storage sequence is not about to be destroyed.

Objects in common are initialized in order of their first declaration and finalized in the reverse

of that order.

Objects not in common are initialized in order of their first declaration and finalized in the

reverse of that order.

6.3.3.2 Initialization and finalization resulting from statement execution

Execution of an ALLOCATE statement to allocate storage for a pointer or allocatable object20

causes initialization of the storage allocated. The initialization process for this storage is

effectively identical to the initialization of a processor-allocated object of the same type, type

parameters, and bounds. The pointer or allocatable object itself is not initialized by this

process.

Execution of a DEALLOCATE statement to deallocate storage for a pointer or allocatable25

object causes finalization of the storage before it is deallocated. The finalization process for

this storage is effectively identical to the finalization of a processor-allocated object of the same

type, type parameters, and bounds. The pointer or allocatable object itself is not finalized by

this process.

When an expression result is passed to a procedure, it is placed in an anonymous data object30

that is then associated with the dummy argument. Such anonymous data objects are

initialized and finalized by the processor. Initialization generally occurs as part of the process

that defines the expression result. Function result initialization is performed by the

initialization of the function result variable. Defined structure constructor initialization is

performed by the initial procedure (4.5.1.5) that implements that constructor. Finalization35

occurs at the discretion of the processor when it no longer needs that expression result.

From: Kurt W. Hirchert J3/99-108 (Page 10 of 18)

Subject: INITIAL / FINAL Edits Meeting 148

J3/99-108 (Page 10 of 18)

Exactly when this occurs may depend on whether a processor reuses a computed expression

result or recomputes it each time it is needed.

An object or subobject, supplied as an actual associated with a dummy argument with the

INTENT(OUT) attribute, undergoes finalization reflecting the attributes of the dummy

argument immediately before the procedure is invoked. This finalization “balances” the

initialization of the dummy argument during the execution of the procedure.

Note:

The attributes of the dummy argument control the nature of the finalization of the actual

argument. For example, if an ALLOCATABLE object is associated with an INTENT(OUT),

ALLOCATABLE dummy argument, its finalization reflects the ALLOCATABLE attribute and10

includes the deallocation of the object. However, if the dummy argument does not have the

ALLOCATABLE attribute, the finalization applies only to the elements of the object and the

object is not deallocated.

Note:15

In all cases where this finalization is non-trivial, the interface is required to be explicit, so the

processor may at its discretion perform the finalization in the caller and the initialization in the

procedure to minimize the amount of information that must be communicated to the

procedure.

”20

Proposal Note:

Much of the text in 6.3 and its subsections could be cleaned up significantly if we had a better

way to distinguish the allocatable part of an allocatable object from the object allocated. With

pointers, we can get by talking about the pointer and its target, but we seem to have no

comparable terminology for allocatable objects. Proper terminology would allow us to more25

clearly distinguish the effects of initialization and finalization on an allocatable object from

that on the object allocated. (There are some places where using pointer and target

terminology might make the pointer descriptions clearer, but I was reluctant to use that

descriptive model when I couldn’t use a parallel model for allocatable.)

From: Kurt W. Hirchert J3/99-108 (Page 11 of 18)

Subject: INITIAL / FINAL Edits Meeting 148

J3/99-108 (Page 11 of 18)

Secondary Edits

Proposal Note:

The first batch of secondary edits provides the rules for initial and final procedures.

42:5 Replace “binding-name” with “binding-id”.

42:5+ Insert new rule and constraints: “

R439.1binding-id is binding-name

or (INITIAL)

or (FINAL)

Constraint: The :: and the => binding shall not be omitted if the binding-id is not a binding-

name.

”

46:35+Insert new paragraph: “

A procedure bound to a binding identifier of (INITIAL) is an initial procedure, as described in

4.5.1.5.1. A procedure bound to a binding identifier of (FINAL) is a final procedure, as

described in 4.5.1.5.2. All other type bound procedures are handling as described in this

section.15

”

47:20+Insert new sections: “

4.5.1.5.1 Initial procedures

A type may have more than one initial procedure bound to it. If there are more than one, they

must satisfy the rules for unambiguous generic procedures (14.1.2.3).

Each initial procedure shall have at least one dummy argument. The first dummy argument

shall be a non-optional dummy argument. It shall have the INTENT(INOUT) attribute and be

of the fixed type to which the initial procedure is bound. If it is an array, it shall have assumed

shape. It shall not have the ALLOCATABLE or POINTER attribute. Any additional dummy

arguments shall have the INTENT(IN) attribute or shall be dummy arguments for which25

INTENT shall not be specified.

If the type to which the procedure is bound is extensible, the initial procedure for the type is

used in the initialization process (6.3) for any extension types of that type, but it is not

inherited as a initial procedure for those extension types.

From: Kurt W. Hirchert J3/99-108 (Page 12 of 18)

Subject: INITIAL / FINAL Edits Meeting 148

J3/99-108 (Page 12 of 18)

If a type has any initial procedures, it shall have one with a scalar argument.

If a type has no explicitly specified initial procedure applying to arrays of rank n, the processor

provides them based on the procedures explicitly specified for the highest rank m less than n.

These processor-provided initial procedures traverse the outer n-m dimensions of the

argument in the array element order, applying the explicitly specified initial procedure to the5

rank m sections thus identified. The processor always provides versions in which any

additional arguments are the same as in the rank m version. If any of the additional arguments

are dummy data objects not having the ALLOCATABLE or POINTER attribute and having a

rank small enough that increasing it by n-m would still give a valid rank, the processor also

provides versions in which the various combinations of those arguments have their rank so10

increased, with the outer n-m extents required to agree with those of the first argument. For

the arguments so increased in rank, sections are analogously selected to identify an argument

of the appropriate rank to supply to the rank m version. If provision of a particular

combination of increased rank arguments would violate the rules in 14.1.2.3, that version is not

provided. To avoid such ambiguity, any optional argument whose rank is increase is a

required argument in the increased rank version.

Note:

The effect of the processor providing these initial procedures is similar to elemental

procedures, but the repetition is performed in sequence rather than in parallel and side effects

are allowed.20

4.5.1.5.2 Final procedures

A type may have more than one final procedure bound to it. If there are more than one, they

must satisfy the rules for unambiguous generic procedures (14.1.2.3).

Each final procedure shall have a single non-optional dummy argument. It shall have the

INTENT(INOUT) attribute and be of the fixed type to which the final procedure is bound. If it25

is an array, it shall have assumed shape. It shall not have the ALLOCATABLE or POINTER

attribute.

If the type to which the procedure is bound is extensible, the final procedure for the type is

used in the finalization process (6.3) for any extension types of that type, but it is not inherited

as a final procedure for those extension types.30

If a type has any final procedures, it shall have one with a scalar argument.

If a type has no explicitly specified final procedure applying to arrays of rank n, the processor

provides one based on the procedure explicitly specified for the highest rank m less than n.

This processor-provided final procedure traverses the outer n-m dimensions of the argument

in the reverse of array element order, applying the explicitly specified final procedure to the35

rank m sections thus identified.

From: Kurt W. Hirchert J3/99-108 (Page 13 of 18)

Subject: INITIAL / FINAL Edits Meeting 148

J3/99-108 (Page 13 of 18)

”

Proposal Note:

The second batch of secondary edits provides for the use of structure constructor syntax to

access alternative initialization by an initial procedure.

53:38-40 Replace paragraph with the following: “5

A derived-type implicitly defines a corresponding structure constructor that allows

construction of values of that derived type from values of other types. A structure constructor

is interpreted as an intrinsic structure constructor if the derived type has no initial procedures;

it is interpreted as a defined structure constructor if the derived type has one or more initial

procedure.10

R448.9structure-constructor is intrinsic-structure-constructor

or defined-structure-constructor

4.5.6.1 Intrinsic structure constructors

An intrinsic structure constructor allows a scalar value of the derived type to be constructed

from a sequence of values corresponding to the components of the derived type.15

”

53:41 Change “structure-constructor” to “intrinsic-structure-constructor”.

Proposal Note:

The rules for when a structure constructor is interpreted intrinsically and when it is

interpreted by an initial procedure were not in the specification passed. This is my attempt to20

fill them in.

55:32+Insert new subsection: “

4.5.6.2 Defined structure constructors

A defined structure constructor allows a value of the derived type to be constructed by passing

arguments to an initial procedure for the type.25

R450.1defined-structure-constructoris derived-type-spec ( [ argument-list ] )

Constraint: The argument-list shall be a valid specifications of actual arguments

corresponding to the dummy arguments other than the first for one of the initial

procedures for the type.

From: Kurt W. Hirchert J3/99-108 (Page 14 of 18)

Subject: INITIAL / FINAL Edits Meeting 148

J3/99-108 (Page 14 of 18)

If a defined structure constructor is used as an explicit initialization (5.1), its argument list is

used in the initialization process (6.3) for the object to which the explicit initialization applies.

If a defined structure constructor is in any other context, the argument list is used in the

initialization of an anonymous object of that type. If the argument list is valid in the

initialization process for objects of more than one possible rank, the anonymous object has the

minimum such rank. The anonymous object is the “value” of the structure constructor.

”

Proposal Note:

The current syntax for declaring extension types provides no means for the extension type to

specify a different default initialization for its “parent component” or link alternative10

initialization of the extension type to alternative initialization of the parent. One can work

around this by simply allowing the parent component to be initialized “wrong” and

overriding that initialization in an initial procedure for the extension, but this is a bit awkward

and causes the processor to do more work during the initialization process. This is not

something I can fix in the proposal, but it might be something we should think about.15

Related Minor Edits

39:10-13 Replace the first three sentences of the paragraph with “Initialization in a

component declaration specifies default initialization for that component. This default

initialization contributes to the initialization process (6.3) for objects of that type.”

Proposal Note

Many of the details here have been incorporated into 6.3.20

Sometimes we talk about default initialization and sometimes we talk about component

initialization. Is there a consistent reason for using one term or the other?

44:17 Replace “is initially … (14.7.5)” with “is default initialized (6.3)”

44:18-25 Delete sentences after first two.

Proposal Note:25

This material is covered in another way in 6.3.

44:26-45:15 Move into 6.3 somewhere.

46:24-33 Move into 6.3 somewhere.

From: Kurt W. Hirchert J3/99-108 (Page 15 of 18)

Subject: INITIAL / FINAL Edits Meeting 148

J3/99-108 (Page 15 of 18)

54:16-17 [Relate to 6.3?]

70:42-44 Replace second sentence in the paragraph with “On invocation of the procedure,

such a dummy argument undergoes the initialization process (6.3).”

Proposal Note:

The new complications are all described in 6.3.5

72:17-18 Replace the final sentence in the paragraph with “Because an INTENT(OUT)

variable has no access to any part of the previous status of the actual argument, the

initialization process is applied to it.”

75:11-19 Replace the first two paragraphs of the section:

“If an object has the SAVE attribute, a single copy of the object is shared among all instances10

(12.5.2.3) of the scoping unit in which it appears, allowing association status, allocation status,

definition status, and value established in one instance to be referenced in another instance.

Such an object is called a saved object.

If an object in an executable scoping unit does not have the SAVE attribute, a separate copy of

that object exists for each instance of the scoping unit. For objects in a module that do not have15

the SAVE attribute, the basis for sharing is that the instance of a module referenced by an

executable scoping unit is the one available to all instances resulting from its procedure

invocations. Thus, two instances of executable scoping units referencing a module share the

same instance if and only if one is the direct or indirect result of the other or both are the direct

or indirect result of a third instance that also references that module.”

Proposal Note:

In FORTRAN 77, the descriptive model was that variables existed for the life of a program, but

that in the absence of a SAVE statement, they became undefined between executions. In

Fortran 90, in order to accomodate features such a recursion and automatic array, we switched

to the model that in the absence of SAVE, each execution had its own copy of the variable.25

However, many vestiges of the F77 descriptive model remain. Because the semantics of intial

and final procedures are strongly tied to the F90 model, it is helpful to revise some of the text

that still reflects the F77 model.

The pointer part of this will be handled elsewhere.

Proposal Note:

79:38+<section 5.2 contains no description of the effect of =>NULL( ) initialization>

From: Kurt W. Hirchert J3/99-108 (Page 16 of 18)

Subject: INITIAL / FINAL Edits Meeting 148

J3/99-108 (Page 16 of 18)

81:38-42 Replace the second sentence in the paragraph:

“For a common block declared in a SAVE statement, its common block storage sequence

(5.6.2.1) in an instance of the scoping unit containing the common block is associated with the

common block storage sequence for every other instance of a scoping unit containing the

common block, thus making the values in those sequences available to all instances. For a

common block not having the SAVE attribute, the basis for sharing is that the common block

storage sequence for a common block in an instance of an executable scoping unit is associated

with all such common block storage sequences in instances resulting from its procedure

invocations. Thus, the common block storage sequences in two instances of executable

scoping units containing a common block are associated if and only if one instance is the direct

or indirect result of the other or both are the direct or indirect result of a third instance that

also contains that common block.”

84:2-86:32 <Does any of this need to be moved to 6.3?>

93:10+Insert note: “

Note:15

A common-block-object must not be of a type with initial or final procedures, since initial and

final procedures are type-bound procedures and sequence types do not have type-bound

procedures.

”

Proposal Note:20

Yes, I really mean “must” here. This is an implied requirement, not a direct one.

107:20-43 Delete.

Proposal Note:

This should be covered in 6.3.

108:1-37 Move into 6.3 somewhere.25

110:1-20 Delete.

Proposal Note:

This should be covered in 6.3.

110:21-23 <move into 6.3?>

From: Kurt W. Hirchert J3/99-108 (Page 17 of 18)

Subject: INITIAL / FINAL Edits Meeting 148

J3/99-108 (Page 17 of 18)

110:24-33 Move into 6.3 somewhere.

110:44-111:11 Delete.

Proposal Note:

This should be covered in 6.3

245:23+ Insert new item into list: “5

(d) A dummy argument that has the INTENT(OUT) attribute and is of a type whose

finalization process (6.3) includes the execution of a final procedure,

”

Proposal Note:

This might have been missing from the version of the specification that was passed.10

258:6-7 Replace final sentence in paragraph with sentence as for 72:17-18 above.

259:34-36 Replace second sentence with “No initialization (6.3) is performed on the

dummy data object, even if it has INTENT(OUT).”

346:33-41 Replace both items with “(4) The pointer becomes disassociated by the

initialization process (6.3).”15

347:1-5 Replace all three items with “(2) The target of the pointer is finalized (6.3) by

means other than deallocating the pointer.”

Proposal Note:

This text covers both (2) and (3). (4) is covered by the pointer ceasing to exist, so it doesn’t

matter if it becomes undefined; the new instance of the pointer will be undefined anyway.]20

350:13-19 Combine the three items in “(1) Variables that are defined by the initialization

process (6.3).”

351:29-30 Replace item with “(16) The initialization process (6.3) may cause part or all of

an object to become defined.”

351:35-45 Delete.25

From: Kurt W. Hirchert J3/99-108 (Page 18 of 18)

Subject: INITIAL / FINAL Edits Meeting 148

J3/99-108 (Page 18 of 18)

Proposal Note:

Subsumed by the above.

352:15-28 Delete.

Proposal Note:

These are the variables that cease to exist.5

353:4-5 Replace item with “(11) Successful execution of an ALLOCATE statement for

a nonzero-sized object causes the object to become undefined unless the initialization

process (6.3) defines it.”

353:12-13 Replace “except … specified” with “unless is it defined by the initialization

process (6.3)”10

353:14-15 [Is this needed separate from the statement about the dummy?]

353:19-20 Same replacement as for 353:12-13.

•