From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.5-pre1 (2020-06-20) on
	ip-172-31-74-118.ec2.internal
X-Spam-Level: *
X-Spam-Status: No, score=1.6 required=3.0 tests=BAYES_50,FROM_NO_USER
	autolearn=no autolearn_force=no version=3.4.5-pre1
Date: Fri, 18 Sep 92 08:12:45 CDT
From: crispen <@ada3.ca.boeing.com:crispen@efftoo.boeing.com>
Subject: Re: Using Global Variables
Message-ID: <9209181312.AA24702@efftoo.boeing.com>
List-Id: <comp.lang.ada>

If you're communicating between two CPUs on a common backplane and
your Ada doesn't have multi-CPU-board tasking, then if you want to
communicate between the boards, you're going to have to (a) use some
OS service (e.g., sockets), or (b) pucker up and stick the variable
into common memory.

There are "nice" and "naughty" ways to do this, of course.  Bad
boys and girls declare a data object in a package spec.  In fact,
*really* bad boys and girls declare data objects in package specs
even when they don't need to talk between CPUs.

Now Trey Haddad (ghaddad@lmsc.lockheed.com) sez:

>   Aww, c'mon guys.  I was under the impression that, in Ada, there's no
>   such animal as a 'global' variable.  There's just 'more' and 'less' local
>   variables.  What's wrong (or difficult, or complicated) about a variable
>   which is in scope in the principal subprogram?  Assuming your particular
>   application calls for it, that is.

It's true that you don't *have* to WITH a package with a data object
in the package spec, so the variable is only *potentially* global -- in
the sense that in F*rtr*n you don't *have* to reference a COMMON block,
but that seems to me to be splitting hairs.

As you can tell, I'm a real bigot about data flow control -- pass your
data in your subprogram arguments OR DIE!

Which is why I wonder about designs that use common memory "for speed".
Did these designs begin as data-flow-controlled designs, and the
common memory was retrofitted when the speed *actually* was too slow?
It's hard to complain about that (though, as a dataflow bigot, I've
found that I could always weed a lot of dumb things out of my code
before having to start on weeding out the smart things).

Or did these designs begin as vintage "working" Fortran code that used
COMMONs and there wasn't program time or money enough to redevelop, just
recode?  Or is it the programmer him/herself who isn't able to take
the time to understand and control the data flow in the system?
Those things may be facts of life in the real world, but IMHO they
should be approached apologetically (I'm a good designer, but I wasn't
allowed to be this time) rather than as justifications (Yeah, I use
COMMON -- so what?  It's great design!).

But, like I said, I'm a bigot.
+-------------------------------+--------------------------------------+
| Bob Crispen                   |   The owls are not what they seem    |
| crispen@foxy.boeing.com       +--------------------------------------+
| (205) 461-3296                |Opinions expressed here are mine alone|
+-------------------------------+--------------------------------------+