From jls@liverpool.ac.uk Wed Dec 15 12:54:14 1993 Received: from mail.liv.ac.uk by dkuug.dk with SMTP id AA07190 (5.65c8/IDA-1.4.4j for ); Wed, 15 Dec 1993 13:56:29 +0100 Received: from liverpool.ac.uk by mailhub.liverpool.ac.uk with SMTP (PP) id <29185-0@mailhub.liverpool.ac.uk>; Wed, 15 Dec 1993 12:54:21 +0000 From: "Dr.J.L.Schonfelder" Message-Id: <9312151254.AA16122@uxg.liv.ac.uk> Subject: Re: (x3j3.1993-437) Evolution of Fortran To: fortran@vnet.IBM.COM Date: Wed, 15 Dec 1993 12:54:14 +0000 (GMT) Cc: SC22WG5@dkuug.dk (SC22/WG5 members) In-Reply-To: <9312150552.AA27806@newton.ncsa.uiuc.edu> from "fortran@vnet.IBM.COM" at Dec 14, 93 09:50:20 pm X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 2597 X-Charset: ASCII X-Char-Esc: 29 Dick, I think you mis-understand the current conformance rule. A program is non-conformant if it uses any "forms and relationships" not defined in the standard. A processor is standard conforming if it executes all standard conforming programs according to the standard definition. A conforming language implementation MAY include additional forms and relationships to its hearts content as long as these do not conflict with any of the standard forms. A standard conforming program of course cannot. These rules are not and never have been symmetric. The F96 standard could delete, say, PAUSE from the language. No subsequent program that used PAUSE would be F96 standard conforming, but your compiler could continue to support PAUSE and still be F96 conforming. However you dont have to continue to support PAUSE to claim F96 conformance. The continuance of PAUSE in your products becomes a feature of your market segment not a requirement on all F96 processors. This is already the case it does not require a change in conformance rules. Of course it is possible that when new features are added to the language a conflict with a deleted feature could be introduced. This is why deleted features are described in an appendix so as to minimise the possibility of this at least for one revision. We basically therefore have a three stage multi-overlapping process for removing features from the language and eventually processors; it might even be considered as 4 stages. 1st revision. add a new better way of doing something 2nd revision. mark the old redundant feature as obsolescent 3rd revision. delete obsolescent feature, move to appendix 4th revision. possible introduction of new feature which causes a conflict Therefore, under current rules there is a minimum of 4 revision cycles before a feature could becomes unsupportable in a standard conforming processor. A user program may become non-standard after 3 revisions, and the programmer will have been given at least one revision warning of possible deletion. I know IBM has a very long "allow everything to continue to work" product update cycle, but as customer for the past 12 years we have more than once had incompatible product updates to deal with. The same has been true for all our other suppliers. The above elongated phase out evolutionary process is on the verge of excessive conservatism; more rapid evolutionary responce may be essential to survival. -- Dr.J.L.Schonfelder Director, Computing Services Dept. University of Liverpool, UK Phone: +44(51)794 3716 FAX : +44(51)794 3759 email: jls@liv.ac.uk