Prev: FAQ Topic - Why does framename.print() not print the correct frame in IE? (2010-02-19)
Next: My Library TaskSpeed tests updated--MultipleIE has the IE6 problem,not My Library
From: Jorge on 20 Feb 2010 15:02
On Feb 20, 7:38 pm, Asen Bozhilov <asen.bozhi...(a)gmail.com> wrote:
> Jorge wrote:
> > Ah, well, ok.
> > But I still believe that your phrase "And AO cannot be marked as
> > garbage collection when execution context exit" has nothing to do with
> > it, for that's necessarily so when/if the returned value is an inner
> > function's reference?
>
> Yes but your point isn't related with returned value from
> ExecutionContext. Your point is related with 13.2 Creating Function
> Objects and internal [[Scope]] property, which refer VO associated
> with execution context in which FunctionDeclaration and
> FunctionExpression evaluated. For example if i use Function
> Constructor, internal [[Scope]] property of created function object
> will refer Global Object independ from calling execution context.
>
> You can easy observe this in Rhino 1.7R2, there `function' objects has
> property `__parent__', which is mimic of internal [[Scope]] property.
>
> var f = (function() {
>   return new Function();
>
> })();
>
> print(f.__parent__ === this); //true
>
> And in this example, there are no any references to AO associated with
> execution context created from anonymous function. And therefore AO
> can marked for garbage collection, when execution context return
> value.

Asen, in that example, obviously, the returned f() does not qualify as
an *inner* function.
--
Jorge.
From: kangax on 20 Feb 2010 15:41
On 2/20/10 1:03 PM, Richard Cornford wrote:
> Asen Bozhilov wrote:
[...]
>> How can you explain:
>>
>> var x = 10;
>> +++x;
>>
>> There SyntaxError instead of runtime error.
>
> A reasonable question as the interpretation should be the equivalent of:-
>
> ++(+x);
>
> - and as - (+x) - will evaluate as a (numeric) value rather than a
> Reference type, when step 5 in the Prefix Increment Operator algorithm
> (11.4.4) calls the PutValue function (8.7.2) PutValue should throw a
> Reference Error.
>
> However, in the section of the spec on errors we find:-
>
> | 16 Errors
> | ...
> | An implementation may treat any instance of the following kinds of
> | runtime errors as a syntax error and therefore report it early:
> |
> | * Improper uses of return, break, and continue.
> | * Using the eval property other than via a direct call.
> | * Errors in regular expression literals.
> | * Attempts to call PutValue on a value that is not a reference
> | (for example, executing the assignment statement 3=4).
>
> - where the last bulleted point refers to examples of calling PutValue
> where the pertinent argument is not a Reference type, and makes
> provision for reporting that as a syntax error rather than a runtime
> error. So the observed behaviour is at the discretion of the
> implementation, but is correct according to the specification.

Interesting. I wasn't aware of this allowance.

But what does "Improper use of return" mean? The only restriction on
return statement I can think of is that LineTerminator can not appear
between `return` token and following expression. However, ASI rules
clearly imply that when LineTerminator is present in between token and
expression, semicolon is inserted right after `return`. There doesn't
seem to be a way to use `return` improperly there.

Another restriction is that return statement can not appear anywhere but
within FunctionBody. However, 12.9 clearly states that when this
happens, the Program is considered syntactically incorrect.

So which *runtime error* could there be with regards to `return`?

