Guard-based auditing
From Erights
(update on status, use XXX) |
Kevin Reid (Talk | contribs) (describe guard-based auditing plan so far) |
||
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 | + | 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]]. |
- | + | ||
- | + | ||
==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). | |
- | + | 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. | |
- | Note that [[FinalPattern]]s and [[VarPattern]]s must get | + | (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>.) |
- | + | Environments gain the method fetchGuard/2, similar to fetchSlot/2. | |
- | + | [[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. | |
- | + | 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> | + | |
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
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>. | ||
- | |||
- | |||
==Implications for auditors== | ==Implications for auditors== | ||
- | |||
- | |||
==Implications for guards== | ==Implications for guards== | ||
- | |||
- | |||
- | |||
- | |||
- | |||
- | |||
- | |||
- | |||
==Open questions== | ==Open questions== | ||
- | + | 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? | |
- | + | ||
- | + | ||
- | + |
Revision as of 14:58, 19 February 2008
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.
Contents |
Basic implementation
Environments holding an optGuard 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).
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.
(Note that FinalPatterns and VarPatterns must get FinalSlot and VarSlot guards; e.g. def x :int := 1
has a guard-in-environment of FinalSlot[int]
.)
Environments gain the method fetchGuard/2, similar to fetchSlot/2.
Auditions have one relevant method, 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'? --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.
An additional component on kernel ObjectExprs: the "as
" clause, syntactically preceding the "implements
", 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, def x as Y {}
audits x with Y, and also causes the binding to be ("x", makeFinalSlot(<x>), FinalSlot[Y])
.
All bindings in the safeScope expose their values in their guards; that is, they are ("foo", bar, FinalSlot[Same[bar]])
.
Implications for auditors
Implications for guards
Open questions
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?