Guard-based auditing - Revision history

Kevin Reid: update on status, use XXX

Kevin Reid — Sat, 29 Aug 2009 22:16:41 GMT

update on status, use XXX

New page

This is a new design for auditing in E. It is an alternative to the unshadowable-names/synEnv system currently implemented in [[E-on-Java]], and the give-the-auditor-access-to-everything previously used by [[E-on-CL]].

It is currently provided in [[E-on-CL]] and [[User:Markm]] plans to implement it in [[E-on-Java]].

==Basic implementation==

In [[environment]]s, nouns are associated with "bindings" instead of [[slot]]s. A binding is an object which holds a [[slot]] and a [[guard]], and alleges that that slot was returned from that guard (except for object expressions; see below).

These properties of binding objects happen to make them very much like [[VarSlot]]s except for being immutable, so they implement the slot protocol and are called [[CoercedSlot]]. CoercedSlots are [[PassByConstruction]] and non-[[transparent]] [[Selfless]].

Note that [[FinalPattern]]s and [[VarPattern]]s must get [[FinalSlot]] and [[VarSlot]] guards; e.g. <code>def x :int := 1</code> results in the binding object <code>makeCoercedSlot(FinalSlot[int], makeFinalSlot(1), null)</code> (except that implementations may optimize it to not require constructing an intermediate FinalSlot if the guard coerces).

If a pattern does not have a guard, then <code>any</code> is used. Examples: <code>def x := y</code> has a binding guard of <code>[[FinalSlot]][any]</code>, and <code>def &x := y</code> has a binding guard of <code>[[any]]</code>.

Environments gain the methods fetchBinding/2, getBindings/0 (returns an object mapping nouns to bindings), and getSlots/0 (returns an object mapping nouns to slots), and lose iterate/1.

