From <@iec.co.uk:malcolm@num-alg-grp.co.uk> Mon Jun 24 18:27:11 1996 Received: from sun2.nsfnet-relay.ac.uk (sun2.nsfnet-relay.ac.uk [128.86.8.45]) by dkuug.dk (8.6.12/8.6.12) with ESMTP id SAA09862 for ; Mon, 24 Jun 1996 18:26:27 +0200 Via: uk.co.iec; Mon, 24 Jun 1996 17:25:56 +0100 Received: from mars.nag.co.uk by nags2.nag.co.uk (4.1/UK-2.1) id AA02475; Mon, 24 Jun 96 17:31:22 BST From: Malcolm Cohen Message-Id: <2438.199606241623@mars.nag.co.uk> Received: by mars.nag.co.uk (5.65c/UK-2.1) id AA02438; Mon, 24 Jun 1996 17:23:18 +0100 Subject: Re: Allocatable Components Liaison Report To: sc22wg5@dkuug.dk (wg5) Date: Mon, 24 Jun 96 17:23:13 MET DST The liaison report opens with: > This TR appears to be complete except for one major objection > and a few relatively minor comments. But the gist of the report is otherwise; that the TR is in no sense "complete". Indeed, since the liaison report requests a technical change and additional (normative) text it is hard to see how it can get "primary development body approval" prior to the upcoming WG5 meeting. > After having seen two iterations of the concept of automatic > deallocation and reallocation for assignment to entities with > allocatable components X3J3 believes this feature should be > dropped from the TR. It should be the user's responsibility to I am deeply disappointed with this decision, particularly with the lack of technical justification in the liaison report. Why this change of heart after the previous meeting apparently voting that something should be included on this? > ensure that the left-hand and right-hand component arrays have > the same shape, just as must be done for ordinary arrays. Yes, but not as it must be done for POINTER arrays! Have people already forgotten that allocatable array components will be replacing POINTER array components in user programs, not fixed-size array components? If we disallow automatic (re)allocation, new text needs to be added to 7.5.1.5 to specifically allow assignment of unallocated array components (or does X3J3 dislike that as well?). And a footnote explaining that assignment of allocatable array components is useless, so the user is going to have to define their own. > We'd prefer to have the word "minimal" dropped from the various > "Implementation Cost" sections. If you drop this, the text no longer says what the implementation cost is and simply becomes a thumbnail sketch of the obvious implementation technique. If there really is objection to this word that has been in the text from the beginning, we may as well delete the "Implementation Cost" section altogether. > There needs to be a discussion, and probably text added to the > standard, discussing the ENTRY statement in an allocatable > function. Why? I see no special text in the standard for ENTRY in an array function that does not apply to an allocatable array function. Presumably whoever brought this up has some particular concern in mind - what is it? > We're concerned about the extension to NULL() to include > unallocated arrays. This is a confusing overload, but we do not > have a suggested change. I am surprised that you have found it confusing this time when there was no comment about it at the previous meeting. I do not agree that it is a confusing overload - the "unallocated" status of an allocatable array is exactly analogous to the "nullified" status of a pointer. > The example for REAL_POLYNOMIAL_MODULE contains many errors. Thank you. Note that if automatic (re)allocation is to be forbidden, this example will get even longer. > The last sentence in Note 4.34.1 appears to be a hangover from > text when automatic (re)allocation was not allowed. Yes, so presumably you want it to stay. > The phrase "associated with a dummy argument" (two places) is > confusing. Can it be reworded to include something like "an > actual argument associated with a corresponding dummy", > especially in the clarifying note. I disagree that it is confusing. The standard already uses this term (see 12.4.1.6, where it appears both in the section heading and in the text). How about replacing the first sentence of Note 4.34.1 with "When the constructor is an actual argument, the allocation status of the allocatable array component is available through the corresponding dummy argument."? > In some cases the ":" is missing after "Example". There should, I think, be no colon after "Example" (section 3.2). Thanks for spotting the irregularity. -- ...........................Malcolm Cohen, NAG Ltd., Oxford, U.K. (malcolm@nag.co.uk)