Thq Quiz

[Dmitry A. Soshnikov]

If some will be interested, one more ES quiz: <URL:
http://javascript.ru/blog/Dmitry-A.-Soshnikov/The-quiz>

For regulars of this group it shouldn't be hard.

/ds

 

[Garrett Smith]

If some will be interested, one more ES quiz: <URL:
http://javascript.ru/blog/Dmitry-A.-Soshnikov/The-quiz>

For regulars of this group it shouldn't be hard.

#5 is a good one for understanding Grouping Operator and Reference.

#6 is better. Seems Chrome gets that feature wrong.

function testArgOutsideLength(a){
a = 1;
alert([arguments.length, arguments[0]]);
}

javascript: function testArgOutsideLength(a){ var inBefore = "0" in
arguments; a = 1; alert([inBefore, "0" in arguments]);}
testArgOutsideLength()

Where chrome elerts:
"0, 1"

A more interesting variation, my "response question":
alert(
function(x, y) {
x = 10;
y = 20;
return[
""+x,
""+arguments[0],
""+y,
""+arguments[1]
];
}(1));

The answer to my "response question" is below.

There seem to be some changes in ES5 but I have not read up on those.
The arguments object, as specified, more complex than need be.

A fixed Spidermonkey bug: <URL:
https://bugzilla.mozilla.org/show_bug.cgi?id=292215 > (fixed) where
assigning to arguments[n] where `n` was >= function.length or >= the
number of actual arguments.

In Safari 2, IIRC, (and probably Konqueror), there is also a bug where
passed args are not synced with the arguments object, so assigning to
the arg does not update the arguments object.

A similar bug exists in FF and IE where the args and the arguments
object syncing does not persist after the function returns:
<URL: http://bugs.ecmascript.org/ticket/447 >

Answer to my "response question" is explained by Ecma-262, r3 s 10.1.8
"Arguments Object":

| A property is created with name length and property attributes {
| DontEnum }. The initial value of this property is the number of actual
| parameter values supplied by the caller.
|

alert(
function(x, y) {
// arguments.length = 1.
}(1));

| For each non-negative integer, arg, less than the value of the length
| property, a property is created with name ToString(arg) and property
| attributes { DontEnum }.

alert(
function(x, y) {
// arguments.length = 1.
// arguments["0"] {DontEnum}
x = 10;
y = 20;
}(1));

| The initial value of this property is the
| value of the corresponding actual parameter supplied by the caller.

Updating the code comments to reflect that:

alert(
function(x, y) {
// arguments.length = 2.
// arguments["0"] = 1 {DontEnum}
x = 10;
y = 20;
}(1));

| The first actual parameter value corresponds to arg = 0, the second to
| arg = 1, and so on. In the case when arg is less than the number of
| formal parameters for the Function object, this property shares its
| value with the corresponding property of the activation object. This
| means that changing this property changes the corresponding property
| of the activation object and vice versa.

At this point, `y` would share its value with arguments[1], but
arguments does not have "1" property. Since no "1" property exists on
the arguments object, the property `y` has nothing to share its value
with. To handle this situation, Chrome *creates* a property of the
arguments object to share value with.

The result is arguments gets a "1" property and arguments.length is 1.

 

[Garrett Smith]

On 2/20/10 4:09 AM, Garrett Smith wrote:
[...]

alert(
function(x, y) {
// arguments.length = 1.

Right.

}(1));

| For each non-negative integer, arg, less than the value of the length
| property, a property is created with name ToString(arg) and property
| attributes { DontEnum }.

alert(
function(x, y) {
// arguments.length = 1.

Still right.

// arguments["0"] {DontEnum}
x = 10;
y = 20;
}(1));

| The initial value of this property is the
| value of the corresponding actual parameter supplied by the caller.

Updating the code comments to reflect that:

alert(
function(x, y) {
// arguments.length = 2.

^^^

What happened to `1`?

I don't see why arguments.length should change from 1 to 2 here. Typo?

`1` is correct because there was one actual argument passed in that
example.

It's not like copy'n'paste is all that hard. Apparently I copied right
the first time, but not the second. I should take my own advice about
late-night messages. Plus I need more sleep anyway.

[...]

I did file a bug on it, too, using another example.
http://code.google.com/p/chromium/issues/detail?id=36350

These kind of things should really be caught by a conformance test suite
like Sputniktests [1]. The fact that they're not (I'm not sure, haven't
checked) shows that test suite has gaps and still needs work.

I think that bug reflects the problems with too much complexity around
`arguments` feature. Even in a very recent build of a major
implementation has an issue. The other issues I listed support my
argument that the complexity around `arguments` causes implementation
problems.

In an es-discuss thread about fixing `arguments` Brendan made a remark
about it being something like "polishing a turd," which I thought both
funny and appropriate.

 

[Dmitry A. Soshnikov]

#6 is better. Seems Chrome gets that feature wrong.

Yeah, that's right, Chrome still cannot get it right. Regarding to
ECMA-262-3, 10.1.8:

|A property is created with name length and property attributes
{ DontEnum }.
|The initial value of this property is the number of *actual parameter
values supplied by the caller*.

function foo(x) {
x = 42;
console.log(arguments.length); // 0
console.log(arguments[0]); // undefined
return arguments[0];
}

// number of actual
// parameter values is 0
f(); // undefined

/ds

 

[Garrett Smith]

Probably got deleted as a dup.
[..]

It could be argued that this is not a bug. The spec's conformance
section explicitly allows objects to have properties in addition to
those specified.

[...]

http://javascript.ru/blog/Dmitry-A.-Soshnikov/The-quiz#q6

If this is not a bug, then all of question 6's options must be
acceptable as correct answers.

function f(x, y) {
x = 10;
console.log(
arguments[0],
arguments[1]
);
}

f();

(a) 10, null
(b) 10, undefined
(c) undefined, undefined
(d) 10, NaN
(e) 10, 10

It seems odd for a program to expect the `arguments` object not to have
a "0" property at that point. The oddness of the situation may be a good
reason the chrome bug (AISI) went on unnoticed for so long.

 

[Dmitry A. Soshnikov]

On Feb 23, 1:19 am, "Richard Cornford" <[email protected]>
wrote:

[...]

It could be argued that this is not a bug. The spec's conformance
section explicitly allows objects to have properties in addition to
those specified. There would be a problem if the - arguments.length -
changed when - arguments[0] - was added to the object, but as that does
not happed the result is an arguments object with all the specified
properties having all the specified values and behaviour, and no more
than the additional properties that ES3 allows.

Many things in ES3 could be debatable as many things (no less than
spec itself) are ambiguous, but that was recognized (by many
implementations) as a bug as spec says exactly (ES3, 10.1.8):

| ... is the number of *actual parameter
| values supplied by the caller*

Whether it's debatable and ambiguous - that's already another
question.

/ds

 

[Dmitry A. Soshnikov]

[...]

If this is not a bug ...

It's a bug. The question and the meaning are very ambiguous (from the
human viewpoint), but regarding to spec (which is itself ambiguous in
many moments) - it's a bug.

