Fwd: Fwd: Draft Proposed Standard SES (Secure EcmaScript)
"Mark S. Miller" <[email protected]> Sat, 19 Mar 2016 11:55:57 -0700
| Newsgroups | gmane.comp.capabilities.general |
|---|---|
| Message-ID | <CABHxS9he6fVS23ucXVQP7heW9Kd2d+k5MHprti7ufEnkiZ8mmg@mail.gmail.com> |
--===============0671237769928319487== Content-Type: multipart/alternative; boundary=089e01160950f6d831052e6b69cf --089e01160950f6d831052e6b69cf Content-Type: text/plain; charset=UTF-8 Forwarded with David's permission. I should mention that my responses both previously and here were written thinking they were going to es-discuss rather than cap-talk. They assume more JS and less ocaps as background than I would have written for this audience. If any of the JS aspects are mysterious, please ask. Thanks. ---------- Forwarded message ---------- From: Mark S. Miller <[email protected]> Date: Sat, Mar 19, 2016 at 11:14 AM Subject: Re: [cap-talk] Fwd: Draft Proposed Standard SES (Secure EcmaScript) To: David Nicol <[email protected]> On Fri, Mar 18, 2016 at 9:46 PM, David Nicol <[email protected]> wrote: > > > On Fri, Mar 18, 2016 at 10:44 PM, Mark S. Miller <[email protected]> > wrote: > >> On Fri, Mar 18, 2016 at 6:34 PM, David Nicol <[email protected]> >> wrote: >> >>> I hope the following makes sense, it is imprecise >>> >>> >>> >>> >>> I have a question. Does SES entirely do away with the "scope chain" and >>> all passing by shared visibility, trading that for explicit object members, >>> or are lexical scopes still available? >>> >> >> Lexical scopes are still exactly as available as they are otherwise. SES >> does nothing whatsoever to change that. Historically, one of the many >> things that motivated me to fight so hard to get true lexical scoping into >> ES5/strict was that the SES-shim needed it. But now that we have it, SES >> does nothing to change it. >> > > what about "variable hoisting" seeming to re-order things? I ask just > because it's confusing coming from Perl, where you can redeclare the same > local symbol repeatedly if you want, to Javascript where you can only > declare a symbol once per scope. > SES does not change JavaScript's scoping rules at all. Everything that does or does not hoist in regular JavaScript does or does not hoist in the same way in SES. Everything that does or does not admit redeclaration in regular JavaScript does so identically in SES. That's why the SES document does not say anything about enhancing, restricting, or altering JavaScript's grammar. In fact it does not mention grammar at all. You can think of many languages as cleanly divided into two major relevant parts, * the nature of the code: flow of control, scoping, etc * the nature of the data it operates on -- primarily the behavior of objects in the heap. SES requires the nature of code to obey the locality we associate with lexical scoping but is otherwise neutral. Since ES5 and later do so, SES does not need to say more here or propose any changes, in order to achieve its fundamental properties. SES requires the nature of objects on the heap to obey the locality we associate with memory safety and object oriented programming (which is the locality of applicative order lambda calculus with local side effects < http://mumble.net/~jar/pubs/secureos/>). SES requires that objects be able to truly encapsulate their state and present a tamper-proof api surface that can defend their invariants from hostile clients. Again, at the object-to-object level ES5 and later do so. Finally, there is the nature of the objects that other objects have implicit (ungranted) access to, either by scoping or by binding to intrinsics. Beyond ES5, locking down the primordials and removing powerful host globals is almost all that additionally needs to be said! I hope the document makes that clear. Nothing in ES2015, ES2016, or draft ES2017 as of March 17 changes any of these fundamentals. Some ES2015 changes, notably the Proxies and WeakMaps that support membranes, are fundamental improvements to the expressiveness of SES. Other post ES5 changes, including syntactic changes like proposed private state, help support the kinds of programming SES is meant to support. But all such changes help support abstraction and modularity generally, and so are, in that sense, independent of SES. Likewise, SES is a great boon to abstraction and modularity, even when security per se is not a concern. In an important way, ocaps are midway between memory safety and pure functional programming. All three limit side effects in order to aid local reasoning about the meaning of programs. When mere memory safety is not enough but pure functional programming is too much, ocaps may be just right ;). WASM and SES SES's independence from syntactic issues is clearest by considering how WASM (WebAssembly) and SES interact. WASM gives us a new form of code with a somewhat different nature, but still limited to the locality properties of lexical scoping. WASM brings in some new primitive data types like various sizes of integer. But because these are immutable SES need not care. WASM does not introduce now objects or API, but rather, operates on the same heap of objects that JavaScript operates on. All the rules about what JavaScript code can and cannot do with these objects applies equally to WASM. Thus, the small set of changes that SES proposes, to turn JavaScript into an ocap language, are *already* sufficient to turn WASM, executing in those same realms, into an ocap language. > > > > >>> If lexical scopes are still available, can the global symbols, that >>> represent immutables, get assigned new representations? That is, can core >>> features get turned off after we're done using them, like >>> >>> function = function(x){ throw }; // we have all the functions we >>> need, further attempts to compile more will fail. >>> >> >> I don't understand the question. "function" is a keyword. It cannot be >> used as a variable name. >> > > I should have written > > function function(){throw}; > > or > > var function = function(x){ throw }; > > as if the keywords are plain symbols like coder-declared ones. > This is just as illegal and meaningless in SES as it is in normal JavaScript. > >> >>> >>> Can the immutables be lexically hidden? >>> >> >> Good question. Yes and no. >> >> You can hide the original global name bindings by several means. The >> fresh global of a new ses realm is a plain mutable object. It initially >> inherits from the proto-global, but you can change that. To have full >> control, you can put what you want on the global and then do >> "freshGlobal.__proto__ = null" (or use Reflect.setPrototypeOf). By wrapping >> any code you execute in a prelude and postlude that shadows globals and >> hides the global object itself, you can also change the bindings of these >> names. >> >> However, this does not enable you to deny access to the intrinsics that >> can be reached by syntax. For example, the expression "[]" in any SES realm >> will create an array that initially inherits from the proto-SES realm's >> Array.prototype, independent of the scoping environment in which that code >> executes. That's why we require everything in the proto-SES realm to be >> transitively immutable and powerless. We assume these objects cannot be >> denied. >> >> Of course, a code rewriting strategy can change what is reachable by >> syntax. But SES does nothing to either help or hurt rewrite-based >> enforcement. >> > > so allowing unlimited external access to eval() may become safe from side > effects, but not from resource-starving DOS attacks; it still isn't > recommended. > Yes, that is true and important. For each type of protection we may ask "at what granularity"? We can partition most (not all) security concerns into * integrity -- loosely, only authorized actions happen * availability -- loosely, authorized actions continue to happen * confidentiality -- loosely, only authorized secrets are learned. The browser's same origin policy defends only integrity. Because code from mutually suspicious origins share an event loop, they are fully vulnerable to each other regarding availability. Among things sharing an event loop, and infinite loop by one blocks all. Finally, browsers don't claim to defend confidentiality against side channels and covert channels. SES, operating within the browser's event loop, cannot do anything about availability and is not in a position to try. However, JavaScript in a non-browser environment like a Node server is in a position to try to defend availability to an important and practical degree. I agree that we need to revise the mobile code example to explain the availability cost in making remote eval available. I was clearer about that in the earlier < http://wiki.ecmascript.org/doku.php?id=strawman:concurrency#open_vat> where the permission to access that remote eval power was explicit and clear. Thanks for pointing this out! SES makes a contribution to the less valuable side of the confidentiality issue: SES helps suppress reading non-overt channels under very restrictive conditions -- where no timing channels are granted -- but does not prevent signaling on these channels. Preventing signaling would be more valuable, but no one has any practical idea how to do that by any means. The big difference is in integrity -- as you say, limiting side effects. Conventional OSes do privilege separation only at the granularity of user/account. The browser same origin policy added another epicycle, extending privilege separation one level, to user-at-origin. But neither was compositional. SES extends privilege separation within an origin. But it does not add yet another level of epicycle. It enables privileges to be separated and composed effectively down to very fine grain. > > >> By allowing hiding, you might be able to avoid having to construct a new >>> eval function with each realm unless you really need one. That is, >>> leave "eval" out of the core language, and put in its place >>> evalFactory(topRealm) >>> >> >> I'm sorry, I don't understand the suggestion. What does evalFactory do? >> > > evalFactory is supposed to generate an eval function whose scope chain > stops at the argument, which is expected to be a scope, if the with > statement caused new vars declared within its block to go in the scope > (which it doesn't) it would be like so > > > function evalFactory(S){ > return function ( src ) { > fancyWritingWith(S) { eval(src) } > }; > }; > > http://www.2ality.com/2011/06/with-statement.html > This has some similarity to the internal technique used by the SES-shim to control global scoping, but it is very different from SES. > > SES still isn't about creating little languages that are invoked with a > near-native eval keyword, and that isn't a criticism of it. > Correct and thanks. > > Thanks > > > >>> >>> >>>> It is now ready for comments at https://github.com/FUDCo/ses-realm >>>> >>> -- Cheers, --MarkM --089e01160950f6d831052e6b69cf Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div>Forwarded with David's permission. I should menti= on that my responses both previously and here were written thinking they we= re going to es-discuss rather than cap-talk. They assume more JS and less o= caps as background than I would have written for this audience. If any of t= he JS aspects are mysterious, please ask. Thanks.</div><div><br></div><br><= div class=3D"gmail_quote">---------- Forwarded message ----------<br>From: = <b class=3D"gmail_sendername">Mark S. Miller</b> <span dir=3D"ltr"><<a h= ref=3D"mailto:[email protected]">[email protected]</a>></span><br>Date= : Sat, Mar 19, 2016 at 11:14 AM<br>Subject: Re: [cap-talk] Fwd: Draft Propo= sed Standard SES (Secure EcmaScript)<br>To: David Nicol <<a href=3D"mail= to:[email protected]">[email protected]</a>><br><br><br><div dir= =3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><span class= =3D"">On Fri, Mar 18, 2016 at 9:46 PM, David Nicol <span dir=3D"ltr"><<a= href=3D"mailto:[email protected]" target=3D"_blank">[email protected]= m</a>></span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margi= n:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204= );border-left-style:solid;padding-left:1ex"><div dir=3D"ltr"><br><div class= =3D"gmail_extra"><br><div class=3D"gmail_quote"><span>On Fri, Mar 18, 2016 = at 10:44 PM, Mark S. Miller <span dir=3D"ltr"><<a href=3D"mailto:erights= @google.com" target=3D"_blank">[email protected]</a>></span> wrote:<br>= <blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-= left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;p= adding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"= gmail_quote"><span>On Fri, Mar 18, 2016 at 6:34 PM, David Nicol <span dir= =3D"ltr"><<a href=3D"mailto:[email protected]" target=3D"_blank">davi= [email protected]</a>></span> wrote:<br><blockquote class=3D"gmail_quote"= style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:= rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir=3D"ltr"= ><div>I hope the following makes sense, it is imprecise</div><div><br></div= ><div><br></div><div><br></div><br><div>I have a question. Does SES entirel= y do away with the "scope chain" and all passing by shared visibi= lity, trading that for explicit object members, or are lexical scopes still= available?</div></div></blockquote><div><br></div></span><div>Lexical scop= es are still exactly as available as they are otherwise. SES does nothing w= hatsoever to change that. Historically, one of the many things that motivat= ed me to fight so hard to get true lexical scoping into ES5/strict was that= the SES-shim needed it. But now that we have it, SES does nothing to chang= e it.</div></div></div></div></blockquote><div><br></div></span><div>what a= bout "variable hoisting" seeming to re-order things? I ask just b= ecause it's confusing coming from Perl, where you can redeclare the sam= e local symbol repeatedly if you want, to Javascript where you can only dec= lare a symbol once per scope.</div></div></div></div></blockquote><div><br>= </div><div><br></div></span><div>SES does not change JavaScript's scopi= ng rules at all. Everything that does or does not hoist in regular JavaScri= pt does or does not hoist in the same way in SES. Everything that does or d= oes not admit redeclaration in regular JavaScript does so identically in SE= S. That's why the SES document does not say anything about enhancing, r= estricting, or altering JavaScript's grammar. In fact it does not menti= on grammar at all.=C2=A0</div><div><br></div><div>You can think of many lan= guages as cleanly divided into two major relevant parts,=C2=A0</div><div><b= r></div><div>=C2=A0 * the nature of the code: flow of control, scoping, etc= </div><div>=C2=A0 * the nature of the data it operates on -- primarily the = behavior of objects in the heap.=C2=A0</div><div><br></div><div>SES require= s the nature of code to obey the locality we associate with lexical scoping= but is otherwise neutral. Since ES5 and later do so, SES does not need to = say more here or propose any changes, in order to achieve its fundamental p= roperties.=C2=A0</div><div><br></div><div>SES requires the nature of object= s on the heap to obey the locality we associate with memory safety and obje= ct oriented programming (which is the locality of applicative order lambda = calculus with local side effects <<a href=3D"http://mumble.net/~jar/pubs= /secureos/" target=3D"_blank">http://mumble.net/~jar/pubs/secureos/</a>>= ). SES requires that objects be able to truly encapsulate their state and p= resent a tamper-proof api surface that can defend their invariants from hos= tile clients. Again, at the object-to-object level ES5 and later do so.</di= v><div><br></div><div>Finally, there is the nature of the objects that othe= r objects have implicit (ungranted) access to, either by scoping or by bind= ing to intrinsics. Beyond ES5, locking down the primordials and removing po= werful host globals is almost all that additionally needs to be said! I hop= e the document makes that clear. Nothing in ES2015, ES2016, or draft ES2017= as of March 17 changes any of these fundamentals. Some ES2015 changes, not= ably the Proxies and WeakMaps that support membranes, are fundamental impro= vements to the expressiveness of SES. Other post ES5 changes, including syn= tactic changes like proposed private state, help support the kinds of progr= amming SES is meant to support. But all such changes help support abstracti= on and modularity generally, and so are, in that sense, independent of SES.= =C2=A0</div><div><br></div><div>Likewise, SES is a great boon to abstractio= n and modularity, even when security per se is not a concern. In an importa= nt way, ocaps are midway between memory safety and pure functional programm= ing. All three limit side effects in order to aid local reasoning about the= meaning of programs. When mere memory safety is not enough but pure functi= onal programming is too much, ocaps may be just right ;).</div><div><br></d= iv><div>WASM and SES</div><div><br></div><div>SES's independence from s= yntactic issues is clearest by considering how WASM (WebAssembly) and SES i= nteract. WASM gives us a new form of code with a somewhat different nature,= but still limited to the locality properties of lexical scoping. WASM brin= gs in some new primitive data types like various sizes of integer. But beca= use these are immutable SES need not care. WASM does not introduce now obje= cts or API, but rather, operates on the same heap of objects that JavaScrip= t operates on. All the rules about what JavaScript code can and cannot do w= ith these objects applies equally to WASM. Thus, the small set of changes t= hat SES proposes, to turn JavaScript into an ocap language, are <i><b>alrea= dy</b></i>=C2=A0sufficient to turn WASM, executing in those same realms, in= to an ocap language.</div><span class=3D""><div><br></div><div><br></div><d= iv>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0p= x 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-lef= t-style:solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_extra"= ><div class=3D"gmail_quote"><div>=C2=A0</div><span><div><br></div><div><br>= </div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;b= order-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:s= olid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_extra"><div cla= ss=3D"gmail_quote"><span><blockquote class=3D"gmail_quote" style=3D"margin:= 0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);= border-left-style:solid;padding-left:1ex"><div dir=3D"ltr"><div><br></div><= div>If lexical scopes are still available, can the global symbols, that rep= resent immutables, get assigned new representations? That is, can core feat= ures get turned off after we're done using them, like</div><div><br></d= iv><div>=C2=A0 =C2=A0 =C2=A0 function =3D function(x){ throw }; // we have = all the functions we need, further attempts to compile more will fail.</div= ></div></blockquote><div><br></div></span><div>I don't understand the q= uestion. "function" is a keyword. It cannot be used as a variable= name.</div></div></div></div></blockquote><div><br></div></span><div>I sho= uld have written</div><div><br></div><div>=C2=A0 =C2=A0 =C2=A0 function fun= ction(){throw};</div><div><br></div><div>or</div><div><br></div><div>=C2=A0= =C2=A0 =C2=A0 var function =3D function(x){ throw };</div><div><br></div><= div>as if the keywords are plain symbols like coder-declared ones.=C2=A0</d= iv></div></div></div></blockquote><div><br></div></span><div>This is just a= s illegal and meaningless in SES as it is in normal JavaScript.</div><span = class=3D""><div><br></div><div><br></div><div>=C2=A0</div><blockquote class= =3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;bo= rder-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">= <div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><spa= n><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;borde= r-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid= ;padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_extra"><div class= =3D"gmail_quote"><span><div>=C2=A0</div><blockquote class=3D"gmail_quote" s= tyle=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rg= b(204,204,204);border-left-style:solid;padding-left:1ex"><div dir=3D"ltr"><= div class=3D"gmail_extra"><div class=3D"gmail_quote"><br></div><div class= =3D"gmail_quote">Can the immutables be lexically hidden?</div></div></div><= /blockquote><div><br></div></span><div>Good question. Yes and no.=C2=A0</di= v><div><br></div><div>You can hide the original global name bindings by sev= eral means. The fresh global of a new ses realm is a plain mutable object. = It initially inherits from the proto-global, but you can change that. To ha= ve full control, you can put what you want on the global and then do "= freshGlobal.__proto__ =3D null" (or use Reflect.setPrototypeOf). By wr= apping any code you execute in a prelude and postlude that shadows globals = and hides the global object itself, you can also change the bindings of the= se names.</div><div><br></div><div>However, this does not enable you to den= y access to the intrinsics that can be reached by syntax. For example, the = expression "[]" in any SES realm will create an array that initia= lly inherits from the proto-SES realm's Array.prototype, independent of= the scoping environment in which that code executes. That's why we req= uire everything in the proto-SES realm to be transitively immutable and pow= erless. We assume these objects cannot be denied.</div><div><br></div><div>= Of course, a code rewriting strategy can change what is reachable by syntax= . But SES does nothing to either help or hurt rewrite-based enforcement.</d= iv></div></div></div></blockquote><div><br></div></span><div>so allowing un= limited external access to eval() may become safe from side effects, but no= t from resource-starving DOS attacks; it still isn't recommended.</div>= </div></div></div></blockquote><div><br></div></span><div>Yes, that is true= and important. For each type of protection we may ask "at what granul= arity"? We can partition most (not all) security concerns into=C2=A0</= div><div><br></div><div>=C2=A0 * integrity -- loosely, only authorized acti= ons happen</div><div>=C2=A0 * availability -- loosely, authorized actions c= ontinue to happen</div><div>=C2=A0 * confidentiality -- loosely, only autho= rized secrets are learned.</div><div><br></div><div>The browser's same = origin policy defends only integrity. Because code from mutually suspicious= origins share an event loop, they are fully vulnerable to each other regar= ding availability. Among things sharing an event loop, and infinite loop by= one blocks all. Finally, browsers don't claim to defend confidentialit= y against side channels and covert channels.</div><div><br></div><div>SES, = operating within the browser's event loop, cannot do anything about ava= ilability and is not in a position to try. However, JavaScript in a non-bro= wser environment like a Node server is in a position to try to defend avail= ability to an important and practical degree. I agree that we need to revis= e the mobile code example to explain the availability cost in making remote= eval available. I was clearer about that in the earlier <<a href=3D"htt= p://wiki.ecmascript.org/doku.php?id=3Dstrawman:concurrency#open_vat" target= =3D"_blank">http://wiki.ecmascript.org/doku.php?id=3Dstrawman:concurrency#o= pen_vat</a>> where the permission to access that remote eval power was e= xplicit and clear. Thanks for pointing this out!</div><div><br></div><div>S= ES makes a contribution to the less valuable side of the confidentiality is= sue: SES helps suppress reading non-overt channels under very restrictive c= onditions -- where no timing channels are granted -- but does not prevent s= ignaling on these channels. Preventing signaling would be more valuable, bu= t no one has any practical idea how to do that by any means.</div><div><br>= </div><div>The big difference is in integrity -- as you say, limiting side = effects. Conventional OSes do privilege separation only at the granularity = of user/account. The browser same origin policy added another epicycle, ext= ending privilege separation one level, to user-at-origin. But neither was c= ompositional. SES extends privilege separation within an origin. But it doe= s not add yet another level of epicycle. It enables privileges to be separa= ted and composed effectively down to very fine grain.</div><span class=3D""= ><div><br></div><div><br></div><div><br></div><blockquote class=3D"gmail_qu= ote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-co= lor:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir=3D"= ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><div><br></div><= div>=C2=A0=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0px= 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);bor= der-left-style:solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail= _extra"><div class=3D"gmail_quote"><span><span><blockquote class=3D"gmail_q= uote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-c= olor:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir=3D= "ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"> By allowing hi= ding, you might be able to avoid having to construct a new eval function wi= th each realm unless you really need one. That is,</div><div class=3D"gmail= _quote">leave "eval" out of the core language, and put in its pla= ce evalFactory(topRealm)</div></div></div></blockquote><div><br></div></spa= n></span><span><div>I'm sorry, I don't understand the suggestion. W= hat does evalFactory do?</div></span></div></div></div></blockquote><div><b= r></div><div>evalFactory is supposed to generate an eval function whose sco= pe chain stops at the argument, which is expected to be a scope, if the wit= h statement caused new vars declared within its block to go in the scope (w= hich it doesn't) it would be like so</div><div><br></div><div><br></div= ><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0function evalFactory(S){</div><div>= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0return function ( sr= c ) {</div><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0fancyWritingWith(S) { eval(src) }</div><div>=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0};</div><div>=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0};</div><div><br></div><div><a href=3D"http://www.2ality.com/2= 011/06/with-statement.html" target=3D"_blank">http://www.2ality.com/2011/06= /with-statement.html</a></div></div></div></div></blockquote><div><br></div= ></span><div>This has some similarity to the internal technique used by the= SES-shim to control global scoping, but it is very different from SES.</di= v><span class=3D""><div><br></div><div>=C2=A0</div><blockquote class=3D"gma= il_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-le= ft-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div di= r=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><div><br></= div><div>SES still isn't about creating little languages that are invok= ed with a near-native eval keyword, and that isn't a criticism of it.</= div></div></div></div></blockquote><div><br></div></span><div>Correct and t= hanks.</div><span class=3D""><div><br></div><div>=C2=A0</div><blockquote cl= ass=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px= ;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1e= x"><div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><= div><br></div><div>Thanks</div><span><div><br></div><div><br></div><blockqu= ote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-wid= th:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-l= eft:1ex"><div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_qu= ote"><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;bo= rder-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:so= lid;padding-left:1ex"><span><div dir=3D"ltr"><div class=3D"gmail_extra"><sp= an><div class=3D"gmail_quote"><br></div><div class=3D"gmail_quote"><br></di= v><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"mar= gin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,2= 04);border-left-style:solid;padding-left:1ex"><div dir=3D"ltr"><div class= =3D"gmail_quote"><div dir=3D"ltr"><div><br></div><div>It is now ready for c= omments at=C2=A0<a href=3D"https://github.com/FUDCo/ses-realm" target=3D"_b= lank">https://github.com/FUDCo/ses-realm</a></div></div></div></div></block= quote></div></span></div></div></span></blockquote></div></div></div></bloc= kquote></span></div> </div></div> </blockquote></span></div><span class=3D"HOEnZb"><font color=3D"#888888"><b= r><br clear=3D"all"><div><br></div></font></span></div></div></div><div><br= ></div>-- <br><div class=3D"gmail_signature">=C2=A0 =C2=A0 Cheers,<br>=C2= =A0 =C2=A0 --MarkM</div> </div> --089e01160950f6d831052e6b69cf-- --===============0671237769928319487== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ cap-talk mailing list [email protected] http://www.eros-os.org/mailman/listinfo/cap-talk --===============0671237769928319487==--