A random collection of ES4 draft spec surprises and thoughts

classic Classic list List threaded Threaded
17 messages Options
Reply | Threaded
Open this post in threaded view
|

A random collection of ES4 draft spec surprises and thoughts

Mark S. Miller-2
In going over the ES4 draft spec docs, I found the following things surprising:

                      Grammar

* The BOM sequence shall be "replaced with a single white space
character". Which one? Should we say instead "treated as a single
whitespace character"?

* What's "__proto__" doing in the grammar? If we want to provide
access to the internal [[Prototype]] property (as I think we do), we
should do that explicitly with a reflective operation such as
Object.prototypeOf(obj). But please let's avoid turning this internal
property into a named property. Doing so breaks the subset
relationship between JSON and EcmaScript. (Granted, we also need to
acknowledge that this relationship is currently broken by Firefox. But
part of the purpose of standards is to encourage browser vendors to
repair their implementations.)

* What's ">=="? I've never seen that before.

* What does the "var" attribute mean inside an object literal?

* Now that we have let-at-the-new-var, i.e., a properly lexically
scoped letrec behavior, do we still need the "let" expression and the
"let" comprehension? Can we kill these?

* Why does the grammar allow function calls in
LeftHandSideExpressions. For example, what's the meaning of

    foo(a)++

?

* Why does delete operate on a PostFixExpression rather than a
LeftHandSideExpression? What's the meaning of

    delete x++;

?

* I thought "like" was dead. How did it get revived?

* What is

   "super" "(" Arguments ")"

? Last I heard, ES4 only has single implementation inheritance, so why
allow "super" to be qualified?


           Core Semantics

* I'm pleasantly surprised to see that the prototype reference (which
I take to be the same as the ES3 internal [[Prototype]] property) is
said to be immutable. Does this mean that we will be able to consider
the following behavior buggy (I hope so):

    var x = {};

    var y = {};

    x.__proto__ = y;
    [object Object]

    y.foo = 3;
    3

    x.foo
    3

* What namespace is "__ES4__" defined in? The text "The namespace
__ES4__is predefined. It is used to tag global names that have been
introduced in the 4th edition" would seem to indicate that __ES4__ is
itself defined in the namespace __ES4__. I'm probably missing or
confused about something.

* Unicode only has 21 bits of significance. That's enough headroom
that we should expect Unicode to live within these limits until the
United Federation of Planets makes peace with the Romulans and the
Klingons. So why is a string value defined as "a finite ordered
sequence of zero or more 32 bit unsigned integer values"?

* What does "Rib" mean? Is it an acronym?

* Is "A catch-all method operates on the object that contains the
method." a mistake? Did you mean "operates on the invoked object"?



--
    Cheers,
    --MarkM
_______________________________________________
Es4-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es4-discuss
Reply | Threaded
Open this post in threaded view
|

Re: A random collection of ES4 draft spec surprises and thoughts

Mike Shaver
On Mon, May 26, 2008 at 2:06 PM, Mark S. Miller <[hidden email]> wrote:
> * What's ">=="? I've never seen that before.

I presume it's ">= but with no type coercion".

Mike
_______________________________________________
Es4-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es4-discuss
Reply | Threaded
Open this post in threaded view
|

Re: A random collection of ES4 draft spec surprises and thoughts

Graydon Hoare-3
In reply to this post by Mark S. Miller-2
Mark S. Miller wrote:
> In going over the ES4 draft spec docs, I found the following things surprising:

I can't answer all of these, but can a few. Most of the grammar
questions are outside of things I know.

> * I thought "like" was dead. How did it get revived?

As a (value * type) binary operator, rather than as a type. It also
(presently) has a form in which it can annotate a function parameter,
which implicitly causes the an assertion of the operator against the
provided type when the function is entered. This annotation behavior on
function parameter lists is something I'm not terribly pleased with, but
then, the most natural boundary between annotated and unannotated code
appears to be that of a function call, so it's possibly sensible to
leave extra conveniences there.

> * What is
>
>    "super" "(" Arguments ")"
>
> ? Last I heard, ES4 only has single implementation inheritance, so why
> allow "super" to be qualified?

I don't know what you mean by qualified. That's a form for either
constructor-chaining or dispatching to a parent method with the same
name as the current method.