It seems odd for a program to expect the `arguments` object not to have
a "0" property at that point.

Yes, it could be so. But from the other side: current spec's behavior
is a consequence of that quantity of formal parameters - is
<constructor>.length, and the quantity of the _actual_ parameters - is
`arguments.length'. For what reason there should be 1 or 2, but not
(correctly) 0? And if they would made that local variable from the
activation object would share its name also in this case (when there's
no any parameter passed) - it's also be ambiguous - e.g. for check
where user *really* passed something to function (could be useful with
overloading by parameters length).

So abstractly this case turns out like function has no parameters at
all, and `x' - is just a local variable:

function foo(x, y) { x = 10 }

foo(20, 30) => foo(x, y) { x = 10 }
foo(40) => foo(x) { x = 10 }
foo(50) => foo() { [var ]x = 10 }

The oddness of the situation may be a good
reason the chrome bug (AISI) went on unnoticed for so long.

Maybe. They can write a suggestion to change the behavior (but not
arguing that spec allows any other additional properties - as in this
cases - all the spec can be doubtful, but providing alternative
unequivocal meaning, taking into account all the existing features).
But also can be that they just forgot to fix it according to ES3
10.1.8.

/ds

 

[Dmitry A. Soshnikov]

Garrett Smith wrote:
[...]

If this is not a bug, then all of question 6's options
must be acceptable as correct answers.

And a lot of other possible answers as well.

Do you mean answers on other questions? For example? If you provide
really ambiguous cases (except question #2 which is already
discussed), I'll update the post.

ECMA 262 3rd Ed. says
that - arguments.length - should be zero, but does not make any
assertions about the values of integer index named properties where the
integer values are greater or equal to - arguments.length -.

But it says about the case when it *less* than quantity of actual
arguments.

function f(x, y) {
  x = 10;
  console.log(
    arguments[0],
    arguments[1]
  );
}

f();

(a) 10, null
(b) 10, undefined
(c) undefined, undefined
(d) 10, NaN
(e) 10, 10

It seems odd for a program to expect the `arguments` object
not to have a "0" property at that point.

The interpretation of the spec that says an arguments object may have
integer indexed properties beyond - arguments.length - has implications
for some styles of method overloading emulation, as you would have to
verify argumetns.length before making deductions from a value in -
arguments[n] -.

