Env - Revision history

ThomasLeonard: Clarify Scope/EEnv split

2011-08-30T11:22:16Z

Clarify Scope/EEnv split

New page

Env: 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}}

Kevin Reid: expand

2011-08-27T00:22:02Z

expand

←Older revision		Revision as of 00:22, 27 August 2011
Line 1:		Line 1:
-	~~Environment~~: what [[Scope]] objects ought to be renamed to.	+	Env: 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.}}
		+
		+	{{stub}}

Kevin Reid: Environment moved to Env: New short name preferred by MarkM

2011-08-27T00:18:49Z

Environment moved to Env: New short name preferred by MarkM

←Older revision

Revision as of 00:18, 27 August 2011

Kevin Reid: punctuation

2008-03-23T20:29:40Z

punctuation

←Older revision		Revision as of 20:29, 23 March 2008
Line 1:		Line 1:
-	Environment ~~What~~ [[Scope]] objects ought to be renamed to.	+	Environment: what [[Scope]] objects ought to be renamed to.

Kevin Reid: stubish

2008-03-23T20:29:20Z

stubish

←Older revision		Revision as of 20:29, 23 March 2008
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}}~~	+