> * I'm pleasantly surprised to see that the prototype reference (which
> I take to be the same as the ES3 internal [[Prototype]] property) is
> said to be immutable. Does this mean that we will be able to consider
> the following behavior buggy (I hope so):

Yes.

> * What namespace is "__ES4__" defined in? The text "The namespace
> __ES4__is predefined. It is used to tag global names that have been
> introduced in the 4th edition" would seem to indicate that __ES4__ is
> itself defined in the namespace __ES4__. I'm probably missing or
> confused about something.

Sorry about this. There was text in the section on names that clarified
the root namespace bindings but it appears to have been cut during some
rewriting. I'll try to ensure it shows up again.

At the moment the ES4 namespace is visible as the global property
__ES4__ to 3rd edition code, because it is bound to the global name
""::__ES4__ and 3rd edition code has the transparent public namespace ""
open in its root scope. This is the "backwards compatibility hazard" if
some 3rd edition code happens to accidentally wish to reuse the global
variable __ES4__.

All other names introduced are qualified by the ES4 namespace, or by
namespaces that are themselves qualified by the ES4 namespace (including
things like the "public" synonym for the transparent public namespace;
that's actually bound to __ES4__::public). So 3rd edition code is not
going to collide with such names, since 3rd edition code is never going
to contain a name expression __ES4__::foo that would be necessary to
start digging around in that namespace.

The ES4 namespace is open in the root scope of any 4th edition code.
You're right that we could possibly get away with only binding the ES4
namespace to, essentially, <ES4>::__ES4__, where <ES4> is the opaque
namespace object itself. We don't do that at present, but we've tried to
keep any name pollution to a minimum so this might be a desirable final
touch if we can make it work.

> * Unicode only has 21 bits of significance. That's enough headroom
> that we should expect Unicode to live within these limits until the
> United Federation of Planets makes peace with the Romulans and the
> Klingons. So why is a string value defined as "a finite ordered
> sequence of zero or more 32 bit unsigned integer values"?

Because a string value in the 3rd edition is defined as "a finite
ordered sequence of zero or more 16 bit unsigned integer values".
Emphatically *not* as a unicode string. Unicode strings are a useful
subset of what a 3rd edition string value can hold, but they're not
defined that way. In particular, the private surrogate range is totally
fair game in 3rd edition implementations. The expansion to 32 bits is
simply a matter of utility: it's much more useful in general to have a
dense u32 sequence than a dense u21 sequence.

> * What does "Rib" mean? Is it an acronym?

Not an acronym. A rib is a (name -> fixture) binding map. It defines the
set of fixed properties that will exist in a scope or an instance.

There is some redundancy between ribs and non-value property states, in
the present RI. I'm in the process of eliminating this redundancy in
favour of relying on ribs directly, and using properties only to model
what's now called the value state.

-Graydon
_______________________________________________
Es4-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es4-discuss
Reply | Threaded
Open this post in threaded view
|

Re: A random collection of ES4 draft spec surprises and thoughts

Jason Orendorff
In reply to this post by Mark S. Miller-2
I can answer two more :)

On Mon, May 26, 2008 at 1:06 PM, Mark S. Miller <[hidden email]> wrote:
> * What does the "var" attribute mean inside an object literal?

See Lars's "ES4 stable draft: Object initializers":
  https://mail.mozilla.org/pipermail/es4-discuss/2008-April/002668.html

> * Why does the grammar allow function calls in
> LeftHandSideExpressions. For example, what's the meaning of
>
>    foo(a)++
>
> ?

As far as I know, this is unchanged from ES3, in which "functions are
permitted to return References" but "This possibility is admitted
purely for the sake of host objects. No built-in ECMAScript function
defined by this specification returns a reference and there is no
provision for a user-defined function to return a reference.":
  http://bclary.com/2004/11/07/#a-8.7
and an implementation that doesn't hold with such nonsense is also
allowed to reject "foo(a)++" as a syntax error:
  http://bclary.com/2004/11/07/#a-16

-j
_______________________________________________
Es4-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es4-discuss
Reply | Threaded
Open this post in threaded view
|

Re: A random collection of ES4 draft spec surprises and thoughts

