It's just a document copyrighted by ecma that happens to mostly be code and is largely derivate from the ES5 spec. which is also copyrighted by Ecma. Paranoia about reading it is a matter between you and your lawyers.
Allen From: Mark S. Miller [mailto:erig...@google.com] Sent: Thursday, May 20, 2010 1:37 PM To: Allen Wirfs-Brock Cc: Joseph Politz; Arjun Guha; Ankur Taly; John Mitchell; Sergio Maffeis; es-discuss@mozilla.org Subject: Re: Specification Language On Thu, May 20, 2010 at 9:11 AM, Allen Wirfs-Brock <allen.wirfs-br...@microsoft.com<mailto:allen.wirfs-br...@microsoft.com>> wrote: There is another approach to using JavaScript to specify JavaScript that we have discussed within TC39. The idea to use the exact same style of specification as current used for ES5 but to use JavaScript as the "meta language" rather than pseudo-code. Because this work is relevant to this discussion but hasn't had visibility outside of TC39 I've made it available on the ES wiki: http://wiki.ecmascript.org/lib/exe/fetch.php?id=strawman%3Astrawman&cache=cache&media=strawman:es5definterp.js.txt Hi Allen, As you know, I have avoided looking at this until the IPR situation was straightened out. Since it now seems to be, could you (or someone representing Ecma) repost this with a BSD license? Everyone concerned about keeping their brain free of unnecessary proprietary contamination, I suggest not clicking on the link above until we get an ack that the text at that link has been reposted with an open source license. Allen From: es-discuss-boun...@mozilla.org<mailto:es-discuss-boun...@mozilla.org> [mailto:es-discuss-boun...@mozilla.org<mailto:es-discuss-boun...@mozilla.org>] On Behalf Of Mark S. Miller Sent: Thursday, May 20, 2010 8:52 AM To: Joseph Politz; Arjun Guha; Ankur Taly; John Mitchell; Sergio Maffeis Cc: es-discuss@mozilla.org<mailto:es-discuss@mozilla.org> Subject: Re: Specification Language On Thu, May 20, 2010 at 8:49 AM, Mark S. Miller <erig...@google.com<mailto:erig...@google.com>> wrote: I'd just like to express my enthusiasm for taking a formal approach to the kernel language. For everything outside the kernel, defining it by self-hosting, by a meta-circular interpreter (where the interpreter is written only in the kernel subset of the language) or by desugaring is fine. These other techniques may or may not be ideal for expressing the semantics of these non-kernel constructs, but it does ensure that an adversary's code cannot take any action beyond those actions allowed by the kernel language. All security reasoning is reasoning about limits on what an adversary may do. Thus, all security arguments rest on an induction over all the actions available to the adversary. I think it is no accident that both prominent attempts to formalize the semantics of JS (LambdaJS and <http://www-cs-students.stanford.edu/~ataly/Papers/>) took security as their driving motivation. I had meant to link to <http://www-cs-students.stanford.edu/~ataly/#publications> above. The related pressing issue is how to tighten up the chapter 16 exemptions. So long as these exemptions are this broad, the induction is broken and all security arguments are unsound. I do not yet have concrete suggestions about how we can tighten these up in ways that JS vendors will agree to. But until we do, we are just as vulnerable to disasters such as having "foo[-6]", for function foo, give foo's caller. By ch16, the major browser that did indeed ship this cannot even be said to have violated the spec. This simple extension allowed by ch16 simultaneously broke all secure JS subsets (Caja, FBJS, WebSandbox, ADsafe, Jacaranda) and all proof about security of any possible subsets. On Wed, May 19, 2010 at 7:03 PM, Joseph Politz <j...@cs.brown.edu<mailto:j...@cs.brown.edu>> wrote: > d) If you're serious about suggesting lambda-JS as a basis (or starting > point, anyway) for future editions of ECMA-262, may I make a suggestion? Do a > proof-of-concept by taking the ES5 document and rewriting some of it in your > suggested style. If I understand your suggestion right, this is exactly what's going on here: http://github.com/arjunguha/ML-LambdaJS/blob/master/data/es5-lib.es5 In the repo Arjun pointed to (http://github.com/arjunguha/ML-LambdaJS), there is: 1. An updated LambdaJS for ES5, with an interpreter; 2. An implementation of desugaring (elaboration) from JavaScript source to ES5-LambdaJS; 3. A start at writing down built-in objects and functions from the specification in ES5-LambdaJS. The implementation passes around 5-6% of the tests at http://es5conform.codeplex.com/, predominantly those that test the object model (e.g. Object.defineProperty, Object.getOwnPropertyDescriptor). We're on our way to implementing more of the built-in objects' functionality. We are serious about using LambdaJS to model real JavaScript, and we're quite focused on getting the abstractions right at the levels of semantics, libraries, and elaboration. I'd love for people to check out the implementation and give feedback on this and any other issues as we move forward with it. Joe _______________________________________________ es-discuss mailing list es-discuss@mozilla.org<mailto:es-discuss@mozilla.org> https://mail.mozilla.org/listinfo/es-discuss -- Cheers, --MarkM -- Cheers, --MarkM -- Cheers, --MarkM
_______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
