From malcolm@num-alg-grp.co.uk Fri Sep 2 23:23:07 1994 Received: from ben.Britain.EU.net by dkuug.dk with SMTP id AA03155 (5.65c8/IDA-1.4.4j for ); Fri, 2 Sep 1994 23:23:07 +0200 Received: from iec.co.uk by ben.britain.eu.net via JANET with NIFTP (PP) id ; Fri, 2 Sep 1994 17:18:58 +0100 Received: from mars.nag.co.uk by nags2.nag.co.uk (4.1/UK-2.1) id AA00409; Fri, 2 Sep 94 17:17:35 BST From: Malcolm Cohen Message-Id: <652.199409021614@mars.nag.co.uk> Received: by mars.nag.co.uk (5.65c/UK-2.1) id AA00652; Fri, 2 Sep 1994 17:14:39 +0100 Subject: Re: X3J3 letter ballot on three items To: SC22WG5@dkuug.dk (SC22/WG5 Mailing List) Date: Fri, 2 Sep 94 17:14:35 MET X-Charset: ASCII X-Char-Esc: 29 Dear Len, I have some comments to make on your comments (on 94-269r2). > > 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 Actually this would be very easy; it would be exactly the same as the time one gets the storage back for any non-pointer array-valued function. And one would never "auto-dealloc" an ALLOCATABLE dummy - it is when the actual goes out of scope. > 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. Er... this paragraph merely points to a separate paper (on which you voted YES). As explanatory text it is certainly not setting up any requirement in itself. [...] > > 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 Yes, this was the position reached by meeting 129 (i.e. the one before last). As such it was treated as a recommendation to WG5 that ALLOCATABLE dummies and function results not be proceeded with for Fortran 95. > 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 I agree with you that leaving these out will not significantly reduce the complexity of implementations but I do think it reduces the complexity of the standard. Anyway, WG5 has decided that allocatable components are a requirement for F95. If X3J3 can do the extra work to allow allocatable dummies and function results in the time available I am sure that WG5 would accept this in the same spirit in which user-defined elementals is being treated. [...] > > - 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. Yes, this text should probably be struck since it is referring to a proposal which is not to be in F95. > >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 Because we are following the existing model for allocatable arrays in the Fortran 90 standard. Currently, if one has an allocatable array name on the LHS of an assignment it must be allocated with the shape conformable to that of the expression on the RHS. > artificial, and I would expect many implementations to make such an > obvious extension. If such an assignment _is_ allowed, why can't This extension is just as obvious and the restriction is just as artificial as for allocatable arrays now. Adding such a facility in F95 or F2000 is not precluded by 94-269r2, but allocatable arrays should be treated consistently whether or not they are components. Also, in the case of derived types the user has the opportunity to define their own assignment with their required semantics, so I do not believe this to be a serious problem. [...] > > 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 Not so: an extra allocatable array (which does not contain allocatable components!) is a single contiguous object. A derived-type object containing allocatable components (some of which could contain allocatable components of their own) will have its storage scattered throughout memory in a tree-like fashion. [...] > I believe the real problem with pointer components is the possibility of > circular links. Certainly that is a problem which allocatable components cannot have; however the Fortran 90 standard goes much further than prohibiting circularity (it does not even allow i/o on derived-type objects containing pointers to intrinsic types -- which cannot possibly be circular!). -- ...........................Malcolm Cohen, NAG Ltd., Oxford, U.K. (malcolm@nag.co.uk)