--
kangax
From: Richard Cornford on 21 Feb 2010 10:50
kangax" wrote in message:
> On 2/20/10 1:03 PM, Richard Cornford wrote:
>> Asen Bozhilov wrote:
> [...]
>>> How can you explain:
>>>
>>> var x = 10;
>>> +++x;
>>>
>>> There SyntaxError instead of runtime error.
>>
>> A reasonable question as the interpretation should be the
>> equivalent of:-
>>
>> ++(+x);
>>
>> - and as - (+x) - will evaluate as a (numeric) value rather
>> than a Reference type, when step 5 in the Prefix Increment
>> Operator algorithm (11.4.4) calls the PutValue function
>> (8.7.2) PutValue should throw a Reference Error.
>>
>> However, in the section of the spec on errors we find:-
>>
>> | 16 Errors
>> | ...
>> | An implementation may treat any instance of the following
>> | kinds of runtime errors as a syntax error and therefore
>> | report it early:
>> |
>> | * Improper uses of return, break, and continue.
>> | * Using the eval property other than via a direct call.
>> | * Errors in regular expression literals.
>> | * Attempts to call PutValue on a value that is not a reference
>> | (for example, executing the assignment statement 3=4).
>>
>> - where the last bulleted point refers to examples of calling
>> PutValue where the pertinent argument is not a Reference type,
>> and makes provision for reporting that as a syntax error rather
>> than a runtime error. So the observed behaviour is at the
>> discretion of the implementation, but is correct according to
>> the specification.
>
> Interesting. I wasn't aware of this allowance.
>
> But what does "Improper use of return" mean? The only restriction
> on return statement I can think of is that LineTerminator can not
> appear between `return` token and following expression. However,
> ASI rules clearly imply that when LineTerminator is present in
> between token and expression, semicolon is inserted right after
> `return`. There doesn't seem to be a way to use `return`
> improperly there.
>
> Another restriction is that return statement can not appear
> anywhere but within FunctionBody. However, 12.9 clearly states
> that when this happens, the Program is considered syntactically
> incorrect.

Your position being that as a return outside of a function body is
already a syntax error there are no context where its "improper use"
could result in a runtime error, and so section 16 has no reason for
making provision for those (non-existent) runtime errors being reported
as syntax errors?

> So which *runtime error* could there be with regards to
> `return`?

I cannot think of any. It looks like that point in section 16 is
redundant.

While we are on the subject of how the spec requires code to
interpreted, you might be interested in considering how:-

<html>
<head>
<title></title>
</head>
<body>
<pre>
<script type="text/javascript">
function a(){
return ({
toString:function(){
alert('a called');
}
})
}

function f(){
var x = 0;
a:while(!x++){
while(true)
break/*
*/a
(x+1).toString();
}
}

document.write((''+f));

window.onload = function(){
f();
};
</script>
</pre>
</body>
</html>

- should work, particularly with regard to the - break - statement (in
the - f - function), automatic semicolon insertion, and the question of
whether the alert (called in the toString method of the object returned
by the - a - function) should be displayed or not. Actual
interpretations in browsers differ so will be of little help in deciding
which is correct.

Richard.

From: kangax on 22 Feb 2010 01:32
On 2/21/10 10:50 AM, Richard Cornford wrote:
> kangax" wrote in message:
>> On 2/20/10 1:03 PM, Richard Cornford wrote:
[...]
>>> | 16 Errors
>>> | ...
>>> | An implementation may treat any instance of the following
>>> | kinds of runtime errors as a syntax error and therefore
>>> | report it early:
>>> |
>>> | * Improper uses of return, break, and continue.
>>> | * Using the eval property other than via a direct call.
>>> | * Errors in regular expression literals.
>>> | * Attempts to call PutValue on a value that is not a reference
>>> | (for example, executing the assignment statement 3=4).
[...]
>> Another restriction is that return statement can not appear
>> anywhere but within FunctionBody. However, 12.9 clearly states
>> that when this happens, the Program is considered syntactically
>> incorrect.
>
> Your position being that as a return outside of a function body is
> already a syntax error there are no context where its "improper use"
> could result in a runtime error, and so section 16 has no reason for
> making provision for those (non-existent) runtime errors being reported
> as syntax errors?

Exactly.

>
>> So which *runtime error* could there be with regards to
>> `return`?
>
> I cannot think of any. It looks like that point in section 16 is redundant.

Ok. I'll bring it up on es-discuss list whenever I get a chance.

