Re: Behavior of `eval` in non strict mode.
Things to complain about! JS interop is far better than other languages with multiple implementations. Never mind complex APIs such as the DOM. /be > On Jan 10, 2014, at 7:05 PM, Andrea Giammarchi > wrote: > > I've learned it the hard way ... when in doubt, see what Firefox does ... > usually that's the meant standard behavior. > > I really wish JavaScript was a Test Driven developing programming language > ... the amount of fragmentation for every single little thing apparently > never tested against meant specs is often too damn high! > > Best Regards > > >> On Fri, Jan 10, 2014 at 5:50 PM, Benjamin (Inglor) Gruenbaum >> wrote: >> Thanks, this clarifies things. I'll update the answer on SO to reflect the >> findings. >> >> >> On Thu, Jan 9, 2014 at 3:54 AM, André Bargull wrote: Thanks for the reply. I'd actually expect `undefined` because function declarations does not return anything. Converting it to a function expression kind of misses the point since those are well... expressions :) I've tried looking in all the relevant places in the spec but still couldn't unambiguously figure out which browser is 'correct'. >>> >>> There are a few edge cases in reference resolution which are not correctly >>> implemented in most browsers. Your example is basically the same as test >>> case 2 from https://bugs.ecmascript.org/show_bug.cgi?id=1751. The relevant >>> section in the specification is "12.13.4 Runtime Semantics: Evaluation": >>> The left hand side of an assignment is always evaluated before the right >>> hand side. This includes resolving and remembering the reference >>> information for an identifier reference. In this case the identifier >>> reference resolves to a binding on the global object, so assignment must be >>> performed on the global, even if a (direct) eval expression introduces new >>> bindings with the same name in the current scope. >>> >>> >>> - André > > ___ > es-discuss mailing list > es-discuss@mozilla.org > https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Behavior of `eval` in non strict mode.
I've learned it the hard way ... when in doubt, see what Firefox does ... usually that's the meant standard behavior. I really wish JavaScript was a Test Driven developing programming language ... the amount of fragmentation for every single little thing apparently never tested against meant specs is often too damn high! Best Regards On Fri, Jan 10, 2014 at 5:50 PM, Benjamin (Inglor) Gruenbaum < ing...@gmail.com> wrote: > Thanks, this clarifies things. I'll update the answer on SO to reflect the > findings. > > > On Thu, Jan 9, 2014 at 3:54 AM, André Bargull wrote: > >> Thanks for the reply. >>> >>> I'd actually expect `undefined` because function declarations does not >>> return anything. Converting it to a function expression kind of misses >>> the >>> point since those are well... expressions :) >>> >>> I've tried looking in all the relevant places in the spec but still >>> couldn't unambiguously figure out which browser is 'correct'. >>> >> >> There are a few edge cases in reference resolution which are not >> correctly implemented in most browsers. Your example is basically the same >> as test case 2 from https://bugs.ecmascript.org/show_bug.cgi?id=1751. >> The relevant section in the specification is "12.13.4 Runtime Semantics: >> Evaluation": The left hand side of an assignment is always evaluated before >> the right hand side. This includes resolving and remembering the reference >> information for an identifier reference. In this case the identifier >> reference resolves to a binding on the global object, so assignment must be >> performed on the global, even if a (direct) eval expression introduces new >> bindings with the same name in the current scope. >> >> >> - André >> > > ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Behavior of `eval` in non strict mode.
Thanks, this clarifies things. I'll update the answer on SO to reflect the findings. On Thu, Jan 9, 2014 at 3:54 AM, André Bargull wrote: > Thanks for the reply. >> >> I'd actually expect `undefined` because function declarations does not >> return anything. Converting it to a function expression kind of misses the >> point since those are well... expressions :) >> >> I've tried looking in all the relevant places in the spec but still >> couldn't unambiguously figure out which browser is 'correct'. >> > > There are a few edge cases in reference resolution which are not correctly > implemented in most browsers. Your example is basically the same as test > case 2 from https://bugs.ecmascript.org/show_bug.cgi?id=1751. The > relevant section in the specification is "12.13.4 Runtime Semantics: > Evaluation": The left hand side of an assignment is always evaluated before > the right hand side. This includes resolving and remembering the reference > information for an identifier reference. In this case the identifier > reference resolves to a binding on the global object, so assignment must be > performed on the global, even if a (direct) eval expression introduces new > bindings with the same name in the current scope. > > > - André > ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Behavior of `eval` in non strict mode.
André Bargull wrote: There are a few edge cases in reference resolution which are not correctly implemented in most browsers. Your example is basically the same as test case 2 from https://bugs.ecmascript.org/show_bug.cgi?id=1751. The relevant section in the specification is "12.13.4 Runtime Semantics: Evaluation": The left hand side of an assignment is always evaluated before the right hand side. This includes resolving and remembering the reference information for an identifier reference. In this case the identifier reference resolves to a binding on the global object, so assignment must be performed on the global, even if a (direct) eval expression introduces new bindings with the same name in the current scope. Has anyone filed bugs against V8 and Chakra? /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Behavior of `eval` in non strict mode.
Thanks for the reply. I'd actually expect `undefined` because function declarations does not return anything. Converting it to a function expression kind of misses the point since those are well... expressions :) I've tried looking in all the relevant places in the spec but still couldn't unambiguously figure out which browser is 'correct'. There are a few edge cases in reference resolution which are not correctly implemented in most browsers. Your example is basically the same as test case 2 from https://bugs.ecmascript.org/show_bug.cgi?id=1751. The relevant section in the specification is "12.13.4 Runtime Semantics: Evaluation": The left hand side of an assignment is always evaluated before the right hand side. This includes resolving and remembering the reference information for an identifier reference. In this case the identifier reference resolves to a binding on the global object, so assignment must be performed on the global, even if a (direct) eval expression introduces new bindings with the same name in the current scope. - André ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Behavior of `eval` in non strict mode.
I think eval returns whatever it evaluates ... i.e.
`var x = eval('123');`
x will be 123 since it's returned. Accordingly, if you assign a function,
this should be returned and become automatically an expression.
The inconsistency exists using explicitly parenthesis but I don't remember
specs saying that eval should not return the evaluated content in case of
function declaration.
Hard to tell which one is correct, the example is odd anyway.
Regards
On Wed, Jan 8, 2014 at 3:56 PM, Benjamin (Inglor) Gruenbaum <
ing...@gmail.com> wrote:
> Thanks for the reply.
>
> I'd actually expect `undefined` because function declarations does not
> return anything. Converting it to a function expression kind of misses the
> point since those are well... expressions :)
>
> I've tried looking in all the relevant places in the spec but still
> couldn't unambiguously figure out which browser is 'correct'.
>
>
> On Thu, Jan 9, 2014 at 1:53 AM, Andrea Giammarchi <
> andrea.giammar...@gmail.com> wrote:
>
>> looks rather an eval gotcha but I think Firefox is correct anyway. try `f
>> = eval("(" + f + ")");` instead and it should produce what you expect (I
>> guess)
>>
>> Regards
>>
>>
>> On Wed, Jan 8, 2014 at 3:37 PM, Benjamin (Inglor) Gruenbaum <
>> ing...@gmail.com> wrote:
>>
>>> I've recently run into this question in Stack Overflow:
>>>
>>> http://stackoverflow.com/q/21008329/1348195
>>>
>>> ```
>>>
>>>
>>> function f() {
>>> f = eval("" + f);
>>> console.log("Inside a call to f(), f is: \n%s", f);}
>>>
>>> f();
>>>
>>> console.log("After a call to f(), f is: \n%s", f);
>>>
>>> ```
>>>
>>> What should the output of the following be?
>>>
>>> I expected `undefined` on both but that's because I'm used to strict
>>> mode. IE/Chrome treat this differently from Firefox and to be honest when I
>>> checked the spec it boiled down to which context is affected here.
>>>
>>> In IE/Chrome the eval is creating `f` inside the context of `f` acting
>>> like a function declaration inside. In Firefox it's acting like it's
>>> running in the global context.
>>>
>>> Which is correct? I've tried to follow 10.4.2 (or 18.2.1 in the ES6
>>> draft which is nice) but I still couldn't figure out what "if there is no
>>> calling context means".
>>>
>>> Thanks,
>>> Benjamin Grunebaum
>>>
>>> ___
>>> es-discuss mailing list
>>> es-discuss@mozilla.org
>>> https://mail.mozilla.org/listinfo/es-discuss
>>>
>>>
>>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Behavior of `eval` in non strict mode.
Thanks for the reply.
I'd actually expect `undefined` because function declarations does not
return anything. Converting it to a function expression kind of misses the
point since those are well... expressions :)
I've tried looking in all the relevant places in the spec but still
couldn't unambiguously figure out which browser is 'correct'.
On Thu, Jan 9, 2014 at 1:53 AM, Andrea Giammarchi <
andrea.giammar...@gmail.com> wrote:
> looks rather an eval gotcha but I think Firefox is correct anyway. try `f
> = eval("(" + f + ")");` instead and it should produce what you expect (I
> guess)
>
> Regards
>
>
> On Wed, Jan 8, 2014 at 3:37 PM, Benjamin (Inglor) Gruenbaum <
> ing...@gmail.com> wrote:
>
>> I've recently run into this question in Stack Overflow:
>>
>> http://stackoverflow.com/q/21008329/1348195
>>
>> ```
>>
>>
>> function f() {
>> f = eval("" + f);
>> console.log("Inside a call to f(), f is: \n%s", f);}
>>
>> f();
>>
>> console.log("After a call to f(), f is: \n%s", f);
>>
>> ```
>>
>> What should the output of the following be?
>>
>> I expected `undefined` on both but that's because I'm used to strict
>> mode. IE/Chrome treat this differently from Firefox and to be honest when I
>> checked the spec it boiled down to which context is affected here.
>>
>> In IE/Chrome the eval is creating `f` inside the context of `f` acting
>> like a function declaration inside. In Firefox it's acting like it's
>> running in the global context.
>>
>> Which is correct? I've tried to follow 10.4.2 (or 18.2.1 in the ES6
>> draft which is nice) but I still couldn't figure out what "if there is no
>> calling context means".
>>
>> Thanks,
>> Benjamin Grunebaum
>>
>> ___
>> es-discuss mailing list
>> es-discuss@mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Behavior of `eval` in non strict mode.
looks rather an eval gotcha but I think Firefox is correct anyway. try `f =
eval("(" + f + ")");` instead and it should produce what you expect (I
guess)
Regards
On Wed, Jan 8, 2014 at 3:37 PM, Benjamin (Inglor) Gruenbaum <
ing...@gmail.com> wrote:
> I've recently run into this question in Stack Overflow:
>
> http://stackoverflow.com/q/21008329/1348195
>
> ```
>
> function f() {
> f = eval("" + f);
> console.log("Inside a call to f(), f is: \n%s", f);}
>
> f();
>
> console.log("After a call to f(), f is: \n%s", f);
>
> ```
>
> What should the output of the following be?
>
> I expected `undefined` on both but that's because I'm used to strict mode.
> IE/Chrome treat this differently from Firefox and to be honest when I
> checked the spec it boiled down to which context is affected here.
>
> In IE/Chrome the eval is creating `f` inside the context of `f` acting
> like a function declaration inside. In Firefox it's acting like it's
> running in the global context.
>
> Which is correct? I've tried to follow 10.4.2 (or 18.2.1 in the ES6 draft
> which is nice) but I still couldn't figure out what "if there is no calling
> context means".
>
> Thanks,
> Benjamin Grunebaum
>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Behavior of `eval` in non strict mode.
I've recently run into this question in Stack Overflow:
http://stackoverflow.com/q/21008329/1348195
```
function f() {
f = eval("" + f);
console.log("Inside a call to f(), f is: \n%s", f);}
f();
console.log("After a call to f(), f is: \n%s", f);
```
What should the output of the following be?
I expected `undefined` on both but that's because I'm used to strict mode.
IE/Chrome treat this differently from Firefox and to be honest when I
checked the spec it boiled down to which context is affected here.
In IE/Chrome the eval is creating `f` inside the context of `f` acting like
a function declaration inside. In Firefox it's acting like it's running in
the global context.
Which is correct? I've tried to follow 10.4.2 (or 18.2.1 in the ES6 draft
which is nice) but I still couldn't figure out what "if there is no calling
context means".
Thanks,
Benjamin Grunebaum
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
