Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!usc!wuarchive!mit-eddie!xn.ll.mit.edu!husc6!m2c!jjmhome!smds!rh From: rh@smds.UUCP (Richard Harter) Newsgroups: comp.lang.misc Subject: Re: Request For Comment About Handling Summary: Contexts, globals, and chilled grease sandwiches Message-ID: <247@smds.UUCP> Date: 18 Nov 90 02:42:29 GMT References: <242@smds.UUCP> <21900002@inmet> Organization: SMDS Inc., Concord, MA Lines: 153 In article <21900002@inmet>, stt@inmet.inmet.com writes: : 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. The key distinction being, I gather, that a procedure is told where it getting externals from rather than declaring where it gets externals from. Are you really thinking in terms of a single "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. This sounds a lot like traditional nested scope. If I am following you correctly I see some problems. Quite frequently one wants to put the context definition code one or more layers down from the top level entry point, e.g. procedure do-good-stuff .... establish-local-context .... do-the-dirty-work If the top level routine has to have all of the context definition code it becomes overburdened with a large declaration section. : 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. It is part of the language design that all functions are "pure". : 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. This raises the question of who decides whether a procedure is "side-effect-free" or "normal", the calling procedure or the called procedure. My view is that an update within a procedure should always succeed with the proviso that, in a "side-effect-free" mode the update is made to a copy. One issue is whether one decides to make "side-effect-free" an integral language concept (the default being to let the chips fall where they may.) If one does, is the attribute of side-effect-freeness inherited? If so, what does one do about service routines which might have side effects? : 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. This is a pretty dubious recommendation. :-) : 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 language is designed to make multi-threading easy, so this is an important point. : The context could either be a flat name space, or : more usefully, an hierarchical name space. My experience is that flat name spaces suck (you should excuse the language.) One always runs into name-space pollution problems. Actually, at the procedure level, the name space is flat. This is, in my view, the right thing to do. Procedures are small and you can afford a flat name space. The route that I am following is that all names are local except those imported in by mechanisms currently under study. : 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. There are no type declarations. The language has a single type; each variable has its value a list of strings. There is provision for scope declarations. Currently a variable can be declared local or global. This is admittedly primitive but works fine for small applications. Call it an interim solution while figuring out how to do it right. : 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. Just the kind of thing that I am thinking about. I have to admit, however, that I don't quite see how the approach that you are suggesting works in an object-oriented context. [This isn't an OOL, but one certainly wants to use OOL techniques.] Objects and their methods have a private context which is shared across a set of procedures (methods, whatever) which is not inherited from the calling environment. A shared memory area sounds a global to me (restricted access globals are still globals). : Contexts match very nicely concepts like "current directory" : or "standard output" present in most operating systems... I like that term, "current dictionary". : In fact, in my experience, most uses for globals are more : safely and flexibly handled by the concept of context. I agree. My thinking has run along those lines. Perhaps I have misjudged the matter but I see the need for multiple contexts which could make things very messy unless one is very very careful. Thank you for the comments. -- Richard Harter, Software Maintenance and Development Systems, Inc. Net address: jjmhome!smds!rh Phone: 508-369-7398 US Mail: SMDS Inc., PO Box 555, Concord MA 01742 This sentence no verb. This sentence short. This signature done.