>
> While we are on the subject of how the spec requires code to
> interpreted, you might be interested in considering how:-
>
> <html>
> <head>
> <title></title>
> </head>
> <body>
> <pre>
> <script type="text/javascript">
> function a(){
> return ({
> toString:function(){
> alert('a called');
> }
> })
> }
>
> function f(){
> var x = 0;
> a:while(!x++){
> while(true)
> break/*
> */a
> (x+1).toString();
> }
> }
>
> document.write((''+f));
>
> window.onload = function(){
> f();
> };
> </script>
> </pre>
> </body>
> </html>
>
> - should work, particularly with regard to the - break - statement (in
> the - f - function), automatic semicolon insertion, and the question of
> whether the alert (called in the toString method of the object returned
> by the - a - function) should be displayed or not. Actual
> interpretations in browsers differ so will be of little help in deciding
> which is correct.

Well, comments containing line terminator (as the one in your example)
should be replaced with one single LineTerminator (during tokenization,
AIUI). And `break` followed by LineTerminator (before following token)
should be a candidate for ASI, so:

break/*
*/a
(x+1).toString();

is transformed to:

break
a
(x+1).toString();

which is then further transformed to:

break;
a
(x+1).toString;

// or functionally identical

break;
a(x+1).toString();

I see that WebKit doesn't respect this, but latest Mozilla and Opera do.

A simpler example demonstrates this clearly:

(function(){
return/*
*/1
})();

returns `1`, not `undefined` as it should.


--
kangax
From: Richard Cornford on 22 Feb 2010 02:49
kangax wrote:
> On 2/21/10 10:50 AM, Richard Cornford wrote:
<snip>
>> function a(){
>> return ({
>> toString:function(){
>> alert('a called');
>> }
>> })
>> }
>>
>> function f(){
>> var x = 0;
>> a:while(!x++){
>> while(true)
>> break/*
>> */a
>> (x+1).toString();
>> }
>> }
<snip>
>> - should work, particularly with regard to the - break -
>> statement (in the - f - function), automatic semicolon
>> insertion, and the question of whether the alert (called
>> in the toString method of the object returned by the - a
>> - function) should be displayed or not. Actual
>> interpretations in browsers differ so will be of little
>> help in deciding which is correct.
>
> Well, comments containing line terminator (as the one in
> your example) should be replaced with one single LineTerminator
> (during tokenization, AIUI).

Treated as line terminators during parsing, but the distinction is
insignificant.

> And `break` followed by LineTerminator (before following token) should
> be a candidate for ASI, so:
>
> break/*
> */a
> (x+1).toString();
>
> is transformed to:
>
> break
> a
> (x+1).toString();
>
> which is then further transformed to:
>
> break;
> a
> (x+1).toString;
>
> // or functionally identical
>
> break;
> a(x+1).toString();

That is the way I read the spec in this case.

> I see that WebKit doesn't respect this,

So that is Safari and Chrome getting this wrong, and IE is wrong as
well.

> but latest Mozilla and Opera do.

The latest Firefox, but Firefox 3.0 was getting this wrong, along with
all the earlier Mozilla browsers I looked at.

Opera, on the other hand, has always used the correct interpretation.

> A simpler example demonstrates this clearly:
>
> (function(){
> return/*
> */1
> })();
>
> returns `1`, not `undefined` as it should.

Yes, the example is more complex than is necessary. I wrote it to look
for something else; changes in meaning following from function
de-compilation/re-compilation. I was thinking that if the de-compilation
stripped comments there might be an example of removing a multi-line
comment with a line terminator and falling to include the line
terminator in the string output. Then the re-complied function would
behave differently from the original. As it turns out, all the
environments where no line terminator appears in the de-complied
function string already fail to treat the multi-line comment correctly,
so the meaning doesn't change, it is just wrong in both cases.

Richard.

First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4 5 6
Prev: FAQ Topic - Why does framename.print() not print the correct frame in IE? (2010-02-19)
Next: My Library TaskSpeed tests updated--MultipleIE has the IE6 problem,not My Library