Env

From Erights

The error is long-standing in E's design, but User:Markm did not not want to use the technically correct “environment” since it was rather lengthy to write in code. User:Kevin Reid advocates using “Env”, this being both correct and short.

XXX Expand this with actually explaining the protocol of Env objects. Also see Thomas Leonard's proposal that Scope objects in E-on-Java remain what they are for implementation efficiency while Envs have the nice user-facing and GBA-providing protocol.

The motivation for this is that we are currently using one type (Scope) for two purposes:

as the means to specify the context in which to evaluate an expression (essentially an immutable map of names to Slots), and

as a mutable internal data structure of the interpreter (holding the current values of local variables, etc).

The way we currently make the mutable Scope object appear immutable to E code is through taming. This is risky (a flaw in the taming rules once allowed code to replace items in safeScope, for example). It's also confusing, because you can e.g. pass values for locals where it doesn't make sense (e.g. to eExpr.eval) and many Scope methods only make sense in one of the two contexts.