From drlevine@apollo.hp.com Fri May 31 22:34:03 1996 Received: from amway.ch.apollo.hp.com (daemon@amway.ch.apollo.hp.com [15.254.24.2]) by dkuug.dk (8.6.12/8.6.12) with ESMTP id WAA28311 for ; Fri, 31 May 1996 22:33:47 +0200 From: drlevine@apollo.hp.com Message-Id: <199605312033.WAA28311@dkuug.dk> Received: from hillside.ch.apollo.hp.com by amway.ch.apollo.hp.com id Fri, 31 May 1996 15:57:07 -0400 Received: by hillside.ch.apollo.hp.com id ; Fri, 31 May 1996 15:57:06 -0400 Date: Fri, 31 May 96 15:57:05 EDT Subject: New Candidates For Obsolescent Language To: sc22wg5 NEW CANDIDATES FOR OBSOLESCENCE I'd like to put forward, for discussion, some additional candidates for the "obsolescence" list. These candidates are particularly interesting because their presence in the language introduces a level of complexity into the language processor which, in turn, negatively impacts the runtime efficiency of Fortran programs. In some cases, portability is also affected. The general notion is to tighten up the rules for storage association and argument association. I'd hope that this material can find its way into the F2000 discussion. Note that there is no new-feature development effort required... 1. Storage association between objects of different size. Summary: Fortran allows (and specifies) storage association between numerical objects of different sizes in some cases. This allows various sorts of constructs which are inconsistent with modern computer architecture, with modern programming practice, and with optimization. Rationale: The storage association rules date back to a day in which memory was scarce, and came in discrete units usally called "words". It's time to modernize. The worst rule is the one which overconstrains the allocation of memory, namely the one which allows REAL and DOUBLE PRECISION variables to be storage associated. As a result, a conforming processor is not able, in the general case, to allocate memory so that data is properly aligned for the hardware. The resulting runtime inefficiencies are unacceptable for a performance-oriented application. It is not expected that many programs would be affected. What utility is there is the existing feature? Some people use COMMON in order to reuse static memory (an old programming technique); but the need to insure storage association among different-sized objects is of little or no positive benefit. Modifications Needed: A little restructuring of some of the description and rules of storage association will provide the desired identification of the obsolescent material. (Unlike some of the other obsolescent features, this one is not so easily identified with a piece of syntax.) Basically, we need to extend the existing prohibition on mixed-type association so that it also excludes mixing DOUBLE PRECISION with default REAL or default INTEGER. Then, we add -- as obsolescent -- additional language to allow the additional cases. For EQUIVALENCE, it's the second constraint [67:3-5] which needs modification; the base language should be more like [67:12-13]. For COMMON association similar modifications at [70:10-12] 2. Remove scalar to array argument association Summary: The standard currenly allows an actual argument of an array element when the corresponding dummy argument is an array. This should be made obsolescent. Rationale: An array element is almost universally considered to be a scalar, and rightly so. It's a real abberation to allow this "scalar" to be a synonym for the array of which it is a part. We have better language to express that now (slices). The abberation not only leads to badly structured programs, but it confuses the language processor. The result is lower performance. (In particular, an optimizer should be able to tell, at a call site, whether the called procedure has access to more than the one element.) Modifications needed: Change the text on [201:10-12] so that the "unless..." phrase is obsolescent. 3. Restrict array reshaping at procedure boundaries Summary: The standard currently allows a wide range of implicit array shaping to occur as part of argument association. This should be removed in favor of normal type equivalence. Overview and Discussion The standard has a set of consistent rules concerned with type matching, shape matching, and conformance. Yet an array actual argument can match up with a dummy of totally different rank, shape, even length. The new language has features like slices and RESHAPE that make this abberation unnecessary. Modifications Needed: Primarily, on [200:5], the words "an assumed-shape" should be obsolescent, so that the normal text reads "If the dummy argument is an array, the rank of the dummy argument shall agree with the rank of the actual argument." Some of [200:7:14] probably needs work, too, to capture a small additional case. 4. Remove mixed-type form of multi-entry functions Summary: Multi-entry procedures introduce a disproportionate amount of complexity into an implementation. Obsoleting the more flagrant mixed-type situations will help greatly. Rationale: Multi-Entry functions have a dubious role in a modern programming language. The current situation provides ill-advised generality in allowing the different entry points to return values of different types, and further by specifying an equivalence relationship between the different return variables. Let us restrict the sitatuation so that all entrypoints have to return values of the same type. Surely, that's what was intended: for instance, the traditional example is using the same code to compute SIN and COS. Modern computers have different registers and different calling conventions for data of different type. The generality allowed by the worst case leads to an implementation which is complex and inefficient at runtime, thus penalizing all users. Modifications Needed: Change the text on [209:41-44++] so that the base text specifies that the characteristics of the result of the function must match; then add text to allow the full behavior as obsolescent. (Much as was done for the storage association proposal, above.) David Levine HP Languages - Chelmsford drlevine@apollo.hp.com (508) 436-4015 -------