From LJM@SLACVM.BITNET Tue Aug 23 07:35:00 1994 Received: from vm.uni-c.dk by dkuug.dk with SMTP id AA19375 (5.65c8/IDA-1.4.4j for ); Wed, 24 Aug 1994 03:15:06 +0200 Message-Id: <199408240115.AA19375@dkuug.dk> Received: from vm.uni-c.dk by vm.uni-c.dk (IBM VM SMTP V2R2) with BSMTP id 3712; Wed, 24 Aug 94 03:14:56 DNT Received: from SLACVM.SLAC.STANFORD.EDU by vm.uni-c.dk (Mailer R2.07) with BSMTP id 2465; Wed, 24 Aug 94 03:14:54 DNT Received: by SLACVM (Mailer R2.08 R208004) id 3303; Tue, 23 Aug 94 18:02:20 PST Date: Tue, 23 Aug 1994 15:35 -0800 (PST) From: "Len Moss" To: "Jerry Wagener" Cc: "SC22/WG5 Mailing List" Subject: Re: (SC22WG5.611) X3J3 letter ballot on three items X-Charset: ASCII X-Char-Esc: 29 In-Reply-To: jwagener@amoco.com -- 08/20/94 04:56 >======== X 3 J 3 L E T T E R B A L L O T ON 3 I T E M S ======== >(And see separate email note for additional background concerning this ballot.) > >Ballot period is 1 Sep 94 to 15 Sep 94. >Send vote, by email and by 15 Sep 94, to Jerry Wagener, jwagener@amoco.com > >At X3J3 meeting 130, three technical items were formally approved for >inclusion in the 009 document with status "approved by X3J3, pending the >results of a two-week X3J3 letter ballot following the meeting". This is that >letter ballot, which is in three parts below - please vote on each part. > >The three items are allocatable derived-type components (94-269r2), >user-defined elemental procedures (94-245r3), and automatic deallocation of >allocatable arrays (94-270r3). The complete text of all three of these >documents is attached to this letter ballot. > >... I hope it's OK to vote early -- I'd like to take care of this now in case I get busy after 1 Sep. I vote NO on part 1 (94-269r2) and YES, WITHOUT COMMENTS on parts 2 and 3 (94-245r3 and 94-270r3). The reasons for my NO vote on part 1 follow, interspersed with the proposal. Leonard J. Moss > >============ t e x t o f 94-269r2 f o l l o w s ============== > X3J3/94-269r2 > > >Subject: Text for X3J3/009 re: Allocatable Components in Structures >(B3) >References: WG5-N930, Resolutions of the Berchtesgaden WG5 Meeting, B9 > WG5-N931, Requirements for Allowing Allocatable derived-type > Components > >Revision history: 94-269r2, resolve comments > 94-269r1, move most initial status to 94-270, fix object init > conflict, editorial fixes > 94-269, specify initial status, use "ultimate component" > classification > WG5-N1040, revised to resolve received comments > 94-202r2 remove allocatable entities from COMMON, do not > specify a storage unit; clarify/simplify constructors > (revised post-meeting per meeting 129 comments) > 94-202r1 provide restriction for entity-decls, add constructors > 94-202 original presentation, May 1994 (meeting 129) > >Requirement Title: B9/B3 Allocatable derived-type components > >Status: X3J3 consideration in progress > >Technical Description: > Currently, the ALLOCATABLE attribute is limited to local named array >data entities. One cannot have allocatable components of derived-type >objects, nor allocatable dummy arguments or function return values. There is >a requirement from WG5 that these restrictions be removed, that ALLOCATABLE be >extended and regularized. > In addition, if an ALLOCATABLE object is still allocated when it goes >out of scope, its allocation status becomes undefined. There is a desire that >the deallocation be provided "automatically" by the processor. That is >addressed in a separate paper (X3J3/94-270r2). I am in favor of the automatic deallocation proposed in 94-270r2; however, this paragraph seems to be setting up automatic deallocation as a general requirement for all ALLOCATABLE objects, including such possible future enhancements as ALLOCATABLE dummies and function return values. I do not understand how the latter could be implemented efficiently, or, for that matter, exactly _when_ a function return value goes "out of scope". I assume ALLOCATABLE dummies would have to correspond to ALLOCATABLE actual argument variables which would have their own scope so this case is more understandable, though not, in my opinion, adequately spelled out in this overview. I suggest that the above paragraph be qualified somehow to indicate that automatic deallocation is not a general requirement for all future objects that might be given an ALLOCATABLE attribute. > The current paper provides a major step towards ALLOCATABLE arrays as >full, first-class entities. It provides for them to appear as components of >derived types, as per WG5-N931, "Requirements for Allowing Allocatable >Derived-type Components". > Still outstanding from the general request: > - ALLOCATABLE dummy arguments and function return values The present proposal appears to leave in place the restriction against ALLOCATABLE _whole_ arrays as dummy arguments and function return values but to permit ALLOCATABLE arrays as subobjects of such entities -- was this the intent? If so, I strongly oppose such an ad hoc compromise -- it won't significantly reduce the complexity of the standard or of implementations, it will only annoy users and undermine our credibility. If this was not the intent, the edits proposed below are completely inadequate. > - ALLOCATABLE strings > - ALLOCATABLE derived types (needs Parameterized Derived Types) I'm not certain what distinction is being made here between "ALLOCATABLE derived types" and "ALLOCATABLE components in structures", unless the former is being treated as a synonym for derived types with non-kind parameters. >While these are mostly fairly straightforward, a large number of edits appear >to be required. Due to the shortage of time, we recommend that this >development be undertaken for Fortran 2000. > Per direction from X3J3, this proposal does not provide for allowing >ALLOCATABLE objects, nor derived type objects with ALLOCATABLE components in >COMMON or EQUIVALENCE. > >Motivation: > ALLOCATABLE provides functionality which shares much with that of the >POINTER features. Indeed, the underlying implementation is probably nearly >identical, with one important difference. The address pointer implicit in >ALLOCATABLE objects is not accessible to the user. ALLOCATABLE objects, >therefore, cannot be aliased with other objects as a result of pointer >assignments. For this reason, they behave much better than pointers with >respect to optimization. > Given the benefits of ALLOCATABLE, it appears advisable to extend the >facility to handle derived type components as well as normal variables. The >extension introduces little additional complexity into either the language >definition or implementation; in fact, one can argue that the generalization >serves to remove an arbitrary restriction from the language. > The duties of the implementor follow directly from current practice. >If a local object has the ALLOCATABLE attribute, the implementation must >arrange to set the object to non-allocated status at the time that the object >is created. This duty is now extended to components of derived type objects. >In addition, if a derived type object with an ALLOCATABLE component is itself >created via an ALLOCATE statement, the component must be set to non-allocated >status as part of the creation. > There exists some complication with regards to constructors. There is >no "null" value for an allocatable object, so the constructor must specify an >actual value set for an allocatable component. (This will generally be an >array constructor with an implied DO to provide the right number of elements.) >(Note that, even though "assignment semantics" apply, this value cannot be >given as a scalar, as there is no size given in the type definition.) > The value of the constructor will include the allocatable component in >an "allocated" state with the indicated contents. Note that the rules of >assignment for allocatable arrays involve copying the contents, not the >implicit pointer. Thus, if the constructor is used in an assignment >statement, the allocatable components of the target variable must already be >allocated. > Lastly, because allocation cannot be done prior to execution, >allocatable components cannot be initialized in DATA statements or with = >initialization. > (Note that some of these conditions may be changed slightly if we >approve the proposal for constructors with keyword and optional fields.) Can a structure with an allocated component of zero size be assigned to a structure where the corresponding component has not been allocated? If not, why not? I would find such a restriction quite artificial, and I would expect many implementations to make such an obvious extension. If such an assignment _is_ allowed, why can't allocated components be initialized with zero-sized array constructors? I think the inability to initialize the non-allocatable components of such a structure except via default initialization is a serious flaw. > >Detailed EDITS: > aeaenote: edits are marked with a brief comment about the particular > subject area being addressed. In some cases, a subject area > is relevant but requires no edits; in such cases, a null edit > (plus comment) is given. aaaa > >AEthroughoutAA aegeneral nomenclatureaa > aeno problem. The Standard references the term "allocatable array" > throughout. There is no problem, in general, with this terminology > applying equitably to either data entities or to components; so no > pervasive change is required.aa > >Subclause 4.4 >AE32:28AA aemake allocatable components ultimateaa > after: "Ultimately, a derived type is resolved into ultimate > components that are" > change: "either of intrinsic type" > to: "of intrinsic type, are allocatable," > >Subclause 4.4.1 >AE33:20AA aedefinition of component-attr-specaa > after: "R427 component-attr-spec is POINTER" > add new line: > " or ALLOCATABLE" > >AE33:26AA > add a new constraint following the third constraint of R427: > "Constraint: POINTER and ALLOCATABLE must not both appear in > the same component-def-stmt." > >AE33:26+AA aeaeWG5: Since allocatable components prohibit appearance in > storage-associated contexts, do not allow sequence types to > contain allocatable components.aaaa > add a new constraint following the above: > "Constraint: The ALLOCATABLE attribute must not be specified if > SEQUENCE is present in the derived-type-def." > >AE33:31-32AA aeWG5(reworded):dimension infoaa in the first constraint of R429, > change: "If the POINTER attribute is not specified" > to: "If neither the POINTER attribute nor the ALLOCATABLE attribute is > specified" > >AE33:33AA aeWG5(reworded):dimension infoaa > in the second constraint of R429, > change: "POINTER attribute" to "POINTER attribute or the ALLOCATABLE > attribute" > >AE33:38+AA aedefault initialization, per 94-138aa > after: "the POINTER attribute must not appear" > add: "and the ALLOCATABLE attribute must not appear" > >AE33:39AA aesequence typesaa > aeaeWG5: No changes needed. A sequence type cannot have allocatable > components.aaaa > >AE34:2AA aewhen one needs to have "::" in a component definitionaa > change: "or both" > to "the ALLOCATABLE attribute, or any combination thereof" > >AE35:35+AA aeedits to object initialization proposal in 94-009.006aa > in paragraph 3 (immediately following the first example in this edit), > after: "If a component is of intrinsic type and is not" > insert: "allocatable or" > aeaebefore "a pointer, a default initial value may be specified..."aaaa > later in the same paragraph, > after: "If the component is of derived type and does not have the" > replace: "pointer attribute" > with: "ALLOCATABLE attribute or POINTER attribute" > >AE35:35+AA aeexamplesaa > add new paragraphs: > "A derived type may have a component that is allocatable. For example: > > TYPE STACK > INTEGER :: INDEX > INTEGER, ALLOCATABLE, DIMENSION(:) :: CONTENTS > END TYPE STACK > > For each variable of type STACK, the shape of the component CONTENTS > is determined by execution of an ALLOCATE statement." > >Subclause 4.4.4 >AE37:28AA aeconstructorsaaaeaeWG5: Interaction with 94-009.006 in last sentence of > this additionaaaa > Add, at the end of this subclause, new paragraphs: > "Where a component of the derived type is an allocatable array, the >corresponding constructor expression must evaluate to an array. The value of >the constructor will have a component that is allocated (has an allocation >status of allocated), and with contents as given by the constructor >expression. Note that the allocation status of the allocatable component is >available to the user program if the constructor is associated with a dummy >argument, but generally not for other uses. Note, also, that when the >constructor value is used in assignment, the corresponding component of the >target must already be allocated. > >Where a derived type contains an ultimate allocatable component, the >constructor must not appear as a data-stmt-constant in a DATA statement >(5.2.9), as an initialization-expr in an entity-decl (5.1), or as an >initialization-expr in a component-initialization (4.4.1)." AESee above comments on unallocated vs. zero-sized allocated components.AA > >Subclause 5.1 >AE40:5AA ae=initializationaa > after: "an allocatable array," > add: "a derived-type object containing an ultimate allocatable > component," If the intent was to prohibit dummies and functions results from containing ALLOCATABLE subobjects, the constraint at lines AE40:8-9AA needs to be generalized. > >AE40:20AA aeaddition to constraint so it is clear they cannot be initialised at > compile timeaa > after: "allocatable arrays," > add: "derived-type objects containing an ultimate allocatable > component," > >Subclause 5.1.2.3 >AE44:24+AA aeedit to interpretation edit, paper 94-274r1aa > change: "a stat-variable" > to: "an allocate-object or stat-variable" This text pertains to the INTENT attribute which is only permitted for dummy arguments, so if the intent was to prohibit dummies from containing ALLOCATABLE subobjects, this edit should be deleted. > >Subclause 5.1.2.4.3 >AE46:8AA aeallocatable arrays are no longer necessarily namedaa > in the first line of the second paragraph, change: "a named array" to > "an array" > >AE46:10AA aeshape of an allocatable component can also be determined by a > structure constructoraa > add to end of sentence: > "or evaluation of a structure constructor for a derived type with an > allocatable component" > >AE46:11AA aewhere & how you can declare ALLOCATABLEsaa > after: "in a type declaration statement" > add: ", a component definition statement," > >AE46:13AA aedittoaa > after: "in a type declaration statement," > add: "a component definition statement," > >AE46:15AA aedittoaa > after: "type declaration statement" > add: "or a component definition statement" > >Subclause 5.1.2.9 >AE48:24AA aestorage units, sequenceaa > aeWG5: This change has been deleted as unnecessary since derived type > objects containing allocatable components cannot appear in > COMMON or EQUIVALENCEaa. > >Subclause 5.2.9 >AE52:34AA aeDATA statement restrictionsaa > change: "or an allocatable array" > to: "an allocatable array, or a derived-type object containing an > ultimate allocatable component" > >Subclause 5.4 >AE56:11AA aeWG5: do not allow allocatable components in NAMELISTaa > change: ", or an allocatable array" > to: ", an allocatable array, or a derived-type object containing > an ultimate allocatable component" >Subclause 5.5.1 >AE57:1AA aeWG5: do not allow allocatable components in EQUIVALENCEaa > after: "an allocatable array," > add: "a derived-type object containing an ultimate allocatable > component," > >Subclause 5.5.2 >AE58:30AA aeaeWG5: allocatable components are not allowed in COMMON since they are > excluded from sequence typesaaaa > >Subclause 5.5.2.3 >AE59:42+AA aeCommon Associationaa > aeaeno edit needed; not allowed in COMMONaaaa > >Subclause 6.1.2 >AE63:8AA aecorresponding restriction to that preventing array ops on pointer > componentsaa > after: "attribute" > add: "and must not have the ALLOCATABLE attribute" > >Subclause 6.3.1 >AE67:16AA aeallocate statementaa > aeok - because POINTER components were allowedaa > >Subclause 6.3.1.1 >AE68:1+AA aeallocation of allocatable arrays - initial statusaa > aeok, existing text appears to be sufficientaa > >AE68:7+AA aeaeWG5: Specify initial state of allocatable components after ALLOCATEaaaa > Add new paragraph at the end of this subclause: >"If an object of derived type is created by an ALLOCATE statement, any >ultimate allocatable components have an allocation status of not currently >allocated." > >Subclause 6.3.3.1 >AE69:8AA aedeallocationaa > add footnote: "Allocatable array components of derived-type objects > with the SAVE attribute also retain their allocation > status." > aeaenote: similar issue for 69:29, for pointers aaaa > >AE69:9AA add list items and renumber > "(2) An allocatable array that is part of the return value of a > function, > (3) An allocatable array that is part of a dummy argument," > >Subclause 7.1.6.1 >AE77:40AA aeaeremove derived-type constructors with allocatable array components > from initialization exprsaaaa > after: "(3) A structure constructor where each component is an > initialization expression" > add: "and no component has the ALLOCATABLE attribute" > >Subclause 7.5.1.5 >AE91:20AA aeinterpretation of intrinsic assignmentaa > after: "nonpointer components." > > add: "Note that for allocatable components the component in the > variable being defined must already be allocated, and the shapes > of the corresponding allocatable components of the variable > being defined and the expression must be the same." AESee above comments on unallocated vs. zero-sized allocated components.AA > >Subclause 9.4.2 >AE124:17AA aewe do not allow derived-types with pointer components in i/o > statements, neither should we allow ones with allocatable componentsaa > after: "If a derived type ultimately contains a pointer component" > add: "or allocatable component" I don't see any need for this restriction -- see my further comments in the rationale section, below. > >Annex A >AE254:12-13AA aeFix glossary copy of the definition of an allocatable arrayaa > change: "A named" > to: "An" > append to end of definition: > "An allocatable array may be a named array or a structure > component" > >AE261:21-22AA aeFix glossary copy of the definition of ultimate componentaa > after: "a component that is of intrinsic type" > add: ", has the ALLOCATABLE attribute," > >AE261:23AA > after: "does not have the" > add: "ALLOCATABLE attribute or" > >add to Rationale Section: >------------------------------ >5.1.2.9 ALLOCATABLE attribute > > Allocatable arrays provide a degree of flexibility intermediate >between that of automatic arrays and pointers. The bounds of an automatic >array can be calculated on non-constant values, but only at scope entry. >Often, this is not sufficiently powerful; nor does it provide for SAVEd arrays >whose size is not given by a constant expression. Pointers do provide the >facility to arbitrarily determine the array bounds by execution of an ALLOCATE >statement. Because of the pointer assignment statement, pointers are a little >less closely controlled than allocatable arrays. More than one pointer may be >associated with a given object, a condition known as "aliasing" which can >negatively impact optimizing compilers. Pointers also allow memory leaks if >not properly deallocated. > Array variables, and components of derived types, can be specified as >ALLOCATABLE when it is desired to calculate their size as a function of some >value determined during execution. > Explicit initialization of allocatable arrays is not permitted for >SAVEd variables, because such initialization may take place prior to >execution, but the ALLOCATE action only occurs during execution. AESee above comments on unallocated vs. zero-sized allocated components.AA > Input/output of derived types containing allocatable components is not >permitted. This is because the storage of an allocatable component is >typically far removed from that of the other derived type components, so it >would be a non-trivial burden to the implementor for unformatted i/o. ... This argument is specious -- an ALLOCATABLE component is no more difficult for the implementer to deal with than an extra ALLOCATABLE array in the i/o-list > ... Also, >for derived types containing allocatable components, as for derived types >containing pointer components, the i/o action desired by the user is unlikely >to be that which can be provided automatically. ... Perhaps, but the same argument can be made for _any_ derived type, not just those containing pointers. I believe the real problem with pointer components is the possibility of circular links. > ... User-defined i/o of derived >types is not part of this standard but we wish to avoid adding a facility >which will be little used and likely to conflict with the addition of the >proper facility in a later revision of the standard (or as a vendor >extension). I'm not so sure that it would be little used -- though pointer components will often be used to build lists, trees, and other complex structures for which the intuitively "right" style of I/O is unclear, ALLOCATABLE components cannot be used in such ways. I would guess that most of the time ALLOCATABLE components will be used just like any other ALLOCATABLE array, and that I/O will therefore be handled similarly. In any case, why would default I/O for ALLOCATABLE structure components be any more likely to conflict with some possible future extension for user-defined derived type I/O than the default I/O we have currently for ordinary structures? > Allocatable arrays were not permitted in storage-associated contexts >(NAMELIST, COMMON, EQUIVALENCE) in Fortran 90. This restriction still holds, >and thus objects of derived type containing allocatable components are also >not permitted in such contexts. For this reason, and because the primary >purpose of SEQUENCE is to allow derived-type objects to appear in such >contexts, allocatable components are not permitted in sequence derived types. > > >==========================end of text for part 1============================== -- Leonard J. Moss o/ My views don't necessarily Stanford Linear Accelerator Center o/ reflect those of SLAC, MS 97; P.O. Box 4349; Stanford, CA 94309 o/ Stanford or the DOE