MarkM has recently suggested that I am responsible for there being no fluid variables in Joule. I think that it is good that Joule lacks fluid variables but perhaps my only contribution in that case was to wince whenever they would describe how they worked, as it was painful to describe. That was sufficiently effective it seems that they decided that they were unnecessary. See comments below on fluid variables. There are several related common language constructs: Many languages have a concept of a top level environment in which a Read Eval Print Loop runs to preserve state and in which expressions can have side-effects. Part of the invention of Rees’s paper was the displacement of this top level with several, each mutually suspicious of others. Other channels of side-effects must be made to conform. Scheme already took several steps beyond Lisp in this regard in eliminating property lists, for example.

Here is how I understand the workings of fluid variables. A fluid variable is a symbol and cell that is established as part of the current environment. When a fluid variable (symbol) is referenced the current nest of environments is searched for a fluid variable with the matching symbol. The first such match provides the cell that satisfies the reference. This really means that each continuation embodies a set of fluid bindings. Many uses of continuations, for which they were reified, are incompatible with fluid variables. One such use is time-slicing. Scheme has no fluid variables.

In lexically scoped languages (Algol, PL/I, C, C++, Pascal, Scheme etc.) Each applied occurrence of an identifier is statically associated with just one defining occurrence, its declaration. In Dynamically scoped languages, (Lisp) this association in determined only at run time.

Both these scoping styles can be explained in the Actors model. The question involves the interpretation of the identifiers that occur freely in the body of the function (the parameters are considered not free). In both cases those identifiers are evaluated in some scope. When a function is created dynamically in a lexical language, access to the generation of variables accessible at the point and time of creation is bundled up and becomes part of the function whereas in a dynamically scoped language the function is not so equipped and when it comes tome to run will use the scope of its caller. In either case parameters to the function are bound to arguments provided by the caller. The infamous funarg problem (See Google) illustrates some of the disadvantages of dynamic scoping. I think that the following history is correct. When John McCarthy invented Lisp he had already contributed to the lexical scoping rules of Algol 60. He was on the committee that defined the language. He tells the story that towards the end of the design process someone proposed a rule that sounded clear and that may (or may not) have corresponded to what is now called referential transparency. McCarthy thought that it was a good idea and had already conceived of a way to implement it efficiently. I guess when it came time to invent Lisp he thought that dynamic scoping was better, or perhaps he didn’t see the connection between the two design issues. It was a couple of decades later that I realized the advantages of lexical scoping. About 2005 McCarthy told me that Scheme (a language like LISP) had got it right with lexical scoping.