🚀 go-pugleaf

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