In article <1kl20m3.1o2rpih1agavveN%nospam@see.signature>,
nospam@see.signature (Richard Maine) writes:

> > > I still don't see this alleged difference between COMMON and modules for
> > > the purpose you describe. As Glen notes, they are both global. Just
> > > because you put the declarations for a COMMON only in the routines in
> > > question, that doesn't mean that the COMMON is somehow local to them. It
> > > is still global in exactly the same way that a module is global. Each
> > > COMMON can map one-to-one onto a module with exactly the same variables.
> > > I don't see this "level" difference.
> >
> > As I noted in my first post from today, it is not a technical
> > distinction, but more an aesthetic one.
>
> Well, I guess it is time for me to drop out of this discussion. I'm sure
> not going to start up with explaining the *LONG* list of problems with
> using COMMON. I have spent so much time in my career debugging messy
> problems relating to COMMON that I have trouble seeing anything
> aesthetically pleasing in it.

As I wrote in reply to Ron Shepard a few minutes ago, I couldn't agree
more and definitely want to get away from COMMON. This is the ONLY
thing I like about COMMON, but even that is not strong enough for me to
use it instead of a module solution. I think I will have a module for
variables which are shared between just a few routines, and said
routines can USE this module (perhaps ONLY the variables they actually
need).

> As just a hint to one of the items in the list, note that COMMON does
> not share variables at all. It just shares memory locations (sort of -
> digression into the strange implementations needed for the now obsolete
> assigned GOTO would be long). The variables just happen to be
> essentially equivalenced via those memory locations.

Right; "shared variables" was just a shorthand notation.