For context, a brief summary of the consensus agreement we reached at the ES committee meeting:
The EcmaScript Committee will produce two official standards documents: * An ES3.1 standard, to supercede the ES3 standard * An ES4 standard Currently, the ES3 spec as written differs from the de-facto ES3 as implemented by web browsers and as employed by web page authors. * Both ES3.1 and ES4 seek to be a compatible superset of what Brendan calls ES3+Reality. * Both groups will work together to help ensure that ES3.1 be a compatible subset of ES4, i.e., that ES4 be a compatible superset of ES3.1. * The ES3.1 spec will be written by modifying the ES3 spec text, which it will supercede. * The ES4 spec will proceed along its current lines, and will be available as a distinct document. * The ES4 reference implementation (RI), though non-normative, will serve as the initial bridge helping ensure that these two languages have the intended compatibility relationships. * The RI will also serve as the ES3.1 reference implementation -- by testing the subset of its behavior corresponding to the ES3.1 semantics. * When this subset of the RI's behavior differs from the intended semantics of ES3.1, the ES3.1 WG will alert the ES4 WG, so that we can work together to repair the subset relationship. Late Friday, after several people had left, those remaining discussed an interesting refinement. Before I summarize the refinement, I wish to stress that these are not yet points discussed with the committee as a whole. Until the Friday refinement, both ES3.1 and ES4 were going to condition certain restrictions on opting in to the language version. Both would condition further restrictions on opting into "strict mode". The relationship between ES3.1 strict mode and ES4 strict mode was unclear. Late Friday, the ES4 WG presented to the joint group their latest thinking on ES4 strict mode, essentially as summarized by Waldemar. These restrictions, and the removal of the static type checking restriction from ES4 strict mode, makes it essentially compatible with the restrictions needed by ES3.1. With the exception of two issues, it seems we could now have the following set of relationships: a) ES3.1 strict <= ES3.1 b) ES4 strict <= ES4 c) ES3.1 <= ES4 d) ES3.1 strict <= ES4 strict e) 3/4 ES3+R <= ES3.1 f) Caja <= ES3.1 strict where "<=" means "subset". The precise definition of "subset" was not explicitly discussed during the committee meetings, but the intuition seems compatible with the notion of "fail-stop subset" as defined in the Caja spec. #e above means that ES3.1 standard mode would be approximately a codification of ES3+Reality. In other words, for a browser to be compatible with the de-facto use of JavaScript on the web, it should be able to follow the ES3.1 std mode spec faithfully. In fact, the ES3.1 effort started mostly in order to perform this codification. ES3+R is a bit misshappen, especially regarding features like lexically nested functions. The "<=" in #e indicates that ES3.1 will be a bit larger than ES3+R, in order to be a simpler and better defined language that includes ES3+R. The "3/4" in #e indicates that presence in 3/4 of the major browsers (IE, FF, Opera, Safari) was adequate to be a candidate for inclusion. This 3/4 notion needs one further bit of refinement. The hard constraint is not that ES3.1 have an upwards compatible semantics from 3/4 ES3+R, but that it have an upwards compatible syntax. An ES3.1 program should successfully parse on existing most of the current ES3 engines, so that it can inquire about its environment -- by feature testing and comparing MAX_ECMASCRIPT_VERSION -- and then conditionally execute code according to what it finds. This is the hardest constraint separating the ES3* line from the ES4* line. With this background, let's revisit Waldemar's list. On Mon, Mar 31, 2008 at 5:02 PM, Waldemar Horwat <[EMAIL PROTECTED]> wrote: > Here are the items mentioned for inclusion in strict mode: > > - Don't turn a null 'this' value into the global object (if non-strict mode > in ES4 doesn't already do this) Much as I hate this particular privilege escalation hazard, in order to be >= reality, I think this must be sane only in strict mode. ES3.1 and ES4 should be in complete agreement here. > - Throw on writes to read-only properties > - Throw on deletes of dontdelete properties > - delete o.x when x is not in o but in the proto will throw > - Reference before definition causes static errors (in some contexts?) > - Function arity checking at run time (ES4 strict only) I am at a loss on this one. ES3.1 has no alternative way to implement variable arity and optional arguments, even in strict mode. OTOH, I quite understand why ES4 strict wants to enforce this. But these respective stances break the subsetting we desire. It seems we have our first hard case for working together to repair the subset relationship. Ideas? > - Disable global variable auto-creation when referencing one from, for > example, within a function > - Disallow duplicate formal parameters > - Disallow duplicate names in object initializers > - Disable FunctionObject.arguments (not actually in ES3 but woefully used in > practice) > - (Maybe) Disallow use of arguments object (ES4 strict only) After the official meeting broke up completely, several of us (Lars, Dave, Jeff, ??) continued talking in the Mozilla kitchen. A proposal for rescuing the arguments object: In strict mode, the arguments object would be a read-only array. In a function mentioning "arguments", all it parameter variables would be read-only, as if declared with "const". With these restrictions, the strict behavior would both be a fail-stop subset of the standard behavior, and be well behaved. > - (Maybe) Disallow useless expressions > - Prohibit 'with' and locally scoped 'eval'. Globally scoped 'eval', 'new > Function', etc. would still be allowed. -- Text by me above is hereby placed in the public domain Cheers, --MarkM _______________________________________________ Es4-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es4-discuss
