Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!uflorida!novavax!hcx1!bill From: bill@ssd.harris.com (Bill Leonard) Newsgroups: comp.lang.fortran Subject: Re: Sig blanks (was Message from God) Message-ID: Date: 31 Jan 90 20:00:57 GMT References: <5974@eos.UUCP> <1990Jan13.154645.506@esegue.segue.boston.ma.us> <2699@tukki.jyu.fi> <1664@bnlux0.bnl.gov> Sender: news@hcx1.SSD.CSD.HARRIS.COM Organization: Harris Computer Systems Division Lines: 74 In-reply-to: bam@bnlux0.bnl.gov's message of 29 Jan 90 19:58:26 GMT In article <1664@bnlux0.bnl.gov> bam@bnlux0.bnl.gov (Bruce A. Martin) writes: ANSI did not *then* allow the notion of "deprecation". If a form or feature was allowed by the standard then it must be on an equal status with all other allowed ones; conversely, if a form was disallowed, then nothing may be said about the processor's behaviour if it is used. (That is why Hollerith is described in an appendix and not in the "official" part of the standard. That's also why zombies such as PAUSE and ASSIGN appear in the same font as the good stuff.) There just was no way for a standard to say that something is acceptable for "old" lines of code but unacceptable for "new" ones (even if there was some way to distinguish between them). In developing the latest revision, "Fortran 90", X3J3 faced a somewhat easier situation with regard to these issues. Firstly, there were new rules that allowed language evolution. In particular, the new rules allowed features to be included in the standard but designated as "obsolescent" or "deprecated", in the expectation that they were subject to removal in a future revision. Secondly, unlike the previous revision, a brand new source form was being added -- the point being that rules for the new form could be arbitrary, because there was no old code which would become invalidated by such rules. To be fair, this isn't quite accurate. There are not, and to my knowledge have never have been, any ANSI rules regarding "deprecation" or "obsolescence". X3J3 made these up on their own. X3 and ANSI never said they couldn't, and since then I believe a couple of other X3Jx committees have adopted the principle. Presumably, X3J3 could have done this on the last cycle just as easily, but they didn't. After all, deprecation and obsolescence are predictions of what future incarnations of X3J3 will or will not do; as with all such predictions, they are subject to a great deal of error. There is not yet any evidence to indicate whether these predictions will have the desired effect. However, one should think that the experience with Hollerith would provide some clues. This feature was removed (not deprecated, not made obsolescent, just flat removed) in going from the 66 standard to FORTRAN/77. Has use of Hollerith disappeared? Emphatically no. Perhaps its rate of appearance in new code has declined, but that hardly seems to matter when there are millions of lines of 20-year-old FORTRAN out there that is still going strong. As far as the cost of supporting the feature in the compiler goes, it doesn't matter how often the feature is used, as long as one important customer uses it at least once. In my (very humble) opinion, one of three criteria must be met for a feature to be effectively removed from a language: (1) Programs using the feature must be naturally short-lived. (2) The feature must already be seldom or never used. (3) It must be possible to automatically translate code using this feature into semantically equivalent code that still conforms to all the same standards (whatever they are) AND performs at nominally the same rate. In addition, I think, the feature must be widely (and I mean by this almost universally) as a very bad feature. Otherwise, users simply won't be motivated to modify their code to remove the feature. For instance, although many people decry the insignificant blank feature of FORTRAN, I was surprised at the number of people who wrote in support of it in the second Public Review. Several of the writers pointed out that it can be used to make code MORE readable (such as writing '1 000 000' instead of '1000000', or writing 'GET INPUT DATA' instead of 'GETINPUTDATA'). Even if insignificant blanks were made obsolescent, I doubt if those users would modify their code because they LIKE it that way. -- Bill Leonard Harris Computer Systems Division 2101 W. Cypress Creek Road Fort Lauderdale, FL 33309 bill@ssd.csd.harris.com or hcx1!bill@uunet.uu.net