From jwagener@amoco.com Mon May 17 12:41:26 1993 Received: from interlock.amoco.com by dkuug.dk with SMTP id AA02343 (5.65c8/IDA-1.4.4j for ); Tue, 18 May 1993 00:41:24 +0200 Received: by interlock.amoco.com id AA03997 (InterLock SMTP Gateway 1.1 for SC22WG5@dkuug.dk); Mon, 17 May 1993 17:35:24 -0500 Received: by interlock.amoco.com (Internal Mail Agent-2); Mon, 17 May 1993 17:35:24 -0500 Received: by interlock.amoco.com (Internal Mail Agent-1); Mon, 17 May 1993 17:35:24 -0500 Date: Mon, 17 May 93 17:41:26 CDT Message-Id: <9305172241.AA25877@trc.amoco.com> From: Jerrold L. Wagener To: SC22WG5@dkuug.dk Subject: a simple requirement X-Charset: ASCII X-Char-Esc: 29 To X3J3 and WG5 - I have been meaning to draft a "requirement" along these lines, and especially meant to get it done by last week in order to have it placed in the X3J3/93-004 document no later than the X3J3 meeting. I missed that deadline, but was able to put something together over the weekend. Len would you please register this in the 004 version that Jeanne distributes for the WG5 meeting. (It's written as an X3J3 paper, but assuming it makes it into the 004 I won't submit it as such.) Sorry for being late. Thanks. Jerry ------------------------------------------ Subject: Let's K.. I.. S.. S.. (A Suggestion for Fortran 95) From: Jerry Wagener The premise of this note is that the KISS principle (Keep It Simple, Stupid) is increasingly important for computer languages. A refinement of this principle, often known as KISMIF (Keep It Simple, Make It Fine), summarizes the yin and yang of quality. The focus here is on simplifying Fortran 95. One way to simplify a language is to remove unnecessary restrictions. This reduces the number of rules that users need to assimilate to become fluent in the language, and possibly simplifies implementation. The following suggested requirement for Fortran 95 proposes, in general, that every restriction of Fortran 90 be evaluated for possible relaxation or elimination in Fortran 95. Specific examples of such candidates include removal of all specification ordering restrictions in the of a program unit, no maximum on the number of characters in a name/line/statement, allowing redundant specification, and a number of other specific restrictions (often appearing as constraints). Another form of simplification is to remove obsolescent features. The syntax rules, and hence the structural complexity, can be considerably reduced, for example, by removing alternate returns and the obsolescent forms of the do construct. Yet another form of simplification is to remove unnecessary options. For example, unnecessary options in , , and complicate the syntax rules for these features. Virtually any form of simplification in the syntax rules and corresponding constraints makes the language more understandable, and hence usable, and simplifies implementation. Therefore unnecessary options that complicate the syntax should be considered for obsolescent status. The following item is therefore submitted for inclusion in the X3J3/93-004 document. NUMBER: TITLE: Keep It Simple, Make It Fine KEYWORDS: simplify, restrictions, syntax rules, constraints, obsolescent features STATUS: registered REQUIREMENT: Simplify Fortran 95 over Fortran 90 in (at least) the following ways. 1. Remove unnecessary restrictions such as a. all specification ordering restrictions in the , b. the maximum number of characters in a name, a line, a statement, c. the current disallowance of redundant specifications, and d. a number of other specific restrictions and constraints. 2. Remove those features identified as obsolescent in Fortran 90. 3. Make obsolescent those features associated with unduly complex syntax rules and/or constraints. Typical candidates are those parts (not necessarily all) of , , and that complicate the syntactical description of these features. JUSTIFICATION: Computer language technology continues to advance in sophistication, both in terms of definition and implementation. The viable general purpose languages of the future will be powerful yet easy to use. The users of the future will tolerate neither restrictions due to primitive conceptual and technological legacies from the past nor syntactic complexity burdened with a plethora of arcane and unnecessary rules. SUBMITTED BY: Jerry Wagener