bill@ssd.harris.com (Bill Leonard) (02/01/90)
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.nethirchert@ux1.cso.uiuc.edu (Kurt Hirchert) (02/02/90)
In article <BILL.90Jan31150057@hcx2.ssd.harris.com> bill@ssd.harris.com (Bill Leonard) writes: >In article <1664@bnlux0.bnl.gov> bam@bnlux0.bnl.gov (Bruce A. Martin) writes: > > ANSI did not *then* allow the notion of "deprecation". ... > >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. ... To be fair, this isn't quite accurate, either. After the furor over COBOL 80 and the Travelers Insurance lawsuit, X3 and SPARC began developing intralanguage compatibility guidelines. X3J3's concepts of deprecation and obsolescence were its attempts to implement those guidelines. Having experienced the problems involved in the conversion from FORTRAN 66 to FORTRAN 77, especially with respect to the change from Hollerith data to CHARACTER, X3J3 had already been planning on something like this; the SPARC guidelines simply helped shape the specifics. It might be worth noting that X3J3 ended up following one of the more conservative approaches in the SPARC guidelines. Other alternatives in the guidelines give standards committees substantially more leeway for making incompatible changes than X3J3 has allowed itself. -- Kurt W. Hirchert hirchert@ncsa.uiuc.edu National Center for Supercomputing Applications