Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!rpi!bu.edu!inmet!stt From: stt@inmet.inmet.com Newsgroups: comp.lang.misc Subject: Re: Request For Comment About Handling Message-ID: <21900002@inmet> Date: 16 Nov 90 19:53:00 GMT References: <242@smds.UUCP> Lines: 83 Nf-ID: #R:smds.UUCP:242:inmet:21900002:000:3525 Nf-From: inmet.inmet.com!stt Nov 16 14:53:00 1990 Re: Use of globals in a new programming language I would recommend that you provide the concept of "context" variables rather than "global" variables. What this means is that each procedure or function which wants access to the global environment must receive an additional implicit "context" parameter. By default, a procedure/function which receives a context parameter passes it down to every procedure/function it calls which requires a context parameter. However, it may establish a new context with different values for some of the variables, but this change only affects the nested calls, and has no effect outside. The only way to have an effect outside is if the context variable is actually a pointer to something. This "thing" pointed to may be altered, but such alterations would generally require mutual exclusion, presuming the thing might be pointed to from multiple threads of control. A totally "pure" procedure/function would receive no context parameter (a so-called "context-free" procedure/function). Such a procedure/function could only depend on its parameters, and only affect its parameters. A pure function given the same parameters would always return the same result. A "side-effect-free" procedure/function would receive the context parameter in a mode which would disallow updating things pointed-to by the context. Such a procedure/function could only affect its parameters/produce a result, though its affect might depend on the state of the context. A "normal" procedure/function would receive the context parameter in a mode allowing it to update things pointed to by the context. Note that this concept of "context" matches nearly exactly that which is represented by the environment variables of Unix, or the logical symbols of VMS. It also corresponds pretty closely to the "special" variables of Common Lisp, which are dynamically rather than lexically scoped. An important feature, however, is that in a multi-threaded language, each thread could have a distinct context. The context could either be a flat name space, or more usefully, an hierarchical name space. If you have declarations in your language, then context "variables" would be declared at the outermost level, but this declaration would only specify the type and default initial value. The current value would depend on the innermost caller which established a new value for it. A major advantage of the "context" approach to globals is that it scales up nicely to multi-threaded and even multi-user environments. The term "global" is misleading since we know it really only means program-wide, not globe-wide. However, in a highly interactive, multi-threaded, multi-user environment, you really might want to have objects shared across threads and/or programs. To do so using contexts, you would create an object in a shared memory area (e.g. the filesystem), and then point to it from one or more contexts. Contexts match very nicely concepts like "current directory" or "standard output" present in most operating systems. They also work well for things like a seed for a random number package, where you might want each thread in a multi-threaded application to have its own seed, allowing a repeatable random-number sequence, independent of the relative rates of execution of the various threads. In fact, in my experience, most uses for globals are more safely and flexibly handled by the concept of context. S. Tucker Taft stt@inmet.inmet.com Intermetrics, Inc. Cambridge, MA 02138