From J.L.Schonfelder@liverpool.ac.uk Thu Jan 12 10:07:24 1995 Received: from mailhub.liverpool.ac.uk (mail.liv.ac.uk) by dkuug.dk with SMTP id AA18656 (5.65c8/IDA-1.4.4j for ); Thu, 12 Jan 1995 11:08:09 +0100 Received: from pop.liv.ac.uk by mail.liv.ac.uk with SMTP (PP); Thu, 12 Jan 1995 10:07:29 +0000 Date: Thu, 12 Jan 1995 10:07:24 GMT From: Lawrie Schonfelder Subject: Re: (SC22WG5.674) Re: informal ballot of 17 defect responces To: SC22WG5@dkuug.dk Message-Id: Priority: Normal Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Charset: ASCII X-Char-Esc: 29 On 11 Jan 1995 07:26:14 -0500 (CDT) Dick Hendrickson wrote: > From: Dick Hendrickson > Date: 11 Jan 1995 07:26:14 -0500 (CDT) > Subject: (SC22WG5.674) Re: informal ballot of 17 defect responces > To: SC22WG5@dkuug.dk > > A couple of weeks ago Lawrie voted NO on defect item 100 and offered an > explanation for his vote. Since I originally agreed with his opinion, > in fact the first version of the response that I wrote had a mathematical > "proof" that .TRUE. was the correct answer, I'll try to explain why I > changed my mind. > > Basically I was convinced that obvious rules that apply to zero-sized > sections of an array are obviously wrong when applied to zero-sized > sections of different arrays. Lawrie says: > > The rule for all zero-sized objects is that they should behave as the obvious > limiting case when one of the extents goes to zero. Behaviour should NOT be > discontinuous. The proposed edits in 100 violate this rule." > > Consider: > > REAL, TARGET :: A(10),B(10) > POINTER C(:) > > C => A(I:5) > print *, ASSOCIATED (C, B(I:5) > > This will print .FALSE. for I <= 5 and .TRUE. isn't an "obvious limit" > when I becomes > 5. You might argue that the "base address" is different > for A and B; but, the standard doesn't define base addresses and there doesn't > seem to be a natural way to define them. We might not want to define an implementation concept such as base address, but it beggers belief that sections of two different named variables not otherwise associated could ever be the same target. I simply dont accept that we cannot draft a definition that can handle this correctly. Consider: > > Parameter (N = some expression) > common D(10), E(N), F(N), G(10) > > C => E > > Most people would think E and F always have different base addresses, after > all they are different arrays. It's surprising to think that > ASSOCIATED (C, F) will be .TRUE. for N <= 0. Surely the associations that exist for reasons other than pointer/target relationships should also be significant in determining the result of the ASSOCIATED function. Since COMMON creates a storage sequence and associations by storage association these have to be significant. I would find it odd if E and F were not associated in this case for N=0. So I think TRUE is a perfectly logical result. > > It's as bad for sections of two dimensional arrays, consider: > REAL, TARGET :: H(10,10) > > C => H(5, I:5) > print *, ASSOCIATED (C, H(6,I:5)) > > Surprising to have this be .TRUE. for I > 5 Absolutely! The responce here should be false for all values of I. Why should I=4 produce a true result Row 5 is not associated in any way with row 6 of H. > > The answer is that there isn't a good answer. We had to pick something > and .FALSE. seems to be "correct" for lots of cases. I dont agree that there is not a good answer. There is it is just somewhat tricky to describe, but that is no justification for giving a simple blanket answer that is manifestly wrong in many if not most cases. > I would rather go along with Richard and make the result processor defined rather than mandate a wrong answer from everyone. At least then some careful vendors could do it right. As it is proposed everyone would have to provide defined but wrong and misleading results. However, I do not accept that a description that provides the correct limiting cases cannot be devised. I will continue to vote NO on this interpretation. -- Dr.J.L.Schonfelder Director, Computing Services Dept. The University of Liverpool, UK e-mail J.L.Schonfelder@liv.ac.uk phone: +44(51)794-3716 fax: +44(51)794-3759