[[Audition]]s have one relevant method, [[Audition#getGuard/1|getGuard/1]]. Given a noun (string), it returns the guard of the matching binding. If the noun is not one of the free variables of the audition's object expression, or if the audit has already terminated, then an exception is thrown.

An additional component on kernel [[ObjectExpr]]s: the "<code>as</code>" clause, syntactically preceding the "<code>implements</code>", behaves like it but with the additional effect of making its value be the guard for the binding of the object name (without coercing the object). That is, <code>def x as Y {}</code> audits x with Y, and also causes the binding to be <code>("x", makeFinalSlot(<x>), FinalSlot[Y])</code>. In the E AST, the current <var>auditorExprs</var> :List[EExpr] is replaced with a new node type "AuditorExprs" with fields (<var>as</var> :nullOk[EExpr], <var>implements</var> :List[EExpr]).

Bindings may be reified in E programs using the prefix && operator. (This is necessary to support nonkernel <code>[[meta.getState]]()</code>, and beneficial to the extends-syntax "<code>super</code>".) "&&" is a single token and operator, not two prefix operators. As an expression, it is BindingExpr(NounExpr); as a pattern it is BindingPattern(NounExpr). The pattern does not take a guard like [[SlotPattern]] does.

The expansion of ObjectExpr's "extends" clause is changed such that "<code>extends <var>someNoun</var></code>" results in <code>super</code> defined as "<code>def &&super := &&<var>someNoun</var></code>"; if the expression in the extends clause is not a noun then the expansion remains the current "<code>def super := <var>someExpr</var></code>"

Because bindings are Selfless, the evaluator need not make any effort to preserve their identities.

All bindings in the [[safeScope]] expose their values in their guards; that is, they are <code>("foo", bar, FinalSlot[Same[bar]])</code>.

CoercedSlots are PassByConstruction; their uncall is makeCoercedSlot.attempt(guard, value). This performs guard.coerce(value, ...); if the guard fails, or returns a reference which is not the same as the original value, then the resulting CoercedSlot has LostApproval[guard] instead of the original guard. LostApproval is equivalent to [[any]], and is used merely to report what the original guard was and why it is missing. ({{XXX|LostApproval is not implemented in E-on-CL}})

==Implications for auditors==

{{XXX|write this}}

==Implications for guards==

To support multiple independently-written auditors on the same object, it must be possible to have single guards which satisfy multiple auditors' criteria. It is also desirable that programmers need not write code to match exactly an auditor's view of what is necessary. Therefore, we add the optional operation rangeSupersetOf/1 to guards.

to rangeSupersetOf(other :Guard) :nullOk[boolean]

If X.rangeSupersetOf(Y) returns true, X is claiming that every value returned by Y (as a guard) would have been returned by X under some circumstances; that is, the 'range' of X is a 'superset of' the range of Y. For example, int.rangeSupersetOf(1..10) should be true, as should [[DeepFrozen]].rangeSupersetOf(int).

Returning false indicates that X is not a range superset of Y; returning null indicates that X doesn't know.

==Open questions==

{{XXX|write this}}

[[Category:Resolved design issues]]
[[Category:Message rangeSupersetOf/1]]

Markm: /* Basic implementation */

Markm — Thu, 01 Jan 2009 19:49:35 GMT

Basic implementation

←Older revision		Revision as of 19:49, 1 January 2009
Line 15:		Line 15:
	[[Audition]]s have one relevant method, [[Audition#getGuard/1\|getGuard/1]]. Given a noun (string), it returns the guard of the matching binding. If the noun is not one of the free variables of the audition's object expression, or if the audit has already terminated, then an exception is thrown.		[[Audition]]s have one relevant method, [[Audition#getGuard/1\|getGuard/1]]. Given a noun (string), it returns the guard of the matching binding. If the noun is not one of the free variables of the audition's object expression, or if the audit has already terminated, then an exception is thrown.

-	An additional component on kernel [[ObjectExpr]]s: the "<code>as</code>" clause, syntactically preceding the "<code>implements</code>", behaves like it but with the additional effect of making its value be the guard for the binding of the object name (without coercing the object). That is, <code>def x as Y {}</code> audits x with Y, and also causes the binding to be <code>("x", makeFinalSlot(<x>), FinalSlot[Y])</code>. In the E AST, the current <var>auditorExprs</var> :List[EExpr] is replaced with a new node type "~~Auditors~~" with fields (<var>as</var> :nullOk[EExpr], <var>implements</var> :List[EExpr]).	+	An additional component on kernel [[ObjectExpr]]s: the "<code>as</code>" clause, syntactically preceding the "<code>implements</code>", behaves like it but with the additional effect of making its value be the guard for the binding of the object name (without coercing the object). That is, <code>def x as Y {}</code> audits x with Y, and also causes the binding to be <code>("x", makeFinalSlot(<x>), FinalSlot[Y])</code>. In the E AST, the current <var>auditorExprs</var> :List[EExpr] is replaced with a new node type "AuditorExprs" with fields (<var>as</var> :nullOk[EExpr], <var>implements</var> :List[EExpr]).

	Bindings may be reified in E programs using the prefix && operator. (This is necessary to support nonkernel <code>[[meta.getState]]()</code>, and beneficial to the extends-syntax "<code>super</code>".) "&&" is a single token and operator, not two prefix operators. As an expression, it is BindingExpr(NounExpr); as a pattern it is BindingPattern(NounExpr). The pattern does not take a guard like [[SlotPattern]] does.		Bindings may be reified in E programs using the prefix && operator. (This is necessary to support nonkernel <code>[[meta.getState]]()</code>, and beneficial to the extends-syntax "<code>super</code>".) "&&" is a single token and operator, not two prefix operators. As an expression, it is BindingExpr(NounExpr); as a pattern it is BindingPattern(NounExpr). The pattern does not take a guard like [[SlotPattern]] does.

Kevin Reid: /* Basic implementation */ clarify super expansion

Kevin Reid — Sat, 29 Nov 2008 02:50:45 GMT

Basic implementation: clarify super expansion

←Older revision		Revision as of 02:50, 29 November 2008
Line 19:		Line 19:
	Bindings may be reified in E programs using the prefix && operator. (This is necessary to support nonkernel <code>[[meta.getState]]()</code>, and beneficial to the extends-syntax "<code>super</code>".) "&&" is a single token and operator, not two prefix operators. As an expression, it is BindingExpr(NounExpr); as a pattern it is BindingPattern(NounExpr). The pattern does not take a guard like [[SlotPattern]] does.		Bindings may be reified in E programs using the prefix && operator. (This is necessary to support nonkernel <code>[[meta.getState]]()</code>, and beneficial to the extends-syntax "<code>super</code>".) "&&" is a single token and operator, not two prefix operators. As an expression, it is BindingExpr(NounExpr); as a pattern it is BindingPattern(NounExpr). The pattern does not take a guard like [[SlotPattern]] does.

-	The expansion of ObjectExpr's "extends" clause is changed such that "<code>extends <var>someNoun</var></code>" results in <code>super</code> defined as: <code>def &&super := &&<var>someNoun</var></code>	+	The expansion of ObjectExpr's "extends" clause is changed such that "<code>extends <var>someNoun</var></code>" results in <code>super</code> defined as "<code>def &&super := &&<var>someNoun</var></code>"; if the expression in the extends clause is not a noun then the expansion remains the current "<code>def super := <var>someExpr</var></code>"

	Because bindings are Selfless, the evaluator need not make any effort to preserve their identities.		Because bindings are Selfless, the evaluator need not make any effort to preserve their identities.

Kevin Reid: /* Basic implementation */ fix typo, improve structure

Kevin Reid — Sat, 29 Nov 2008 02:45:02 GMT

Basic implementation: fix typo, improve structure

←Older revision		Revision as of 02:45, 29 November 2008
Line 15:		Line 15:
	[[Audition]]s have one relevant method, [[Audition#getGuard/1\|getGuard/1]]. Given a noun (string), it returns the guard of the matching binding. If the noun is not one of the free variables of the audition's object expression, or if the audit has already terminated, then an exception is thrown.		[[Audition]]s have one relevant method, [[Audition#getGuard/1\|getGuard/1]]. Given a noun (string), it returns the guard of the matching binding. If the noun is not one of the free variables of the audition's object expression, or if the audit has already terminated, then an exception is thrown.

-	An additional component on kernel [[ObjectExpr]]s: the "<code>as</code>" clause, syntactically preceding the "<code>implements</code>", behaves like it but with the additional effect of making its value be the guard for the binding of the object name (without coercing the object). That is, <code>def x as Y {}</code> audits x with Y, and also causes the binding to be <code>("x", makeFinalSlot(<x>), FinalSlot[Y])</code>. In ~~theE~~ AST, the current ~~list of~~ auditorExprs is replaced with a new node type "Auditors" with fields (as :nullOk[EExpr], implements :List[EExpr]).	+	An additional component on kernel [[ObjectExpr]]s: the "<code>as</code>" clause, syntactically preceding the "<code>implements</code>", behaves like it but with the additional effect of making its value be the guard for the binding of the object name (without coercing the object). That is, <code>def x as Y {}</code> audits x with Y, and also causes the binding to be <code>("x", makeFinalSlot(<x>), FinalSlot[Y])</code>. In the E AST, the current <var>auditorExprs</var> :List[EExpr] is replaced with a new node type "Auditors" with fields (<var>as</var> :nullOk[EExpr], <var>implements</var> :List[EExpr]).

	Bindings may be reified in E programs using the prefix && operator. (This is necessary to support nonkernel <code>[[meta.getState]]()</code>, and beneficial to the extends-syntax "<code>super</code>".) "&&" is a single token and operator, not two prefix operators. As an expression, it is BindingExpr(NounExpr); as a pattern it is BindingPattern(NounExpr). The pattern does not take a guard like [[SlotPattern]] does.		Bindings may be reified in E programs using the prefix && operator. (This is necessary to support nonkernel <code>[[meta.getState]]()</code>, and beneficial to the extends-syntax "<code>super</code>".) "&&" is a single token and operator, not two prefix operators. As an expression, it is BindingExpr(NounExpr); as a pattern it is BindingPattern(NounExpr). The pattern does not take a guard like [[SlotPattern]] does.

-	The expansion of ObjectExpr's "extends" clause is changed such that "<code>extends <var>someNoun</var></code>" results in <code>super</code> defined as: <code>def &&super := &&<var>someNoun</var>	+	The expansion of ObjectExpr's "extends" clause is changed such that "<code>extends <var>someNoun</var></code>" results in <code>super</code> defined as: <code>def &&super := &&<var>someNoun</var></code>

	Because bindings are Selfless, the evaluator need not make any effort to preserve their identities.		Because bindings are Selfless, the evaluator need not make any effort to preserve their identities.

Kevin Reid: /* Basic implementation */ doc of super expansion and Kernel-E change

Kevin Reid — Sat, 08 Nov 2008 04:24:58 GMT

Basic implementation: doc of super expansion and Kernel-E change

←Older revision		Revision as of 04:24, 8 November 2008
Line 15:		Line 15:
	[[Audition]]s have one relevant method, [[Audition#getGuard/1\|getGuard/1]]. Given a noun (string), it returns the guard of the matching binding. If the noun is not one of the free variables of the audition's object expression, or if the audit has already terminated, then an exception is thrown.		[[Audition]]s have one relevant method, [[Audition#getGuard/1\|getGuard/1]]. Given a noun (string), it returns the guard of the matching binding. If the noun is not one of the free variables of the audition's object expression, or if the audit has already terminated, then an exception is thrown.

-	An additional component on kernel [[ObjectExpr]]s: the "<code>as</code>" clause, syntactically preceding the "<code>implements</code>", behaves like it but with the additional effect of making its value be the guard for the binding of the object name (without coercing the object). That is, <code>def x as Y {}</code> audits x with Y, and also causes the binding to be <code>("x", makeFinalSlot(<x>), FinalSlot[Y])</code>.	+	An additional component on kernel [[ObjectExpr]]s: the "<code>as</code>" clause, syntactically preceding the "<code>implements</code>", behaves like it but with the additional effect of making its value be the guard for the binding of the object name (without coercing the object). That is, <code>def x as Y {}</code> audits x with Y, and also causes the binding to be <code>("x", makeFinalSlot(<x>), FinalSlot[Y])</code>. In theE AST, the current list of auditorExprs is replaced with a new node type "Auditors" with fields (as :nullOk[EExpr], implements :List[EExpr]).

	Bindings may be reified in E programs using the prefix && operator. (This is necessary to support nonkernel <code>[[meta.getState]]()</code>, and beneficial to the extends-syntax "<code>super</code>".) "&&" is a single token and operator, not two prefix operators. As an expression, it is BindingExpr(NounExpr); as a pattern it is BindingPattern(NounExpr). The pattern does not take a guard like [[SlotPattern]] does.		Bindings may be reified in E programs using the prefix && operator. (This is necessary to support nonkernel <code>[[meta.getState]]()</code>, and beneficial to the extends-syntax "<code>super</code>".) "&&" is a single token and operator, not two prefix operators. As an expression, it is BindingExpr(NounExpr); as a pattern it is BindingPattern(NounExpr). The pattern does not take a guard like [[SlotPattern]] does.
		+
		+	The expansion of ObjectExpr's "extends" clause is changed such that "<code>extends <var>someNoun</var></code>" results in <code>super</code> defined as: <code>def &&super := &&<var>someNoun</var>

	Because bindings are Selfless, the evaluator need not make any effort to preserve their identities.		Because bindings are Selfless, the evaluator need not make any effort to preserve their identities.

Kevin Reid: /* Basic implementation */ mention super motive for &&

Kevin Reid — Sat, 08 Nov 2008 04:17:41 GMT

Basic implementation: mention super motive for &&

←Older revision		Revision as of 04:17, 8 November 2008
Line 17:		Line 17:
	An additional component on kernel [[ObjectExpr]]s: the "<code>as</code>" clause, syntactically preceding the "<code>implements</code>", behaves like it but with the additional effect of making its value be the guard for the binding of the object name (without coercing the object). That is, <code>def x as Y {}</code> audits x with Y, and also causes the binding to be <code>("x", makeFinalSlot(<x>), FinalSlot[Y])</code>.		An additional component on kernel [[ObjectExpr]]s: the "<code>as</code>" clause, syntactically preceding the "<code>implements</code>", behaves like it but with the additional effect of making its value be the guard for the binding of the object name (without coercing the object). That is, <code>def x as Y {}</code> audits x with Y, and also causes the binding to be <code>("x", makeFinalSlot(<x>), FinalSlot[Y])</code>.

-	Bindings may be reified in E programs using the prefix && operator. (This is necessary to support nonkernel <code>[[meta.getState]]()</code>.) "&&" is a single token and operator, not two prefix operators. As an expression, it is BindingExpr(NounExpr); as a pattern it is BindingPattern(NounExpr). The pattern does not take a guard like [[SlotPattern]] does.	+	Bindings may be reified in E programs using the prefix && operator. (This is necessary to support nonkernel <code>[[meta.getState]]()</code>, and beneficial to the extends-syntax "<code>super</code>".) "&&" is a single token and operator, not two prefix operators. As an expression, it is BindingExpr(NounExpr); as a pattern it is BindingPattern(NounExpr). The pattern does not take a guard like [[SlotPattern]] does.

	Because bindings are Selfless, the evaluator need not make any effort to preserve their identities.		Because bindings are Selfless, the evaluator need not make any effort to preserve their identities.

Kevin Reid: /* Basic implementation */ clarify relationship with VarSlot

Kevin Reid — Sat, 08 Nov 2008 03:47:39 GMT

Basic implementation: clarify relationship with VarSlot

←Older revision		Revision as of 03:47, 8 November 2008
Line 5:		Line 5:
	In [[environment]]s, nouns are associated with "bindings" instead of [[slot]]s. A binding is an object which holds a [[slot]] and a [[guard]], and alleges that that slot was returned from that guard (except for object expressions; see below).		In [[environment]]s, nouns are associated with "bindings" instead of [[slot]]s. A binding is an object which holds a [[slot]] and a [[guard]], and alleges that that slot was returned from that guard (except for object expressions; see below).

-	~~Binding~~ objects happen to be very much like ~~immutable~~ [[VarSlot]]s, so they implement the slot protocol and are called [[CoercedSlot]]. CoercedSlots are [[PassByConstruction]] and non-[[transparent]] [[Selfless]].	+	These properties of binding objects happen to make them very much like [[VarSlot]]s except for being immutable, so they implement the slot protocol and are called [[CoercedSlot]]. CoercedSlots are [[PassByConstruction]] and non-[[transparent]] [[Selfless]].

-	Note that [[FinalPattern]]s and [[VarPattern]]s must get FinalSlot and VarSlot guards; e.g. <code>def x :int := 1</code> results in the binding object <code>makeCoercedSlot(FinalSlot[int], makeFinalSlot(1), null)</code> (except that implementations may optimize it to not require constructing an intermediate FinalSlot if the guard coerces).	+	Note that [[FinalPattern]]s and [[VarPattern]]s must get [[FinalSlot]] and [[VarSlot]] guards; e.g. <code>def x :int := 1</code> results in the binding object <code>makeCoercedSlot(FinalSlot[int], makeFinalSlot(1), null)</code> (except that implementations may optimize it to not require constructing an intermediate FinalSlot if the guard coerces).

	If a pattern does not have a guard, then <code>any</code> is used. Examples: <code>def x := y</code> has a binding guard of <code>[[FinalSlot]][any]</code>, and <code>def &x := y</code> has a binding guard of <code>[[any]]</code>.		If a pattern does not have a guard, then <code>any</code> is used. Examples: <code>def x := y</code> has a binding guard of <code>[[FinalSlot]][any]</code>, and <code>def &x := y</code> has a binding guard of <code>[[any]]</code>.

Kevin Reid: update eocl status

Kevin Reid — Wed, 17 Sep 2008 21:20:33 GMT

update eocl status

←Older revision		Revision as of 21:20, 17 September 2008
Line 1:		Line 1:
-	This is a new design for auditing in E. It is an alternative to the unshadowable-names/synEnv system currently implemented in [[E-on-Java]], and the give-the-auditor-access-to-everything ~~currently in~~ [[E-on-CL]].	+	This is a new design for auditing in E. It is currently provided in [[E-on-CL]]. It is an alternative to the unshadowable-names/synEnv system currently implemented in [[E-on-Java]], and the give-the-auditor-access-to-everything previously used by [[E-on-CL]].

	==Basic implementation==		==Basic implementation==
Line 23:		Line 23:
	All bindings in the [[safeScope]] expose their values in their guards; that is, they are <code>("foo", bar, FinalSlot[Same[bar]])</code>.		All bindings in the [[safeScope]] expose their values in their guards; that is, they are <code>("foo", bar, FinalSlot[Same[bar]])</code>.

-	CoercedSlots are PassByConstruction; their uncall is makeCoercedSlot.attempt(guard, value). This performs guard.coerce(value, ...); if the guard fails, or returns a reference which is not the same as the original value, then the resulting CoercedSlot has LostApproval[guard] instead of the original guard. LostApproval is equivalent to [[any]], and is used merely to report what the original guard was and why it is missing.	+	CoercedSlots are PassByConstruction; their uncall is makeCoercedSlot.attempt(guard, value). This performs guard.coerce(value, ...); if the guard fails, or returns a reference which is not the same as the original value, then the resulting CoercedSlot has LostApproval[guard] instead of the original guard. LostApproval is equivalent to [[any]], and is used merely to report what the original guard was and why it is missing. (XXX LostApproval is not implemented in E-on-CL)

	==Implications for auditors==		==Implications for auditors==

Kevin Reid: update to match new design decisions; possibly not complete

Kevin Reid — Sun, 23 Mar 2008 15:57:00 GMT

update to match new design decisions; possibly not complete

←Older revision		Revision as of 15:57, 23 March 2008
Line 3:		Line 3:
	==Basic implementation==		==Basic implementation==

-	[[~~Environment~~]]s ~~holding an opt~~[[~~Guard~~]] ~~along with each binding~~. ~~For each noun, the scope alleges that the corresponding~~ [[slot]] ~~(not~~ slot ~~value!)~~ was returned from that guard (except for object expressions; see below).	+	In [[environment]]s, nouns are associated with "bindings" instead of [[slot]]s. A binding is an object which holds a [[slot]] and a [[guard]], and alleges that that slot was returned from that guard (except for object expressions; see below).

-	~~As a consequence of this, environments must not~~ be [[~~Selfless~~]], ~~since it is not necessarily possible to go from some product of a guard to a value it coerces to~~ the ~~same result~~. ~~They may be~~ [[PassByConstruction]]~~, however~~.	+	Binding objects happen to be very much like immutable [[VarSlot]]s, so they implement the slot protocol and are called [[CoercedSlot]]. CoercedSlots are [[PassByConstruction]] and non-[[transparent]] [[Selfless]].

-	(Note that [[FinalPattern]]s and [[VarPattern]]s must get FinalSlot and VarSlot guards; e.g. <code>def x :int := 1</code> ~~has a guard-~~in~~-environment of~~ <code>FinalSlot[int]</code>.)	+	Note that [[FinalPattern]]s and [[VarPattern]]s must get FinalSlot and VarSlot guards; e.g. <code>def x :int := 1</code> results in the binding object <code>makeCoercedSlot(FinalSlot[int], makeFinalSlot(1), null)</code> (except that implementations may optimize it to not require constructing an intermediate FinalSlot if the guard coerces).

-	~~Environments gain the method fetchGuard~~/2, ~~similar to fetchSlot~~/2.	+	If a pattern does not have a guard, then <code>any</code> is used. Examples: <code>def x := y</code> has a binding guard of <code>[[FinalSlot]][any]</code>, and <code>def &x := y</code> has a binding guard of <code>[[any]]</code>.

-	[[Audition]]s have one relevant method, [[Audition#getGuard/1\|getGuard/1]]. Given a noun (string), it returns the ~~environment's optGuard for that~~ binding. ~~(XXX seems to be some optional/required confusion here. Does this return null, or does it return 'any'? --[[User:Kevin Reid\|Kevin Reid]] 08:58, 19 February 2008 (CST))~~ If the noun is not one of the free variables of the audition's object expression, or if the audit has already terminated, then an exception is thrown.	+	Environments gain the methods fetchBinding/2, getBindings/0 (returns an object mapping nouns to bindings), and getSlots/0 (returns an object mapping nouns to slots), and lose iterate/1.
		+
		+	[[Audition]]s have one relevant method, [[Audition#getGuard/1\|getGuard/1]]. Given a noun (string), it returns the guard of the matching binding. If the noun is not one of the free variables of the audition's object expression, or if the audit has already terminated, then an exception is thrown.

	An additional component on kernel [[ObjectExpr]]s: the "<code>as</code>" clause, syntactically preceding the "<code>implements</code>", behaves like it but with the additional effect of making its value be the guard for the binding of the object name (without coercing the object). That is, <code>def x as Y {}</code> audits x with Y, and also causes the binding to be <code>("x", makeFinalSlot(<x>), FinalSlot[Y])</code>.		An additional component on kernel [[ObjectExpr]]s: the "<code>as</code>" clause, syntactically preceding the "<code>implements</code>", behaves like it but with the additional effect of making its value be the guard for the binding of the object name (without coercing the object). That is, <code>def x as Y {}</code> audits x with Y, and also causes the binding to be <code>("x", makeFinalSlot(<x>), FinalSlot[Y])</code>.
		+
		+	Bindings may be reified in E programs using the prefix && operator. (This is necessary to support nonkernel <code>[[meta.getState]]()</code>.) "&&" is a single token and operator, not two prefix operators. As an expression, it is BindingExpr(NounExpr); as a pattern it is BindingPattern(NounExpr). The pattern does not take a guard like [[SlotPattern]] does.
		+
		+	Because bindings are Selfless, the evaluator need not make any effort to preserve their identities.

	All bindings in the [[safeScope]] expose their values in their guards; that is, they are <code>("foo", bar, FinalSlot[Same[bar]])</code>.		All bindings in the [[safeScope]] expose their values in their guards; that is, they are <code>("foo", bar, FinalSlot[Same[bar]])</code>.
		+
		+	CoercedSlots are PassByConstruction; their uncall is makeCoercedSlot.attempt(guard, value). This performs guard.coerce(value, ...); if the guard fails, or returns a reference which is not the same as the original value, then the resulting CoercedSlot has LostApproval[guard] instead of the original guard. LostApproval is equivalent to [[any]], and is used merely to report what the original guard was and why it is missing.

	==Implications for auditors==		==Implications for auditors==
Line 21:		Line 29:
	==Implications for guards==		==Implications for guards==

-	~~==Open questions==~~	+	To support multiple independently-written auditors on the same object, it must be possible to have single guards which satisfy multiple auditors' criteria. It is also desirable that programmers need not write code to match exactly an auditor's view of what is necessary. Therefore, we add the optional operation rangeSupersetOf/1 to guards.

-	If ~~environments are PassByConstruction, then~~, if a ~~passed~~ guard ~~coerces~~ some ~~slot to a different slot upon unserialization~~, ~~should~~ the ~~binding have~~ the ~~coerced value~~ (i.e. ~~now coerced twice~~), or should ~~the binding forget the guard?~~	+	to rangeSupersetOf(other :Guard) :nullOk[boolean]
		+
		+	If X.rangeSupersetOf(Y) returns true, X is claiming that every value returned by Y (as a guard) would have been returned by X under some circumstances; that is, the 'range' of X is a 'superset of' the range of Y. For example, int.rangeSupersetOf(1..10) should be true, as should DeepFrozen.rangeSupersetOf(int).
		+
		+	Returning false indicates that X is not a range superset of Y; returning null indicates that X doesn't know.
		+
		+	==Open questions==

	[[Category:Unresolved design issues]]<!-- not a perfect fit, but good to have this indexed there -->		[[Category:Unresolved design issues]]<!-- not a perfect fit, but good to have this indexed there -->

Kevin Reid: add to design issues cat

Kevin Reid — Mon, 17 Mar 2008 15:58:54 GMT

add to design issues cat

←Older revision		Revision as of 15:58, 17 March 2008
Line 24:		Line 24:

	If environments are PassByConstruction, then, if a passed guard coerces some slot to a different slot upon unserialization, should the binding have the coerced value (i.e. now coerced twice), or should the binding forget the guard?		If environments are PassByConstruction, then, if a passed guard coerces some slot to a different slot upon unserialization, should the binding have the coerced value (i.e. now coerced twice), or should the binding forget the guard?
		+
		+	[[Category:Unresolved design issues]]<!-- not a perfect fit, but good to have this indexed there -->