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.9 required=3.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.5-pre1 Date: 23 Sep 92 21:13:23 GMT From: haven.umd.edu!darwin.sura.net!zaphod.mps.ohio-state.edu!cis.ohio-state.ed u!news.sei.cmu.edu!lph@ames.arc.nasa.gov (Larry Howard) Subject: Re: Using Global Variables Message-ID: <1992Sep23.211323.23443@sei.cmu.edu> List-Id: In article <20600143@inmet>, shafer@inmet.inmet.com writes: |> |> The use of global data is "really" just a case of efficiently implemented |> parameter passing. We could see this clearly if we just considered the |> characterization of parameter passing in terms of its operational semantics, |> insteaed of full blown descriptive prescriptions. It's just the difference |> between what is "really happening" and how we see fit to describe and map |> it. Optimization can then be viewed as part of compiling, not programming. The use of global variables for communication between program elements has the virtue of decoupling communication from invocation or synchronization. This type of communication can therefore be combined with a variety of coordination mechanisms. You have pointed out that global variables can be used to implement parameter passing on subprogram and entry calls, and that this decision could be made by a compiler in response to some global optimization. It could likewise be made by a lead designer and embodied in an architecture. There can be considerable safety in limiting a design to the control/communication pairings supported by Ada in the form of subprogram calls and rendezvous. These are both predictable and understandable (;'). There may also be considerable power in other forms of coordination, even if these same forms have been misused in the past. I think we should only insist that whatever is used be understandable and predictable. I guess what I really objected to in this thread was the odor of orthodoxy when (IMHO) we still seem to be on a fairly steep learning curve. Larry Howard (lph@sei.cmu.edu) | Software Engineering Institute, Carnegie Mellon Univ. | Vera pro gratiis. Pittsburgh, PA 15213-3890 (412) 268-6397/5857 (fax) |