Yeah, I think this is one of the main reasons (possibility of checking
_real_ arguments.length) of this strange behavior. And even if there's
`x = 10' - still to have ability to check _real_ `arguments.length'
which should be 0 and as a consequence, `arguments[0]' shouldn't
appear. Although, yeah, the behavior is ambiguous.

If it is a bug at all.

Yeah, by the 10.1.8 it shouldn't be, but as for ambiguous behavior -
it could be changed and recognized as a bug (but with providing a good
alternative for behavior).

/ds

 

[Richard Cornford]

On Feb 23, 1:19 am, Richard Cornford wrote:
[...]

It could be argued that this is not a bug. The spec's conformance
section explicitly allows objects to have properties in addition to
those specified. There would be a problem if the - arguments.length
- changed when - arguments[0] - was added to the object, but as
that does not happed the result is an arguments object with all
the specified properties having all the specified values and
behaviour, and no more than the additional properties that ES3
allows.

Many things in ES3 could be debatable as many things (no less than
spec itself) are ambiguous, but that was recognized (by many
implementations) as a bug as spec says exactly (ES3, 10.1.8):

| ... is the number of *actual parameter
| values supplied by the caller*

That is the specification for the - length - property of the
- arguments - object, but do we have any evidence of an environment
where the - length - property is incorrect? My quick tests of Chrome
show the addition of an - arguments[n] - when assigning to a
corresponding formal parameter for which no actual argument was
passed, but that the - arguments.length - value is not altered by
this action (and so does not become incorrect).

The - length - property is not specified as relating to the number of
'integer index' properties of the - arguments - object, and the only
'integer index' properties specified are those where the integer would
be less than - length -.

Whether it's debatable and ambiguous - that's already another
question.

ECMA 262 3rd Ed. specifies the argument object's [[Prototype]], its
callee, its length and "non-negative integer" properties "less than
the value of the length property". This "bug" does not present any
evidence of any of these specified properties having incorrect values
or behaviours.

The conformance section (1) starts out stating that: "A conforming
implementation of ECMAScript must provide and support all the types,
values, objects, properties,
functions, and program syntax and semantics described in this
specification.", but for an arguments object all of the properties,
syntax and semantics appear to be correct where Chrome is concerned.

The conformance section also says: "A conforming implementation of
ECMAScript is permitted to provide additional types, values, objects,
properties, and functions beyond those described in this
specification.", and what we have is evidence of properties of an
arguments "beyond" (literally in this case) to those specified.

You can argue that the situation as it manifests itself in Chrome is a
bad idea, and observe that others have made different (even better)
decisions, but I cannot see how this violates the specification in any
way. Therefore it is not an implementation bug.

Richard.

 

[Dmitry A. Soshnikov]

On Feb 23, 1:19 am, Richard Cornford wrote:
[...]

It could be argued that this is not a bug. The spec's conformance
section explicitly allows objects to have properties in addition to
those specified. There would be a problem if the - arguments.length
- changed when - arguments[0] - was added to the object, but as
that does not happed the result is an arguments object with all
the specified properties having all the specified values and
behaviour, and no more than the additional properties that ES3
allows.

Many things in ES3 could be debatable as many things (no less than
spec itself) are ambiguous, but that was recognized (by many
implementations) as a bug as spec says exactly (ES3, 10.1.8):

| ... is the number of *actual parameter
| values supplied by the caller*

That is the specification for the - length - property of the
- arguments - object

Not only, the spec says about the concrete and exact case *when
arguments properties share their values with corresponding variables
of the activation object*. And this case is related to
`arguments.length'. Sure, arguments can be augment with new properties
on runtime context phase (which executes after entering the context
phase at which `arguments' (and all the other stuff) is created).

but do we have any evidence of an environment
where the - length - property is incorrect?

No, with `arguments.length' everything's OK - in all implementations -
it shouldn't be changed as `arguments' is not an array, thus has no
overloaded [[Put]] for that. So it should be always 0 in this case.

My quick tests of Chrome
show the addition of an - arguments[n] - when assigning to a
corresponding formal parameter for which no actual argument was
passed, but that the - arguments.length - value is not altered by
this action (and so does not become incorrect).

With `.length' that's OK, as mentioned above, but Chrome makes error
with *fact of sharing* the value of local variable, and the case when
this fact should be true is described in 10.1.8 and depends on actual
`arguments.length' analyzed on entering the context. The conformant
implementation (as I see it) is:

function foo(x) {
x = 10;
alert(arguments[0]); // should undefined
arguments[0] = 100;
alert([
arguments[0], // should be 100
x, // should be 10, as doesn't share
arguments.length // should be 0, as [[Get]] isn't overloaded
]);
}

foo();

And only in Chrome we have "100, 100, 100, 0", meanwhile in other:
"undefined, 100, 10, 0".

The - length - property is not specified as relating to the number of
'integer index' properties of the - arguments - object, and the only
'integer index' properties specified are those where the integer would
be less than - length -.

The main goal of the last bullet of 10.1.8 even is not in
`length' (although, in `length' also), but in specifying *exact
behavior and the case* when implementation should share `arguments'
index-properties values and local variables of the activation object.

You can argue that the situation as it manifests itself in Chrome is a
bad idea, and observe that others have made different (even better)
decisions

Yeah, some (all?) other implementations recognize it as bug. For
example, I found in code of SpiderMonkey comment related to bug
mentioned above by Garrett where implementors also agree that the
behavior of 10.1.8 should be treated so:

but I cannot see how this violates the specification in any
way. Therefore it is not an implementation bug.

As I mentioned, it's in the last bullet of the 10.1.8, where the exact
case when `arguments' and local variables should be shared is
described.

/ds

 

[Richard Cornford]

On Feb 23, 1:19 am, Richard Cornford wrote:
[...]
It could be argued that this is not a bug. The spec's conformance
section explicitly allows objects to have properties in addition
to those specified. There would be a problem if the -
arguments.length - changed when - arguments[0] - was added to
the object, but as that does not happed the result is an
arguments object with all the specified properties having all
the specified values and behaviour, and no more than the
additional properties that ES3 allows.
Many things in ES3 could be debatable as many things (no less
than spec itself) are ambiguous, but that was recognized (by
many implementations) as a bug as spec says exactly (ES3,
10.1.8):
| ... is the number of *actual parameter
| values supplied by the caller*

That is the specification for the - length - property of the
- arguments - object

Not only,

So which other value represents "the number of *actual parameter
values supplied by" the caller*"?

the spec says about the concrete and exact case *when
arguments properties share their values with corresponding
variables of the activation object*.

Only "In the cases when arg is less then the number of formal
parameters for the function" and after constraining arg to all "non-
negative integers" "less then the value of the length property".

And this case is related to `arguments.length'. Sure, arguments
can be augment with new properties on runtime context phase
(which executes after entering the context phase at which
`arguments' (and all the other stuff) is created).

I don't understand that last sentence.

but do we have any evidence of an environment
where the - length - property is incorrect?

No, with `arguments.length' everything's OK - in all
implementations - it shouldn't be changed as `arguments' is
not an array, thus has no overloaded [[Put]] for that. So
it should be always 0 in this case.

My quick tests of Chrome
show the addition of an - arguments[n] - when assigning to a
corresponding formal parameter for which no actual argument was
passed, but that the - arguments.length - value is not altered
by this action (and so does not become incorrect).

With `.length' that's OK, as mentioned above, but Chrome makes
error with *fact of sharing* the value of local variable, and
the case when this fact should be true is described in 10.1.8
and depends on actual `arguments.length' analyzed on entering
the context. The conformant implementation (as I see it) is:

function foo(x) {
x = 10;
alert(arguments[0]); // should undefined

Based on what? In this case - arguments.length - is zero, and so there
is no specified value or behaviour for an - arguments[0] - property in
this case.

arguments[0] = 100;
alert([
arguments[0], // should be 100

Yes it should, as the - arguments[0] - property has just been assigned
that value.

x, // should be 10, as doesn't share

That is much harder to justify. While successful assignment would not
normally be expected to have side effects on the values of the
properties of other objects I don't see anything that forbids this.

arguments.length // should be 0, as [[Get]] isn't overloaded
]);

}

foo();

And only in Chrome we have "100, 100, 100, 0", meanwhile in
other: "undefined, 100, 10, 0".

But as there is no 'correct' outcome to be derived from the
specification it is not possible to declare either to be wrong.
Interactions with 'integer index' properties of the - arguments -
object that are equal to or greater than - arguments.length - are not
specified at all.

The main goal of the last bullet of 10.1.8 even is not in
`length' (although, in `length' also), but in specifying
*exact behavior and the case* when implementation should
share `arguments' index-properties values and local
variables of the activation object.

Whatever the motivation of the section, the wording of the section
specifies exact behaviour for a length property and all non-negative
'integer index' properties that are less than the length value. It
says nothing about the existence (or non-existence), value or
behaviour of 'integer index' properties that are equal to or greater
than length; there are no constraints placed on such properties in
that section.

It would be possible to argue that whatever is not specified is
therefore forbidden, but that position would instantly collapse at the
third paragraph of the conformance section; you cannot forbid all that
is not specified at the same time as allowing "additional types,
objects, properties and functions beyond those described in this
specification".

Section 10.1.8 specifies the values and behaviour of non-negative
integer index properties of the - arguments - object that are less
than the - arguments.length - value, and it stops there. Beyond that
the language's conformance rules allow anything that does not
contradict what is specified.

Yeah, some (all?) other implementations recognize it as bug.

You cannot assume that. It is entirely possible that where it is
recognised at all the behaviour chosen was chosen because it was seen
as sensible.

For example, I found in code of SpiderMonkey comment related
to bug mentioned above by Garrett where implementors also
agree that the behavior of 10.1.8 should be treated so:

<URL:http://mxr.mozilla.org/mozilla/source/js/src/jsfun.c#210>

Is that an appeal to authority? Individuals, including those working
on script engine software, are capable of misinterpreting the
specification, reading more in that is there, or even just expressing
themselves imprecisely/poorly.

(just as I am, which is what makes having this discussion in public
worthwhile. Burred in the spec somewhere they may be something that
would make this Chrome feature an ECMAScript implementation bug. It is
not in section 10.1.8, but that does not mean that nobody here will be
able to point something out).

As I mentioned, it's in the last bullet of the 10.1.8, where
the exact case when `arguments' and local variables should be
shared is described.

If it is there, by all means cite the text that imposes constraints on
the existance, values or behaviour of 'integer index' properties of
the - arguments - object that are equal to or greater than -
arguments.length -. I don't see it.

Richard.

 

[Dmitry A. Soshnikov]

On Feb 24, 2:43 pm, Richard Cornford <[email protected]>
wrote:

[...]

So which other value represents "the number of *actual parameter
values supplied by" the caller*"?

Seems you didn't understand correctly, by "not only" I meant that
10.1.8 says not only the length property but also about the exact case
when properties of `arguments' object and and corresponding formal
parameters should be shared.

Only "In the cases when arg is less then the number of formal
parameters for the function" and after constraining arg to all "non-
negative integers" "less then the value of the length property".

Do I understand correctly that you argue about that if
arguments.length == 0, than implementation can share corresponding
formal *first* parameter as index-property of the `arguments[0]' is
*equal to* 0, but not less as told in spec? If so, sorry, this is just
a _too formal_ attempt to think out "how could it be if ...". And
doesn't it mean that for `arguments[1]' shouldn't share the
corresponding formal parameter (1 < 0, where 0 - is the
`arguments.length')? But it does. As it does (wrong) for
`arguments[0]'.

Your current arguing reminds some case in court when everybody
understands that it is wrong, but because of _some formal ambiguity_
(a "formal hole in the law") is will be justified. Sorry, no, it
won't.

I don't understand that last sentence.

Doesn't matter, I meant that it's possible to add new properties to
`arguments' object (but they shouldn't affect the `.length' property,
what I said in another sentence).

function foo(x) {
  x = 10;
  alert(arguments[0]); // should undefined

Based on what? In this case - arguments.length - is zero, and so there
is no specified value or behaviour for an - arguments[0] - property in
this case.

I said above - it's just an attempt to be hooked for ambiguity of the
specification. If Chrome is correct by your words, than it shouldn't
share `y' (let's assume it's the second parameter) and `arguments[1]'
in case when no parameters are passed. But Chrome shares them in all
that cases, which is wrong. Referencing to conformance section also
isn't fit here - because implementation can create any other
properties (as many as it want), but shouldn't disturb the description
of concrete algorithm (10.1.8 in this case; see for `arguments[1]'
then if you still want to argue about 0 == 0, but not less than).

  arguments[0] = 100;
  alert([
    arguments[0], // should be 100

Yes it should, as the - arguments[0] - property has just been assigned
that value.

    x, // should be 10, as doesn't share

That is much harder to justify. While successful assignment would not
normally be expected to have side effects on the values of the
properties of other objects I don't see anything that forbids this.

Yeah, that's true (any side effect could be, which specification
doesn't forbid), but this exact case is forbidden by 10.1.8 (again,
you can choose to analyze arguments[1], y, and the case when no
parameters passed to (x, y) function).

    arguments.length // should be 0, as [[Get]] isn't overloaded
  ]);

}

foo();

And only in Chrome we have "100, 100, 100, 0", meanwhile in
other: "undefined, 100, 10, 0".

But as there is no 'correct' outcome to be derived from the
specification it is not possible to declare either to be wrong.
Interactions with 'integer index' properties of the - arguments -
object that are equal to or greater than - arguments.length - are not
specified at all.

Mentioned above, it seems like formal catching the hole in ambiguous
specification description, but I can't find useful application of it.
Then use arguments[1] and y, when .length will be 0, and Chrome will
try to share 1 which is grater than 0. Do I understand correctly that
for you statements "1 is grater than 0" (with which you're trying to
argue) and "0 is less than 1" are not equivalent for this case?

Whatever the motivation of the section, the wording of the section
specifies exact behaviour for a length property and all non-negative
'integer index' properties that are less than the length value. It
says nothing about the existence (or non-existence), value or
behaviour of 'integer index' properties that are equal to or greater
than length; there are no constraints placed on such properties in
that section.

Yeah, I mentioned it above.

It would be possible to argue that whatever is not specified is
therefore forbidden, but that position would instantly collapse at the
third paragraph of the conformance section; you cannot forbid all that
is not specified at the same time as allowing "additional types,
objects, properties and functions beyond those described in this
specification".

Section 10.1.8 specifies the values and behaviour of non-negative
integer index properties of the - arguments - object that are less
than the - arguments.length - value, and it stops there. Beyond that
the language's conformance rules allow anything that does not
contradict what is specified.



You cannot assume that. It is entirely possible that where it is
recognised at all the behaviour chosen was chosen because it was seen
as sensible.

On implementation level this should be so. Some ambiguous cases should
be treated as logical as possible, but without finding "law holes" and
choosing this way to implement (and moreover, argue after than
referencing on it).

Is that an appeal to authority?

Strange to hear that. Never. Seems, you confuse me to someone. But if
you insist: this is just _an example_.

Individuals, including those working
on script engine software, are capable of misinterpreting the
specification, reading more in that is there, or even just expressing
themselves imprecisely/poorly.

(just as I am, which is what makes having this discussion in public
worthwhile. Burred in the spec somewhere they may be something that
would make this Chrome feature an ECMAScript implementation bug. It is
not in section 10.1.8, but that does not mean that nobody here will be
able to point something out).

Yes, it could be so, but I think this case is clear although is very
ambiguous and can be appellate with references which you mention. The
other question - what is the big deal of that too formal appellations
for the implementation level? I don't see a big. Although, I clearly
understand your position.

/ds

 

[Richard Cornford]

On Feb 24, 2:43 pm, Richard Cornford wrote:
[...]

So which other value represents "the number of *actual parameter
values supplied by" the caller*"?

Seems you didn't understand correctly, by "not only" I meant that
10.1.8 says not only the length property but also about the exact
case when properties of `arguments' object and and corresponding
formal parameters should be shared.

No, section 10.1.8 specifies a minimum set of properties of the -
arguments - object that will share values with formal parameters. It
does not constrain the values or behaviours of any - arguemnts -
object 'integer index' properties that are not in that set.

Only "In the cases when arg is less then the number of formal
parameters for the function" and after constraining arg to all
"non- negative integers" "less then the value of the length
property".

Do I understand correctly that you argue about that if
arguments.length == 0, than implementation can share corresponding
formal *first* parameter as index-property of the `arguments[0]'
is *equal to* 0, but not less as told in spec?

I am pointing out that there are boundaries to what is being specified
in 10.1.8, and that as the behaviour that is being subject to
criticism is outside of those boundaries section 10.1.8 does not apply
to it.

If so, sorry, this
is just a _too formal_ attempt to think out "how could it be if
...". And doesn't it mean that for `arguments[1]' shouldn't share
the corresponding formal parameter (1 < 0, where 0 - is the
`arguments.length')? But it does. As it does (wrong) for
`arguments[0]'.

I don't understand that sentence.

Your current arguing reminds some case in court when everybody
understands that it is wrong, but because of _some formal
ambiguity_ (a "formal hole in the law") is will be justified.
Sorry, no, it won't.

Yes, of course. But the accusation being made is taking the form of
accusing Chrome of violating ECMA 262 3rd Ed; that the behaviour
exhibited represents an ECMAScript implementation bug. This accusation
is false, as the behaviour exhibited is fully accommodated by the
specification.

Now if someone wanted to accuse Chrome of doing something that was
stupid, not a good idea, of no practical use or help to anyone, etc.
then that is all fine (and probably true), but let us not call it an
ECMAScript implementation bug unless it is an ECMAScript
implementation bug.

I don't understand that last sentence.

Doesn't matter, I meant that it's possible to add new properties
to `arguments' object (but they shouldn't affect the `.length'
property, what I said in another sentence).

function foo(x) {
x = 10;
alert(arguments[0]); // should undefined

Based on what? In this case - arguments.length - is zero, and
so there is no specified value or behaviour for an - arguments[0]
- property in this case.

I said above - it's just an attempt to be hooked for ambiguity
of the specification.

There is no ambiguity; the specification does not define anything
about an - arguments[0] - property in this case, but does allow for
properties and behaviour beyond what it does specify.

If Chrome is correct by your words,

My words aren't important; Chrome is 'correct' by specification (in
the sense that what it is doing is not incorrect by the
specification).

than it shouldn't share `y' (let's assume it's the second
parameter) and `arguments[1]' in case when no parameters
are passed.

Why? If the existence, value and behaviour of - arguments[0] - is
beyond what is specified then the same will apply to - arguments[1] -,
etc.

But Chrome shares them in all that cases, which is wrong.

But only wrong by opinion, not wrong according to the specification.

Referencing to conformance section also isn't fit here -
because implementation can create any other properties
(as many as it want), but shouldn't disturb the description
of concrete algorithm (10.1.8

The algorithm is bound by zero and - < arguments.length -. 'integer
index' properties outside of that range are not specified, and so they
cannot "disrupt" the algorithm.

in this case; see for `arguments[1]' then if you still want to
argue about 0 == 0, but not less than).

arguments[0] = 100;
alert([
arguments[0], // should be 100

Yes it should, as the - arguments[0] - property has just been
assigned that value.

x, // should be 10, as doesn't share

That is much harder to justify. While successful assignment
would not
normally be expected to have side effects on the values of the
properties of other objects I don't see anything that forbids this.

Yeah, that's true (any side effect could be, which specification
doesn't forbid), but this exact case is forbidden by 10.1.8

I don't see any text in 10.1.8 that does forbid it. I see text that
states what values and properties can be expected of non-negative
'inter index' properties that are less then - arguments.length -, but
that is where it stops.

(again,
you can choose to analyze arguments[1], y, and the case when no
parameters passed to (x, y) function).

arguments.length // should be 0, as [[Get]] isn't overloaded
]);
}
foo();
And only in Chrome we have "100, 100, 100, 0", meanwhile in
other: "undefined, 100, 10, 0".

But as there is no 'correct' outcome to be derived from the
specification it is not possible to declare either to be wrong.
Interactions with 'integer index' properties of the - arguments -
object that are equal to or greater than - arguments.length - are not
specified at all.

Mentioned above, it seems like formal catching the hole in ambiguous
specification description,

There is still no ambiguity; the specification specifies what it
specifies, and beyond that there is the conformance section.

but I can't find useful application of it.
Then use arguments[1] and y, when .length will be 0, and Chrome
will try to share 1 which is grater than 0. Do I understand
correctly that for you statements "1 is grater than 0" (with
which you're trying to argue) and "0 is less than 1" are not
equivalent for this case?

Less than - arguemnts.length - is what ECMA 262 specifies, and greater
than or equal is left unspecified.

Yeah, I mentioned it above.

Mentioned that there are no constraints on the existence, values or
behaviour of 'integer index' properties that are equal to or greater
than length?

Yes, it could be so, but I think this case is clear although is very
ambiguous and can be appellate with references which you mention. The
other question - what is the big deal of that too formal appellations
for the implementation level? I don't see a big.

I don't understand that.

Although, I clearly understand your position.

OK, so is what Chrome is doing an ECMAScript implementation bug or
not?

Richard.

 

[Dmitry A. Soshnikov]

On Feb 24, 5:09 pm, Richard Cornford <[email protected]>
wrote:

[...]

than it shouldn't share `y' (let's assume it's the second
parameter) and `arguments[1]' in case when no parameters
are passed.

Why? If the existence, value and behaviour of - arguments[0] - is
beyond what is specified then the same will apply to - arguments[1] -,
etc.

Although, I won't touch the case when 0 == 0, so it's allowed, as I
said that this is just a formal playing on words, but is not about
correct understanding, I ask:

function foo(x, y) {
y = 10;
alert(arguments[1]);
}

foo();

So, what we have:

- `arguments.length' == 0, right?

- 0 is less 1, right?
- 1 is greater than 0, right?
- 1 is *not* less than 0, right? - this is for you 10.1.8

If the last point is correct, why does Chrome share y and [1]? As said
absolutely clear: "In the case when arg is less than the
number of formal parameters for the Function object, this property
shares its value with the corresponding property of the activation
object".

Here `arg' (1) is not less than the number of formal parameters (0),
so Chrome is wrong, right?

If you'll answer "no", do I understand that for you "1 is greater than
0" is not the same as "0 is less than 1"? If so, I should stop on this
point, as this is just the play on words (which is not so useful,
don't you think so?).

OK, so is what Chrome is doing an ECMAScript implementation bug or
not?

Sure not Current Chrome's implementation has a bug regarding to
10.1.8 regardless _formal_ catches and references to conformance
section.

By the way, what the reason of your argue?

/ds

 

[Dmitry A. Soshnikov]

Sure not Current Chrome's implementation has a bug regarding to
10.1.8 regardless _formal_ catches and references to conformance

Typo: "Sure not"* is "Sure yes, Chrome has bug" as follows from other
part of the following statement.

/ds

 

[Richard Cornford]

On Feb 24, 5:09 pm, Richard Cornford wrote:
[...]

than it shouldn't share `y' (let's assume it's the second
parameter) and `arguments[1]' in case when no parameters
are passed.

Why? If the existence, value and behaviour of - arguments[0]
- is beyond what is specified then the same will apply to
- arguments[1] -, etc.

Although, I won't touch the case when 0 == 0, so it's
allowed, as I said that this is just a formal playing on
words, but is not about correct understanding, I ask:

function foo(x, y) {
y = 10;
alert(arguments[1]);

}

foo();

So, what we have:

- `arguments.length' == 0, right?

- 0 is less 1, right?

Less than ..., but yes.

- 1 is greater than 0, right?
- 1 is *not* less than 0, right? - this is for you 10.1.8

If the last point is correct, why does Chrome share y and [1]?
As said absolutely clear: "In the case when arg is less than the
number of formal parameters for the Function object, this property
shares its value with the corresponding property of the activation
object".

This only occurs after 'arg' has been defined as: "For each non-
negative integer, arg, less than the value of the length
property, ...". If 'arg' is a non-negative integer less than the value
of the length, and the length is zero, then there are no value that
are 'arg', and if there are no values that are 'arg' then there are no
cases "when arg is less than the number of formal parameters for the
Function object". In that case no 'integer index' properties of the
arguments object are defined by the specification, and so any that do
exist must exist under the provisions of the conformance section and
may have any value or behaviour that they want.

Here `arg' (1) is not less than the number of formal parameters (0),

There is no 'arg' that has the value 1 when - arguments.length - is
zero, as then there are no values that satisfy "non-negative integer,
arg, less than the value of the length property".

so Chrome is wrong, right?

Not according to the specification.

If you'll answer "no", do I understand that for you "1 is greater than
0" is not the same as "0 is less than 1"?

I am saying that the set of non-negative integers that are less then
zero is empty.

If so, I should stop on this point, as this is just the play on
words (which is not so useful, don't you think so?).

A play on words is not useful, but understanding the applicable
specification for the language you are using is.

Sure not Current Chrome's implementation has a bug regarding to
10.1.8 regardless _formal_ catches and references to conformance
section.

(Taking into account your correction of the above) I still see nothing
in that section that applies to 'integer index' properties of an -
arguments - object that are greater than or equal to -
arguments.length -.

By the way, what the reason of your argue?

You mean beyond demonstrating that when I said that this was
"arguable" I was telling the truth?

When people use the specification to justify their positions I prefer
to see that the specification does justify those positions. Mere
opinions should be exposed as such, and justified (or not) on other
grounds.

Richard.

 

[Garrett Smith]

On Feb 24, 2:43 pm, Richard Cornford wrote:

[...]

Your current arguing reminds some case in court when everybody
understands that it is wrong, but because of _some formal
ambiguity_ (a "formal hole in the law") is will be justified.
Sorry, no, it won't.

Yes, of course. But the accusation being made is taking the form of
accusing Chrome of violating ECMA 262 3rd Ed; that the behaviour
exhibited represents an ECMAScript implementation bug. This accusation
is false, as the behaviour exhibited is fully accommodated by the
specification.

Chrome has an interpretation of the spec that is different from what is
specified in Ecma 262 r3.

What Chrome does is not explicitly mentioned and so is not fully
accommodated. OTOH, Chrome's behavior is not explicitly forbidden,
either. It is not correct to expect that a browser won't do that.

Now if someone wanted to accuse Chrome of doing something that was
stupid, not a good idea, of no practical use or help to anyone, etc.
then that is all fine (and probably true), but let us not call it an
ECMAScript implementation bug unless it is an ECMAScript
implementation bug.

OK.

And this case is related to `arguments.length'. Sure, arguments
can be augment with new properties on runtime context phase
(which executes after entering the context phase at which
`arguments' (and all the other stuff) is created).
I don't understand that last sentence.

Doesn't matter, I meant that it's possible to add new properties
to `arguments' object (but they shouldn't affect the `.length'
property, what I said in another sentence).

function foo(x) {
x = 10;
alert(arguments[0]); // should undefined
Based on what? In this case - arguments.length - is zero, and
so there is no specified value or behaviour for an - arguments[0]
- property in this case.

I said above - it's just an attempt to be hooked for ambiguity
of the specification.

There is no ambiguity; the specification does not define anything
about an - arguments[0] - property in this case, but does allow for
properties and behaviour beyond what it does specify.

The section on the arguments object states how and when properties are
added. Chrome fills that in, but colors outside the lines a bit. In
doing that, it is going against what I read as the intent of the spec,
which is to describe precisely when properties are added to arguments
object.

If arguments is an Object object, then according to section 15.2.5, it
should not have additional properties.

| 15.2.5 Properties of Object Instances
|
| Object instances have no special properties beyond those inherited
| from the Object prototype object.

Arguments is an Object instance and so can be expected to have no
additional properties (obviously excepting those that are explicitly
stated).

 

[Garrett Smith]

ECMA 262 specifies its own interpretation?


The conformance section requires that the things that are mentioned do
happen. Anything that is not mentioned is not constrained or forbidden
by the specification. Indeed, the third paragraph of the conformance
section implies that anything that is not mentioned is explicitly allowed.

Ah, no. The conformance section does not imply that "anything that is
not mentioned is explicitly allowed."

That conformance section:

| ..."A conforming implementation of ECMAScript is permitted to provide
| additional types, values, objects, properties, and functions beyond
| those described in this specification."

I see a list of "types, values, objects, properties, and functions". Not
"anything".

A conforming implementation that features existing built-in Object, is
not permitted to provide additional properties to that Object. AIQB:

| 15.2.5 Properties of Object Instances
| Object instances have no special properties beyond those inherited
| from the Object prototype object.

OTOH, Chrome's behavior is not explicitly forbidden, either. It is not
correct to expect that a browser
won't do that.

Now if someone wanted to accuse Chrome of doing something
that was stupid, not a good idea, of no practical use or
help to anyone, etc. then that is all fine (and probably
true), but let us not call it an ECMAScript implementation
bug unless it is an ECMAScript implementation bug.
OK.

There is no ambiguity; the specification does not define
anything about an - arguments[0] - property in this case,
but does allow for properties and behaviour beyond what
it does specify.

The section on the arguments object states how and when
properties are added.

No, the specification defines a set of properties (their values and
behaviour) that will be added to an arguments object. Possible
properties beyond those specified are not covered at all.

Chrome fills that in,

Chrome satisfies the requirements of the specification, in that it adds
the properties of the arguments object that are specified, and gives
then the correct values and behaviour.

but colors outside the lines a bit.

Only in the sense that it does things beyond what is specified that are
neither required nor forbidden.

In doing that, it is going against what I read as the
intent of the spec,

You shouldn't try to read intent in the spec, the result will be
subjective and personal. Read the words in the spec.

which is to describe precisely when properties are added
to arguments object.

If that were the intent it would have been trivial to write the wording
that would make it mandatory. The absence of those words is significant.

If arguments is an Object object, then according to section
15.2.5, it should not have additional properties.

| 15.2.5 Properties of Object Instances
|
| Object instances have no special properties beyond those
| inherited from the Object prototype object.

(I assume that this means that you have abandoned the idea that section
10.1.8 contradicts the behavior exhibited by Chrome. i.e. your bug
report is incorrect in its assertion that it does.)

Either Object instances can have additional properties or they cannot.
The section above says they cannot.

The Arguments object is an Object instance and Object instances have no
additional properties.

It can be expected that arguments object has no additional properties
except for under the specific circumstances stated in that section.

That section is best considered in comparison with similar section on
the properties of instances of other types, such as:-

| 15.3.5 Properties of Function Instances

The arguments object is not a function.

[snip]

No, an arguments object may have properties beyond those explicitly
specified.

Not if it is an Object instance.

 

[Richard Cornford]

Ah, no. The conformance section does not imply that "anything that
is not mentioned is explicitly allowed."

That conformance section:

| ..."A conforming implementation of ECMAScript is permitted to
| provide additional types, values, objects, properties, and
| functions beyond those described in this specification."

I see a list of "types, values, objects, properties, and functions".
Not "anything".

Don't forget the additional syntax allowed by the last paragraph of
the conformance section. Once you are allowing additional types,
values, objects, properties, functions and syntax what are you
including in your 'anything' that is not allowed?

A conforming implementation that features existing built-in
Object,

Such as - Object.prototype -?

is not permitted to provide additional properties to that
Object. AIQB:

Yes they are. That is precisely what they are allowed to do, and very
frequently do do.

Object.prototype certainly is a built-in object, and it is pretty
normal for it to have properties beyond those mentioned in ECMA 262.

Either Object instances can have additional properties or they
cannot.

They can.

The section above says they cannot.

No, it says that, as specified in ECMA 262, they don't have any
"special properties".

The Arguments object is an Object instance

The arguments object starts off as an Object instance, it is then
modified.

and Object instances have no additional properties.

Even if I did accept that Object instances can have no properties
beyond those listed in ECMA 262 3rd Ed., once they have been modified
then their original state is no longer significant.

It can be expected that arguments object has no additional
properties except for under the specific circumstances stated
in that section.

But it should not be expected. The stage of modifying an Object
instance into an arguments object is precisely the sort of stage at
which additional properties beyond those specified could be added.

The arguments object is not a function.

No, but if a "Properties of ... Instances" section exists for all the
equivalent types it should not be surprising if some of them just
state that there is nothing to declare in such a section, while
others, such as in the case of Function instances, list special
properties of the instances. The absence of a list in such a context
should not be taken as restrictive.

If the spec wanted to say that Object instances could not have
properties beyond those specified then it would simply have to say
that they must not have such properties. It is the absence of such a
restriction that means there is no restriction.

And Function instances often have properties beyond those listed in
section 15.3.4, such as a - name - property. This is exactly the sort
of addition that the conformance section does allow.

[snip]

No, an arguments object may have properties beyond those
explicitly specified.

Not if it is an Object instance.

Yes if it is an Object instance, and yes if it was an Object instance
that has been modified (the latter being the case here).

Richard.

 

[Thomas 'PointedEars' Lahn]

That conformance section:

| ..."A conforming implementation of ECMAScript is permitted to provide
| additional types, values, objects, properties, and functions beyond
| those described in this specification."

I see a list of "types, values, objects, properties, and functions". Not
"anything".

If I am understanding correctly that the issue is that the object referred
to by `arguments' would have additional properties, then you have clearly
overlooked the "properties" part in that sentence. That applies to *all*
properties of *all* objects.

A conforming implementation that features existing built-in Object, is
not permitted to provide additional properties to that Object. AIQB:

| 15.2.5 Properties of Object Instances
| Object instances have no special properties beyond those inherited
| from the Object prototype object.

That is not what this means, as your interpretation would directly
contradict the Conformance section, and render several major if not all
past and present implementations not compliant, which is a bit hard to
believe.

[...]
No, an arguments object may have properties beyond those explicitly
specified.

Not if it is an Object instance.

ISTM you are misinterpreting the Specification. That you are follows
implicitly from the existence of `arguments.caller' in some
implementations, which is ECMAScript-compliant behavior as well. And what
about the properties that JavaScript adds to Object instances? Are you
declaring JavaScript non-compliant here?


PointedEars