Path: utzoo!utgpu!attcan!uunet!lll-winken!lll-lcc!ames!ncar!oddjob!uxc!uxc.cso.uiuc.edu!uxe.cso.uiuc.edu!hirchert From: hirchert@uxe.cso.uiuc.edu Newsgroups: comp.lang.fortran Subject: Re: (none) Message-ID: <50500069@uxe.cso.uiuc.edu> Date: 19 Aug 88 19:53:00 GMT References: <651@<8052> Lines: 26 Nf-ID: #R:<8052:651:uxe.cso.uiuc.edu:50500069:000:1639 Nf-From: uxe.cso.uiuc.edu!hirchert Aug 19 14:53:00 1988 Two comments on Bob Allison's comments on the last X3J3 meeting: 1. Bob is quite right that proposals to do away with the concept of deprecation did not also include changes to better integrate the formerly deprecated features with new features (in particular to do storage associating on new data types). Some of us never expected them to. I would argue that failing to properly integrate the language is a mistake even if some parts of the language are deprecated. This makes language integration a separate problem from deprecation, and thus I expected a separate solution. Fortunately, X3J3 now seems amenable to adopting such a solution. 2. Bob suggests that if the concept of obsolescence remains in Fortran 8x, there will be nothing to stop the Fortran 9x committee from making features like COMMON and EQUIVALENCE obsolescent in the next standard. a. Assuming COMMON and EQUIVALENCE are still as heavily used as they are now, I would suggest that the public comment on such a draft would make the recent 8x public comment look tame. b. If you think that the committee could somehow ignore that kind of public comment, then in the absense of the concept of obsolescence, there would be nothing to keep the 9x committee from deleting those features outright. The concept of obsolescence was originally proposed not as an attack on the obsolescent features but as a guarantee of the continued availability of the featues not identified as obsolescent. Kurt W. Hirchert hirchert@ncsa.uiuc.edu National Center for Supercomputing Applications