From jwagener@trc.amoco.com Wed Dec 9 03:52:54 1992 Received: from noc.msc.edu by dkuug.dk with SMTP id AA16050 (5.65c8/IDA-1.4.4j for ); Wed, 9 Dec 1992 16:53:00 +0100 Received: from uc.msc.edu by noc.msc.edu (5.65/MSC/v3.0.1(920324)) id AA17377; Wed, 9 Dec 92 09:52:59 -0600 Received: from [149.180.11.2] by uc.msc.edu (5.65/MSC/v3.0z(901212)) id AA09627; Wed, 9 Dec 92 09:52:57 -0600 Received: from trc.amoco.com (apctrc.trc.amoco.com) by netserv2 (4.1/SMI-4.0) id AA26710; Wed, 9 Dec 92 09:52:54 CST Received: from crmac1 by trc.amoco.com (4.1/SMI-4.1) id AA12277; Wed, 9 Dec 92 09:52:54 CST Date: Wed, 9 Dec 92 09:52:54 CST Message-Id: <9212091552.AA12277@trc.amoco.com> From: Jerrold L. Wagener To: chk@cs.rice.edu Cc: SC22WG5@dkuug.dk Subject: X3J3 comments on HPF X-Charset: ASCII X-Char-Esc: 29 Chuck, here is a slightly cleaned up version of the note I sent you yesterday. Have a good meeting - we're all looking forward to HPF-v1. Jerry ==================================================== Informal X3J3 Comments on HPF ----------------------------- X3J3 thanks all the participants in the HPF process. The result will be useful to the Fortran community. X3J3 is pleased that Fortran 90 was chosen as the HPF base language, and is happy to provide input on HPF. This review was based upon HPF-v04, albeit without the most recent set of intrinsic functions. What follows is the work of a subgroup of X3J3, as modified by email discussions following the November 1992 (New Haven) X3J3 meeting. This memo therefore represents informal input on HPF and not a formal X3J3 position. This particular review does not deal rigorously with technical or style issues but rather was performed from the following point of view: Assuming that HPF becomes highly successful, how hard will it be to integrate it into a future version of the Fortran standard? On this basis, in general the subgroup agrees in principal with most of the HPF design decisions. The following are a few concerns and observations, which may or may not be problems: 1) It was not obvious to the subgroup that storage association is not significantly modified in HPF, because of the apparent use of SEQUENCE to restore Fortran 90 semnatics. Previous attempts to make changes to storage association have met resistance. If a change is to be made in this area some sort of transistion mode may be necessary. 2) As has been observed in the HPF discussions, REALIGN could prove to be a poor "spelling" if moved from a pure directive/free format source form to traditional fixed format source. Selection of an alternative spelling might save some debate later. 3) HPF provides a new class of procedure, "PURE". Certainly this provides a needed solution for some of the challenges presented by block forall. It is not clear to the subgroup that there will be no interaction with existing properties of Fortran 90; for example, will "pure" constraints need to be checked (ala Fortran 90 constraints) or will certain programs merely be "non standard conforming"? As another example, it is not clear what the effect might be in the standard on I/O, which is disallowed in "pure" procedures. This is not to discourage the use of "pure" procedures in HPF; if they prove useful X3J3 will accept any corresponding responsibility. 4) It is not clear to the subgroup that EXTRINSIC procedures will have sufficient general applicability to be considered in a near term revision of standard Fortran. Currently the Fortran standard does not specify anything outside of the Fortran language itself; this policy might have to be reconsidered in order to include EXTRINSIC procedures. 5) Before it was discovered that the review copy had the wrong set of intrinsic functions, concern for increased namespace population prompted the subgroup, supported by straw vote in the full committee, to suggest that the namespace be managed in HPF by placing all HPF defined procedures, including intrinsic functions, in a special HPF module. This could even be true for the HPF subset, in which case the USE HPF statement could be made into a directive. Perhaps these comments are no longer appropriate for the current set of procedures. 6) INDEPENDENT and its NEW clause appear to address some of the problem space being addressed by X3H5. While this is not germane to HPF, X3J3 is a coordinating liaison for X3H5 and X3J3 will have to rationalize having multiple methods to get similar effects when trying to include HPF and X3H5 designs into a future revision of the Fortran standard. HPF questions for X3J3 ---------------------- 1) Why was block FORALL left out of S108? Even simple FORALL was eventually removed, so work on a more extensive/extended FORALL facility was not seen as viable at the time. X3J3 knows of no reason why block FORALL such as described in HPF cannot function in Fortran. As noted by HPF, and as "pure" procedures seek to solve, there are complications to be considered. 2) Why was nested WHERE not included? This was likely a case of trying to minimize new features and subsequently standardize any common extensions that might arise. Nested WHERE is widely viewed as an "obvious" vendor extension. Note that evolution of the Fortran standard was (and is) anticipated, and plans are sometimes made accordingly. 3) Why was MASK not defined to include scalars? Rightly or wrongly, it was thought that a scalar MASK was most naturally performed via looping and IF. If users and implementors believe otherwise, this certainly could be included in a future revision of the Fortran standard. One possible difficulty is the phrasing of the conformability requirements, since in many contexts scalars conform to any array shape. 4) Use SEQUENCE to describe "old style storage association"? Of course Fortran 90 does not use SEQUENCE generally for this purpose. A straw vote for such general use did not shed any light on this issue. That's probably because X3J3 has not really had an opportunity to come to grips with it. Certainly SEQUENCE is the right word to use for the purpose proposed in HPF, as it extends the concept as used in Fortran 90, though there is some sentiment in the subgroup for making the "old" way be the default and use additional syntax for the "new" way. 5) Directives or language extensions? While X3J3 has previously advised groups to extend syntax, a quick straw voted in this case favored the HPF directives over syntax. The subgroup nevertheless recommends that, if possible, the form of the directives be such that they could easily be made into syntax in the future; it appears as if the current directives in HPF are well designed in this respect. Jerry Wagener for X3J3