Brendan Eich-2
In reply to this post by Mark S. Miller-2
On May 26, 2008, at 11:06 AM, Mark S. Miller wrote:

Doing so breaks the subset
relationship between JSON and EcmaScript. (Granted, we also need to
acknowledge that this relationship is currently broken by Firefox.

Not Firefox -- both Mozilla JS implementations (SpiderMonkey and Rhino) support __proto__ (readably -- let's ignore the writable case).

ActionScript also had read-only __proto__ in at least one of its versions. I'm not sure if it still does in AS3.


But
part of the purpose of standards is to encourage browser vendors to
repair their implementations.)

If it ain't broke, don't fix it.

If I recall correctly (and I'm sure someone will set me straight otherwise), JSON is not compatible with ES3 -- Unicode non-BMP character handling differs. Trying to force a subset relation from JSON to ES4 is not going to fly if JSON is not a subset of ES3. What matters is the intersection being "big enough", and hard cases like __proto__ or other mangled names do not much matter.


* What's ">=="? I've never seen that before.

A typo?


* What does the "var" attribute mean inside an object literal?

Same as elsewhere: it makes a fixture.


* Now that we have let-at-the-new-var, i.e., a properly lexically
scoped letrec behavior, do we still need the "let" expression and the
"let" comprehension? Can we kill these?

(I'm not sure what you mean by "let" comprehension, but :) No, they have different use-cases that deserve attention.


* Why does the grammar allow function calls in
LeftHandSideExpressions. For example, what's the meaning of

    foo(a)++

?

Notice how ES1-3 grammars also produced such sentences. We do not use a bottom-up grammar to make such sentences not parse, and neither do real implementations.

Indeed, IE JScript (for VBScript compatibility) long ago added support for "Reference" type return values from certain native ("host object") methods. This enabled domNode.item(i) = j, e.g. SpiderMonkey added support because someone embedding its open source wanted to support code written for JScript.

Thus the ES1-4 grammars can produce these expressions, but they are ruled out semantically for some or all kinds of objects. See ES3 11.3.1 and 11.13.1, then 8.7.1 step 1; also 16 fourth bulleted item.


* Why does delete operate on a PostFixExpression rather than a
LeftHandSideExpression? What's the meaning of

    delete x++;

?

This looks like a bug to me: ES3 has the production

UnaryExpression : delete UnaryExpression

But in any case, LeftHandSideExpression is not compatible. Jeff should weigh in here.


* I thought "like" was dead. How did it get revived?

We removed "like" from the type system. It's still a binary operator, and there is sugar for enforcing like relations on arguments and return values.


* What is

   "super" "(" Arguments ")"

? Last I heard, ES4 only has single implementation inheritance, so why
allow "super" to be qualified?

Not sure what you mean by "qualified", but super can be *called*.


           Core Semantics

* I'm pleasantly surprised to see that the prototype reference (which
I take to be the same as the ES3 internal [[Prototype]] property) is
said to be immutable. Does this mean that we will be able to consider
the following behavior buggy (I hope so):

    var x = {};

    var y = {};

    x.__proto__ = y;
    [object Object]

    y.foo = 3;
    3

    x.foo
    3

If the property is read-only then of course assignment to a property of y can't affect x. Under 'use strict', the attempt to set the read-only __proto__ property throws.


* What namespace is "__ES4__" defined in?

The public (compatibility) one -- hence the ugly __ bracketing, to minimize chance of collision.

I left a few questions for others to answer ("rib" is defined in at least one place in the draft specs I reviewed).

/be

_______________________________________________
Es4-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es4-discuss
Reply | Threaded
Open this post in threaded view
|

Re: A random collection of ES4 draft spec surprises and thoughts

Brendan Eich-2
In reply to this post by Graydon Hoare-3
On May 26, 2008, at 11:57 AM, Graydon Hoare wrote:


* I thought "like" was dead. How did it get revived?

As a (value * type) binary operator, rather than as a type. It also 
(presently) has a form in which it can annotate a function parameter, 
which implicitly causes the an assertion of the operator against the 
provided type when the function is entered. This annotation behavior on 
function parameter lists is something I'm not terribly pleased with, but 
then, the most natural boundary between annotated and unannotated code 
appears to be that of a function call, so it's possibly sensible to 
leave extra conveniences there.

It's particularly helpful on return types to avoid forcing control to flow through a single exit block, in which to write a like expression in an if whose consequent throws a new TypeError (I got tired just writing that ;-).

But it helps also on arguments:

function f(a like T, b like U, c like V) {
  ...
}

instead of

function f(a, b, c) {
  if (!(a like T)) throw new TypeError;
  if (!(b like U)) throw new TypeError;
  if (!(c like V)) throw new TypeError;
  ...
}

/be

_______________________________________________
Es4-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es4-discuss
Reply | Threaded
Open this post in threaded view
|

Re: A random collection of ES4 draft spec surprises and thoughts

Jeff Dyer
In reply to this post by Mark S. Miller-2

On 5/26/08 11:06 AM, Mark S. Miller wrote:

> * What's "__proto__" doing in the grammar? If we want to provide
> access to the internal [[Prototype]] property (as I think we do), we
> should do that explicitly with a reflective operation such as
> Object.prototypeOf(obj). But please let's avoid turning this internal
> property into a named property. Doing so breaks the subset
> relationship between JSON and EcmaScript. (Granted, we also need to
> acknowledge that this relationship is currently broken by Firefox. But
> part of the purpose of standards is to encourage browser vendors to
> repair their implementations.)

You'll notice that it is used as a keyword in object literals to allow
setting up the [[Prototype]] of an object, and as an attribute to mean what
'prototype' used to mean. We felt 'prototype' was already used too broadly
to reserve for this specific purpose.

>
> * What's ">=="? I've never seen that before.

Residue of an erased construct.

>
> * What does the "var" attribute mean inside an object literal?
>
> * Now that we have let-at-the-new-var, i.e., a properly lexically
> scoped letrec behavior, do we still need the "let" expression and the
> "let" comprehension? Can we kill these?
>
> * Why does the grammar allow function calls in
> LeftHandSideExpressions. For example, what's the meaning of
>
>     foo(a)++
>
> ?
>
> * Why does delete operate on a PostFixExpression rather than a
> LeftHandSideExpression? What's the meaning of
>
>     delete x++;
>
> ?

Its a bug, but not the one you are reporting. For compatibility with ES3 the
operand of the 'delete' operator must be a /UnaryExpression/. This allows
non-sense expressions like 'delete void 0'. The result, in case you are
wondering, is /true/.

Jd

_______________________________________________
Es4-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es4-discuss
Reply | Threaded
Open this post in threaded view
|

Re: A random collection of ES4 draft spec surprises and thoughts

Jeff Dyer
In reply to this post by Brendan Eich-2

On 5/26/08 12:01 PM, Brendan Eich wrote:

> On May 26, 2008, at 11:06 AM, Mark S. Miller wrote:
>
>> Doing so breaks the subset
>> relationship between JSON and EcmaScript. (Granted, we also need to
>> acknowledge that this relationship is currently broken by Firefox.
>
> Not Firefox -- both Mozilla JS implementations (SpiderMonkey and
> Rhino) support __proto__ (readably -- let's ignore the writable case).
>
> ActionScript also had read-only __proto__ in at least one of its
> versions. I'm not sure if it still does in AS3.

__proto__ is not supported in AS3, to my knowledge. Any anyways, if there is
controversy here it should be that __proto__ is being reserved in ES4 and is
not as generally usable as in ES3 and ancestors. Not, that it has special
meaning at certain points in the grammar.

Jd

_______________________________________________
Es4-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es4-discuss
Reply | Threaded
Open this post in threaded view
|

Re: A random collection of ES4 draft spec surprises and thoughts

Brendan Eich-2
On May 26, 2008, at 2:16 PM, Jeff Dyer wrote:

> On 5/26/08 12:01 PM, Brendan Eich wrote:
>
>> ActionScript also had read-only __proto__ in at least one of its
>> versions. I'm not sure if it still does in AS3.
>
> __proto__ is not supported in AS3, to my knowledge.

I was thinking of

http://livedocs.adobe.com/flash/8/main/wwhelp/wwhimpl/common/html/ 
wwhelp.htm?context=LiveDocs_Parts&file=00002585.html

So, ActionScript 2 -- right?


> Any anyways, if there is
> controversy here it should be that __proto__ is being reserved in  
> ES4 and is
> not as generally usable as in ES3 and ancestors.

(No __proto__ in ES3, of course.)


> Not, that it has special
> meaning at certain points in the grammar.

Mark's point about JSON, Doug has raised it too, is that magic  
property names in an ES standard, if not in a few implementations of  
ES3, pre-empt those names from being used as JSON property names.  
Even if the identifier __proto__ were not in the grammar -- if it  
were only the name of a magic Object.prototype getter -- it would  
break the JSON < ES4 relation. But I think that relation is already  
broken, since (AFAIK) JSON is not a subset of ES3.

/be



_______________________________________________
Es4-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es4-discuss
Reply | Threaded
Open this post in threaded view
|

Re: A random collection of ES4 draft spec surprises and thoughts

Jeff Dyer



On 5/26/08 2:55 PM, Brendan Eich wrote:

> On May 26, 2008, at 2:16 PM, Jeff Dyer wrote:
>
>> On 5/26/08 12:01 PM, Brendan Eich wrote:
>>
>>> ActionScript also had read-only __proto__ in at least one of its
>>> versions. I'm not sure if it still does in AS3.
>>
>> __proto__ is not supported in AS3, to my knowledge.
>
> I was thinking of
>
> http://livedocs.adobe.com/flash/8/main/wwhelp/wwhimpl/common/html/
> wwhelp.htm?context=LiveDocs_Parts&file=00002585.html
>
> So, ActionScript 2 -- right?

Yes, that's AS2 only.

>> Any anyways, if there is
>> controversy here it should be that __proto__ is being reserved in
>> ES4 and is
>> not as generally usable as in ES3 and ancestors.
>
> (No __proto__ in ES3, of course.)

Right, which means it can be used as an ordinary identifier.

>
>
>> Not, that it has special
>> meaning at certain points in the grammar.
>
> Mark's point about JSON, Doug has raised it too, is that magic
> property names in an ES standard, if not in a few implementations of
> ES3, pre-empt those names from being used as JSON property names.
> Even if the identifier __proto__ were not in the grammar -- if it
> were only the name of a magic Object.prototype getter -- it would
> break the JSON < ES4 relation. But I think that relation is already
> broken, since (AFAIK) JSON is not a subset of ES3.

Understood. And just to beat this horse to make sure it's really dead,
'__proto__'s appearance in the grammar doesn't make it a special property
name -- it just limits where in the language that special property can be
referenced.

Jd

_______________________________________________
Es4-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es4-discuss
Reply | Threaded
Open this post in threaded view
|

Re: A random collection of ES4 draft spec surprises and thoughts

Mark S. Miller-2
In reply to this post by Brendan Eich-2
On Mon, May 26, 2008 at 12:01 PM, Brendan Eich <[hidden email]> wrote:
> If I recall correctly (and I'm sure someone will set me straight otherwise),
> JSON is not compatible with ES3 -- Unicode non-BMP character handling
> differs. Trying to force a subset relation from JSON to ES4 is not going to
> fly if JSON is not a subset of ES3.

That's the first I've heard of that problem. AFAIK, JSON, ES3, ES3.1,
and ES4 all accept \u surrogate pairs representing a UTF-16 encoding
of non-BMP characters. Can anyone say more about what the remaining
problem is here?

The only breakage in the subset relationship that I'm aware of are

* the ES3 stripping of Cf characters, which everyone agrees needs to
be fixed in ES3.1 and ES4,

* and the treatment of \u2028 and \u2029 are newline characters rather
than merely whitespace characters. We're fixing this in ES3.1 and
proposing that ES4 fix this as well.

Are there other problems?


--
    Cheers,
    --MarkM
_______________________________________________
Es4-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es4-discuss
Reply | Threaded
Open this post in threaded view
|

Re: A random collection of ES4 draft spec surprises and thoughts

Mark S. Miller-2
In reply to this post by Jeff Dyer
On Mon, May 26, 2008 at 4:57 PM, Jeff Dyer <[hidden email]> wrote:
>> But I think that relation is already
>> broken, since (AFAIK) JSON is not a subset of ES3.
>
> Understood. And just to beat this horse to make sure it's really dead,

Last I saw that horse, it merely had a minor injury that was healing rapidly ;).


--
    Cheers,
    --MarkM
_______________________________________________
Es4-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es4-discuss
Reply | Threaded
Open this post in threaded view
|

Re: A random collection of ES4 draft spec surprises and thoughts

Maciej Stachowiak
In reply to this post by Jason Orendorff

On May 26, 2008, at 11:58 AM, Jason Orendorff wrote:

> I can answer two more :)
>
> On Mon, May 26, 2008 at 1:06 PM, Mark S. Miller <[hidden email]>  
> wrote:
>> * What does the "var" attribute mean inside an object literal?
>
> See Lars's "ES4 stable draft: Object initializers":
>  https://mail.mozilla.org/pipermail/es4-discuss/2008-April/002668.html
>
>> * Why does the grammar allow function calls in
>> LeftHandSideExpressions. For example, what's the meaning of
>>
>>   foo(a)++
>>
>> ?
>
> As far as I know, this is unchanged from ES3, in which "functions are
> permitted to return References" but "This possibility is admitted
> purely for the sake of host objects. No built-in ECMAScript function
> defined by this specification returns a reference and there is no
> provision for a user-defined function to return a reference.":
>  http://bclary.com/2004/11/07/#a-8.7
> and an implementation that doesn't hold with such nonsense is also
> allowed to reject "foo(a)++" as a syntax error:
>  http://bclary.com/2004/11/07/#a-16

In practice, for Web compatibility, it has to be a runtime error not a  
parse error. I don't know of any implementation making use of a  
function returning a reference however (in WebKit's implementation  
Reference is not a real type, just a spec fiction, and I assume this  
is true in other implementations).

  - Maciej

_______________________________________________
Es4-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es4-discuss
Reply | Threaded
Open this post in threaded view
|

Re: A random collection of ES4 draft spec surprises and thoughts

Brendan Eich-2
On May 26, 2008, at 11:40 PM, Maciej Stachowiak wrote:

> On May 26, 2008, at 11:58 AM, Jason Orendorff wrote:
>
>> As far as I know, this is unchanged from ES3, in which "functions are
>> permitted to return References" but "This possibility is admitted
>> purely for the sake of host objects. No built-in ECMAScript function
>> defined by this specification returns a reference and there is no
>> provision for a user-defined function to return a reference.":
>>  http://bclary.com/2004/11/07/#a-8.7
>> and an implementation that doesn't hold with such nonsense is also
>> allowed to reject "foo(a)++" as a syntax error:
>>  http://bclary.com/2004/11/07/#a-16
>
> In practice, for Web compatibility, it has to be a runtime error not a
> parse error.

Could you provide a list of URLs? We added support for "lvalue  
return" to SpiderMonkey years ago, based on someone using the code  
and wanting to port VBScript-infected JScript. I don't recall the  
name (it wasn't AOL :-P), but there may be a post from me in reply on  
the old "jseng" Mozilla USENET group.


> I don't know of any implementation making use of a
> function returning a reference however (in WebKit's implementation
> Reference is not a real type, just a spec fiction, and I assume this
> is true in other implementations).

SpiderMonkey erases References except where a native function calls a  
special API to return one.

/be

_______________________________________________
Es4-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es4-discuss
Reply | Threaded
Open this post in threaded view
|

Re: A random collection of ES4 draft spec surprises and thoughts

Brendan Eich-2
In reply to this post by Mark S. Miller-2
On May 26, 2008, at 5:57 PM, Mark S. Miller wrote:

On Mon, May 26, 2008 at 12:01 PM, Brendan Eich <[hidden email]> wrote:
If I recall correctly (and I'm sure someone will set me straight otherwise),
JSON is not compatible with ES3 -- Unicode non-BMP character handling
differs. Trying to force a subset relation from JSON to ES4 is not going to
fly if JSON is not a subset of ES3.

That's the first I've heard of that problem. AFAIK, JSON, ES3, ES3.1,
and ES4 all accept \u surrogate pairs representing a UTF-16 encoding
of non-BMP characters. Can anyone say more about what the remaining
problem is here?

Sorry, I was misremembering the problem discussed at


which would make JSON not a subset of ES4.


The only breakage in the subset relationship that I'm aware of are

* the ES3 stripping of Cf characters, which everyone agrees needs to
be fixed in ES3.1 and ES4,

Even Microsoft? [1]

* and the treatment of \u2028 and \u2029 are newline characters rather
than merely whitespace characters. We're fixing this in ES3.1 and
proposing that ES4 fix this as well.


That's all fine, or to be debated [2]. But the fact remains: JSON is not a subset of ES3 for these reasons. Let's not bend "subset" via future tense.

Are there other problems?

These two are enough.

Why is it important that JSON is a subset of ES-future-anything?

/be


_______________________________________________
Es4-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es4-discuss
Reply | Threaded
Open this post in threaded view
|

Re: A random collection of ES4 draft spec surprises and thoughts

Maciej Stachowiak
In reply to this post by Brendan Eich-2

On May 26, 2008, at 11:48 PM, Brendan Eich wrote:

> On May 26, 2008, at 11:40 PM, Maciej Stachowiak wrote:
>
>> On May 26, 2008, at 11:58 AM, Jason Orendorff wrote:
>>
>>> As far as I know, this is unchanged from ES3, in which "functions  
>>> are
>>> permitted to return References" but "This possibility is admitted
>>> purely for the sake of host objects. No built-in ECMAScript function
>>> defined by this specification returns a reference and there is no
>>> provision for a user-defined function to return a reference.":
>>> http://bclary.com/2004/11/07/#a-8.7
>>> and an implementation that doesn't hold with such nonsense is also
>>> allowed to reject "foo(a)++" as a syntax error:
>>> http://bclary.com/2004/11/07/#a-16
>>
>> In practice, for Web compatibility, it has to be a runtime error  
>> not a
>> parse error.
>
> Could you provide a list of URLs?

I don't mean that actually supporting Reference return is  
incompatible. Just that treating foo(a)++ as a syntax error is  
incompatible. In JavaScriptCore we detect at parse time when the  
operand of a ++ or -- is not syntactically an lvalue and emit code to  
throw an exception at runtime, because apparently some scripts on the  
Web include functions with such constructs that they never call, so  
treating it as a syntax error and aborting parsing would break the  
page, but throwing at runtime does not.

We tried to treat this a syntax error and at the time it broke  
300themovie.warnerbros.com and fedex.com. There were probably more  
than these two, we did not do an exhaustive search. Since Mozilla and  
IE both support this syntax I imagine this is no surprise.

> We added support for "lvalue return" to SpiderMonkey years ago,  
> based on someone using the code and wanting to port VBScript-
> infected JScript. I don't recall the name (it wasn't AOL :-P), but  
> there may be a post from me in reply on the old "jseng" Mozilla  
> USENET group.
>
>
>> I don't know of any implementation making use of a
>> function returning a reference however (in WebKit's implementation
>> Reference is not a real type, just a spec fiction, and I assume this
>> is true in other implementations).
>
> SpiderMonkey erases References except where a native function calls  
> a special API to return one.

I did not know that. Probably not something we are keen to add.

  - Maciej

_______________________________________________
Es4-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es4-discuss
Reply | Threaded
Open this post in threaded view
|

RE: A random collection of ES4 draft spec surprises and thoughts

Lars Hansen-3
In reply to this post by Mark S. Miller-2
> -----Original Message-----
> From: [hidden email]
> [mailto:[hidden email]] On Behalf Of Mark S. Miller
> Sent: 26. mai 2008 11:07
> To: [hidden email]; [hidden email] x-discuss
> Subject: A random collection of ES4 draft spec surprises and thoughts
>
> In going over the ES4 draft spec docs, I found the following
> things surprising:

Other people took care of everything except this one:

> * Is "A catch-all method operates on the object that contains
> the method." a mistake? Did you mean "operates on the invoked object"?

My phrasing is clumsy, but in my universe we invoke functions and
methods, not objects, and I was trying to convey that sense of
reality.  The sentence does not end with a period but with a second
clause: ", not on that object's prototype object." and that's the
main point: the method only operates on the specific receiver object,
not on the receiver's prototypes.  But you're right to point out
that it could be improved.  Thanks.

--lars
_______________________________________________
Es4-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es4-discuss