Path: utzoo!utgpu!news-server.csri.toronto.edu!clyde.concordia.ca!uunet!munnari.oz.au!goanna!ok
From: ok@goanna.cs.rmit.oz.au (Richard A. O'Keefe)
Newsgroups: comp.lang.fortran
Subject: Re: COMMON and SAVE statements
Message-ID: <3512@goanna.cs.rmit.oz.au>
Date: 4 Aug 90 08:45:23 GMT
References: <65861@lll-winken.LLNL.GOV>
Organization: Comp Sci, RMIT, Melbourne, Australia
Lines: 27

In article <65861@lll-winken.LLNL.GOV>, ray@rogue.llnl.gov (Ray, Scott) writes:
> 2. What could possibly be the motivation for the standard allowing
>    variables in COMMON to be become undefined without a SAVE statement?

Overlays.  Notionally, a COMMON block comes into existence when a
program unit mentioning it is entered, and remains in existence as
long as there is a running program unit that mentions it.  After that
it can go away.  The specification in the standard allows an
implementation to just deallocate the block then, and reallocate it
with undefined contents next time it comes into existence, just like
a local variable.  The standard _also_ allows an implementation to
keep common blocks around forever, just like local variables.

>    I can't think of a case where this would be desirable behavior.

Remember, computers used to be _tiny_.  There's a slow sorting routine
called quicksort which was invented about 1960 so that sorting could be
done _at all_ on a machine with about 256 words of main memory and
16k words of backing store.  By the time of F77, that kind of limitation
was the unlamented past, but 8Mbytes on your desktop was still the future.
Using overlay techniques with data as well as code meant that you _could_
get as much memory re-use out of Fortran as you could out of Algol or Pascal.

-- 
Distinguishing between a work written in Hebrew and one written in Aramaic
when we have only a Latin version made from a Greek translation is not easy.
(D.J.Harrington, discussing pseudo-Philo)