From bleikamp@mozart.convex.com Tue Feb 14 02:21:20 1995 Received: from convex.convex.com by dkuug.dk with SMTP id AA11677 (5.65c8/IDA-1.4.4j for ); Tue, 14 Feb 1995 15:21:27 +0100 Received: from mozart.convex.com by convex.convex.com (8.6.4.2/1.35) id IAA14869; Tue, 14 Feb 1995 08:21:22 -0600 Received: from localhost by mozart.convex.com (8.6.4/1.28) id IAA02459; Tue, 14 Feb 1995 08:21:20 -0600 From: bleikamp@mozart.convex.com (Richard Bleikamp) Message-Id: <199502141421.IAA02459@mozart.convex.com> Subject: comments on J.R.'s comments on defect item 173 To: sc22wg5@dkuug.dk (sc22wg5@dkuug.dk) Date: Tue, 14 Feb 95 8:21:20 CST X-Mailer: ELM [version 2.3 PL11] X-Charset: ASCII X-Char-Esc: 29 I'd like to respond to John's comments on interp #173. The phrasing in the interp in the current letter ballot prohibits an INTENT OUT or INOUT argument from being "storage associated" with any other argument (for elemental intrinsics?). John has suggested a different wording, which uses "associated", to capture all forms of association (mostly pointer association i suspect, i don't believe any form of name association applies here [i.e. argument, host, use]). John also included the words "any part of any other actual argument" to emphasize the "partial" overlap issue. In some (private) e-mail, John mentioned that "storage association" is more likely to evoke thoughts of EQUIVALENCE, and not so likely to evoke considerations of pointer association. John also prefers the phrase "partial overlap", to make it clearer what we intended to disallow. While I agree with John's points about storage association and partial overlap, I don't think that is relevant. The current wording (in the letter ballot) is technically correct and precise. If any elements of the two arguments of interest are pointer associated, or (partially) overlap in any way, then the two arguments ARE storage associated. I also think pointer association is not very relevant here. The only pointer association that causes partial overlap is when two ELEMENTS of the array valued arguments are pointer associated with each other, NOT when the two arguments are pointer associated. That is confusing, and not made any clearer by the wording change which eliminates "storage" from "storage association". I believe the wording for interp 173 in the letter ballot is both accurate and sufficient. And while I think John's proposed response is also ok, I object to using different words in different places when we mean the same thing. We chose to use certain (admittedly obtuse) phrases for some concepts; however, once we've defined and used such a phrase in a precise and correct manner, then it is inappropriate to further elaborate on that phrase (except in an occasional note or in annex C), even when it appears confusing to the casual (or not so casual) reader. If the phrase is confusing, we should take Dick W's advice, and rewrite all the parts of the standard which use that phrase; rather than "patching" a few places piecemeal. Some of the committee will disagree, and argue that the standard should be readable by an educated user. Although I agree this is desirable, we failed in that task when we did F90. Trying to fix up a little piece at a time is a complete waste of time, and will lead to a longer standard, where the same concept is described in different ways in different places. This will confuse some readers, who will wonder what the intended difference is, since we used different words. We do NOT have a standard which is easily readable by the average engineer. And the standard cannot address that audience without a substantial rewrite. Also, the standard is far too expensive to consider it as a text for learning Fortran. No one is going to part with that much money when a much cheaper text is readily available. We need to be precise, but there is no need to use different words than are already well defined in the standard to clarify what we mean. Rich (with apologies for taking so much of your time)