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.}}

+

+

Here are the patches for splitting Scope into two objects:

+

+

* http://www.eros-os.org/pipermail/e-lang/2010-September/013620.html

+

+

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.

+

+

{{stub}}

Latest revision as of 11:22, 30 August 2011

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.