On Nov 13, 2010, at 8:41 AM, Geoffrey Sneddon wrote:
> On 27/10/10 21:38, Brendan Eich wrote:
>>> Is there consensus that this is defacto standard behavior that is needed for interoperability among browsers and that it should be incorporated into Harmony?
>>>> I suspect this is a de-facto standard we should codify in Harmony. Thanks for bringing it up.
>> How much of de-facto standards are going to be codified? What about things which aren't entirely interoperability implemented, but the basic premise is an absolute requirement for web compatibility (e.g., the recent thread on function hoisting).
Allen explicitly addressed this in his reply on that thread:
> From the ES5 spec section 12 statement semantics:
>> NOTE Several widely used implementations of ECMAScript are known to support the use of FunctionDeclaration as a Statement. However there are significant and irreconcilable variations among the implementations in the semantics applied to such FunctionDeclarations. Because of these irreconcilable differences , the use of a FunctionDeclaration as a Statement results in code that is not reliably portable among implementations. It is recommended that ECMAScript implementations either disallow this usage of FunctionDeclaration or issue a warning when such a usage is encountered. Future editions of ECMAScript may define alternative portable means for declaring functions in a Statement context.
>> Also see section on functions in http://blogs.msdn.com/b/ie/archive/2010/08/25/chakra-interoperability-means-more-than-just-standards.aspx>> There seem to be more browsers that treat function declarations in blocks as straightforward extensions of the function hoisting semantics (unconditionally) but Firefox does something different.
>> As I say in the above blog post, you have to have them in a browser but anything other than trivial usage is unlike to be interoperable.
>> Allen
When browsers do not implement the same (within epsilon) semantics for certain syntax put forth in a would-be de-facto standard, obviously browser-independent web content cannot count on more than the intersection semantics.
Ecma TC39 is not going to standardize union-semantics (browser X does A, browser Y does B, etc.).
This leaves us with room to draft, prototype-implement, user-test, and ultimately de-jure-standardize a better common semantics for the given syntax. That's the plan for functions in blocks, as noted several times on this list over the years. There's a placeholder on the wiki:
http://wiki.ecmascript.org/doku.php?id=harmony:block_functions
but the action is happening here:
http://wiki.ecmascript.org/doku.php?id=harmony:block_scoped_bindings
Both are linked from
http://wiki.ecmascript.org/doku.php?id=harmony:proposals
> What about things which are needed for web compatibility, interoperability implemented, but disallowed in ES5/Strict (e.g., Function.arguments, Function.caller, octal escapes (which are defined differently to all impls as raised before ES5 was finalized), etc.)?
Those are more interoperably implemented, although perhaps not perfectly. No ECMA standard bothered to specify them -- a failing on the committee's part, or (some argue) a shunning that these monstrosities deserved, to help drive them away.
How'd that shunning work out? Not so well.
Nevertheless, we have no plans to standardize these in a future spec, and Harmony builds on ES5 strict which poisons the properties. This is not just "shun harder", in all cases. We're trying to add new and better forms to get people away from the bad old thing (rest params and default parameter values instead of arguments).
Octal we've covered on this list, most recently at:
https://mail.mozilla.org/pipermail/es5-discuss/2010-February/003502.html
where you started the thread ;-).
I think everyone who posted was neutral or positive on allowing "\0" for the NUL character in strings.
Allen replied here:
https://mail.mozilla.org/pipermail/es5-discuss/2010-February/003507.html
proposing an "approved extensions" list. We haven't built that yet, but it might be the way to handle the de-facto standards that have enough intersection semantics to be usable cross-browser.
> I'd very much like to get to a point where you can implement something web compatible from the spec, which would mean defining things some don't like, and changing other definitions that people don't like either… At the moment, it's impossible to implement a fully compliant ES5 implementation without sacrificing web compatibility.
You're right. For functions in blocks, we have a plan. For octal, some agreement to allow \0 but nothing more (shun harder, I think). For foo.arguments, shun and also add better replacements. For arguments.caller, shun.
This is not a great plan.
An "extensions list" covering what's needed for web compatibility would be helpful, whether it's part of an ECMA-262 spec or a companion spec or TR.
We have to draw the line carefully. For example, what about callable regexps? They are something Mozilla added long ago, WebKit JSC (and therefore V8) cloned, but not in IE or (AFAIK) Opera. typeof /hi/ == "object" not "function", in spite of the callability, and David-Sarah Hopwood pointed out that ES3 and ES5 do not allow [[Call]] to be defined on RegExp instances (their internal methods are fully specified).
We're trying to remove callable regexps, in coordination with JSC and V8 folks, so we do not want even a "extension list for non-IE or !document.all web content compatibility".
Let's start with the list that you've outlined:
- function declaration in block
- octal in general
- \0 in strings
- non-\0 in strings
- arguments.callee (ES5 strict mode error)
- arguments.caller (ES5 strict mode error)
- foo.caller given function foo (ES5 strict mode error)
- foo.arguments given function foo
Anything else?
Any testing data you or others have that demonstrates web usage of the more obscure of these would be great.
/be