From Erights
(Difference between revisions)
|
|
| Line 1: |
Line 1: |
| - | Env: what [[Scope]] objects ought to be renamed to.
| + | Environment What [[Scope]] objects ought to be renamed to. |
| - | | + | |
| - | 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}}
| + | |
Revision as of 20:29, 23 March 2008
Environment What Scope objects ought to be renamed to.
