From bleikamp@mozart.convex.com Fri Feb 17 04:48:31 1995 Received: from convex.convex.com by dkuug.dk with SMTP id AA16569 (5.65c8/IDA-1.4.4j for ); Sat, 18 Feb 1995 12:38:43 +0100 Received: from mozart.convex.com by convex.convex.com (8.6.4.2/1.35) id KAA11013; Fri, 17 Feb 1995 10:48:34 -0600 Received: from localhost by mozart.convex.com (8.6.4/1.28) id KAA16037; Fri, 17 Feb 1995 10:48:32 -0600 From: bleikamp@mozart.convex.com (Richard Bleikamp) Message-Id: <199502171648.KAA16037@mozart.convex.com> Subject: Re: (SC22WG5.715) defect item 173 To: jkr@letterbox.rl.ac.uk (John Reid) Date: Fri, 17 Feb 95 10:48:31 CST Cc: SC22WG5@dkuug.dk In-Reply-To: <199502171106.AA11480@dkuug.dk>; from "John Reid" at Feb 17, 95 11:05 am X-Mailer: ELM [version 2.3 PL11] X-Charset: ASCII X-Char-Esc: 29 'John Reid' wrote: > > ... > > Let me try another tack. This is very closely related to 12.5.2.9. Indeed, > it might be argued that in view of 12.5.2.9, no edit is needed. The > wording there [180:3-4] is: > ... I agree, EXCEPT that the whole point of this interpretation was to make an exception to this general rule, for the MVBITS elemental intrinsic subroutine. There is no need to re-describe the prohibitions, except to give some CONTEXT for the case we want to allow. There was no intent to introduce additional restrictions on argument association (or any other association). If MVBITS weren't defined the way it was in MIL-STD 1753 (erroneously from a Fortran purists point of view), we wouldn't be wasting all this time. Having reached a more than adequate level of frustration and confusion, I'm tempted to suggest we shoot both this interpretation and the person who wrote MIL-STD-1753 (maybe Henry K. can arrange this :):):):). Seriously though, I finally see John's point, and I apologize for being so dense. However, I still don't agree with John, except that some rewording might be appropriate to make it clear that the "values" of the actual arguments are what cannot be storage associated (and I don't think John's edits make that any clearer). But I'd also be happy with deleting this whole discussion of storage association, if we can provide some other way of allowing the TO and FROM arguments to reference the same . My view of POINTERs is that an object with the pointer attribute has two distinct storage sequences associated with it: - the storage for the pointer, as described in 14.6.3.1 (8), and - the storage of its target (when the pointer is associated) and in the context of an actual argument, when the "argument associated" dummy arg does not have the POINTER attribute, the "actual argument" is not the pointer, but rather the target. In the rest of the standard, presumably we talk about the target when appropriate, and the data object with the pointer attribute when appropriate, but I can't find any text which clearly makes this distinction for actual arguments. > > Surely, it would help the reader to use the same form of words for the > new text. I'd be happy with [180:2-4], if paraphrased somewhat. It would be awkward to add the exception of MVBITS to these phrases as is. But the edit in the ballot is not wrong, its just not complete. I think we should pass 173 NOW, WITHOUT any substantial edits, as long as it doesn't invalidate anything in the standard, or any users code. I'm suggesting this because of the timing with respect to Fortran 95. There is a real possibility that any interps which are NOT approved now (in this letter ballot) will NEVER be in a corrigenda against F90 (i realize there might not be a 3rd corrigenda anyways). It isn't clear to me that any interpretation processing will happen at the Maui meeting. Jerry is pushing hard to get F95 out on schedule, and is sacrificing interpretation processing to get there. I think the users deserve as many FIXES as we can provide for Fortran 90, and this is a FIX. It makes common existing practice (for MVBITS) legal, where F90 currently prohibits such code. So, I favor passing interp 173 AS IS for Fortran 90, and doing it better for F95 (I think we still have time for this, if WG5 instructs x3j3 to do so). Note that interp 173, whether it is passed or not, will NOT affect the 007, because the section being edited does NOT exist in the 007. Because the section being edited was deleted from 007, the proposed wording for the 007 was changed and inserted in a more general discussion of elemental (user and intrinsic) subroutines. This passed as a separate paper in Houston, not as part of approving the interpretation. In order to clarify this for F95, someone needs to write up a paper for the WG5 meeting, or someone who attends the WG5 meeting needs to make sure that the list of tasks for X3J3 to do at Maui includes changing this stuff in the 007. The current 007 wording (assuming the edits passed in Houston are applied) is: "In a reference to an elemental subroutine, the actual argument associated with INTENT(OUT) and INTENT(INOUT) dummy arguments must not be storage associated with any other actual argument, except that the FROM and TO arguments for the MVBITS intrinsic subroutine may be the same variable." This is still a correct statement (although incomplete), but the whole discussion of storage association is only there to provide context for which general prohibition is being overridden for the MVBITS intrinsic. No new restrictions are being introduced. Perhaps F95 should include something like this instead of the edit above: "The intrinsic subroutine MVBITS may be called with the same as the actual arguments corresponding to the TO and FROM dummy arguments. This is an exception to the general rule which prohibits actions that change the value of an entity associated with a dummy argument, except those actions taken through the dummy argument (12.4.1.6)." this is still awkward, feel free to fix it. Rich