[comp.lang.fortran] Deprecation/Obsolescence

bobal@microsoft.UUCP (Bob Allison) (08/26/88)

In article <50500069@uxe.cso.uiuc.edu> hirchert@uxe.cso.uiuc.edu writes:
>
>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.

    X3J3 seems willing, but that has not been sufficient before: I still hear
    a lot of people who are unwilling to accept any solution to the
    character/non-character problem with common blocks.  I can't wait to
    see their reaction to structures in common.

>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.
>	...
>
>Kurt W. Hirchert     hirchert@ncsa.uiuc.edu
>National Center for Supercomputing Applications

Kurt is, of course, correct.  I was actually just making preliminary 
observations which would have moved one to the conclusion that: COMMON 
and EQUIVALENCE are not leaving the language in the forseeable future; 
and, there are still people on the committee who do not believe this.  

I believe that one approaches language design completely differently 
when one thinks the language can be redesigned from scratch, throwing 
out the old parts which are not chic enough and designing replacement 
features for them, than when one believes that the core of the language 
is fixed (despite any unfortunate design decisions) and that replacement 
features simply provide confusion and multi-language programming in the 
same piece of code.  (My English teacher would have killed me for a sentence
like that: in the real world, it isn't even a misdemeanor).

If we aren't going to remove COMMON and EQUIVALENCE, then we don't want
to go out of our way designing new ways to do the same thing.  Rather,
we should be spending time addressing issues which haven't been addressed
at all and need the help much more.  Unfortunately, it is a little late
for new things.  For the moment, I will be satisfied with a new standard
which provides some new stuff (structures, some standardization of 
common extensions, a couple of new control constructs, some new I/O), which
at least gives people a little more to work with, than spending another
five years deciding we don't know what the hell we want to do, and 
leaving programmers with 77 for that much longer.

That was way too long: sorry.

Bob Allison