<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
  <head>
    <meta content="text/html; charset=windows-1252"
      http-equiv="Content-Type">
  </head>
  <body text="#000000" bgcolor="#ffffff">
    On 19.02.2011 21:23, Allen Wirfs-Brock wrote:
    <blockquote
      cite="mid:51962BC4-E1C9-4DA0-BC7C-F149524B31D1@wirfs-brock.com"
      type="cite">
      <div>The distinction between a direct eval and an eval first
        appears in Ecma-262, Edition 2 which said: "If value of the <span
          style="font: 10px Courier;"><b><font class="Apple-style-span"
              size="3"><span class="Apple-style-span" style="font-size:
                12px;"><font class="Apple-style-span" face="Helvetica">eval
                </font></span></font></b></span>property is used in any
        way other than a direct call (that is, other than by the
        explicit use of its name as an <i>Identifier </i>which is the
        <i>MemberExpression </i>in a <i>CallExpression</i>), or if the
        <span style="font: 10px Courier;"><b><font
              class="Apple-style-span" size="3"><span
                class="Apple-style-span" style="font-size: 12px;"><font
                  class="Apple-style-span" face="Helvetica">eval </font></span></font></b></span>property
        is assigned to, an <b>EvalError </b>exception may be thrown."</div>
      <div><br>
      </div>
      <div>Note that the ES2 definition left support for indirect eval
        as an implementation option.  Some browsers tried to implement
        throwing on EvalError but they discovered that this was
        incompatible with the web.  So they implemented globally scoped
        indirect eval which proved to be compatible with the web.  By
        the time of the drafting of ES5 the situations was that that
        some browsers implemented indirect and direct evals identically
        and some browsers implemented globally scoped indirect eval. No
        browser made use of the specification permitted EvalError.</div>
      <div><br>
      </div>
    </blockquote>
    <br>
    Yeah, I see. So this is all about the lexical (static) scope. I.e.
    the closured lexical environment of the built-in `eval` is the
    global environment, therefore it has access only for the global
    bindings, right?<br>
    <br>
    It seems also explains that the `Function`'s code is always
    evaluated in the global context -- it's in contrast with direct
    `eval`'s which isn't a function call at all. Is it so (regarding
    `Function`)?<br>
    <br>
    <blockquote
      cite="mid:51962BC4-E1C9-4DA0-BC7C-F149524B31D1@wirfs-brock.com"
      type="cite">
      <div>For ES5 we wanted to eliminate any implementation options
        from the eval spec and to make it compatible with the web.
         Globally scoped indirect eval served was the solution we
        choose. The rest of the details including the treatment of
        strict code follow from that decision.</div>
      <div><br>
      </div>
    </blockquote>
    <br>
    Yep, it's clear.<br>
    <br>
    <blockquote
      cite="mid:51962BC4-E1C9-4DA0-BC7C-F149524B31D1@wirfs-brock.com"
      type="cite">
      <div>Also note that the term  "indirect eval" is never used in the
        normative parts of the ES5 specification.  It only distinguishes
        "direct calls to eval" as the special case.  The term "indirect
        eval" is only used in Annex D.</div>
      <div><br>
      </div>
    </blockquote>
    <br>
    Yes, though, exactly the term "indirect" became the most popular in
    this case.<br>
    <br>
    <blockquote
      cite="mid:51962BC4-E1C9-4DA0-BC7C-F149524B31D1@wirfs-brock.com"
      type="cite">
      <div><br>
      </div>
      <div><br>
        <blockquote type="cite">
          <div text="#000000" bgcolor="#ffffff">
            <blockquote cite="mid:4D5F0B11.4030908@gmail.com"
              type="cite"> On 18.02.2011 20:04, Allen Wirfs-Brock wrote:
              <blockquote
                cite="mid:5DF81334-FA04-410C-8136-7644BFC8788F@wirfs-brock.com"
                type="cite">Here is another way to think about it.
                <div><br>
                </div>
                <div>The built-in function object that is the initial
                  value of the global  "eval"  (defined in 15.1.2.1) is
                  a non-strict function. Hence anything it does defaults
                  to "non-strict" and it uses the global environment as
                  the VariableEnvironment for the code it evaluates.
                   However, if the argument code contains an use strict
                  directive, then it uses a new child environment of the
                  global environment as the VariableEnvironment.   This
                  is all specific defined behavior of the built-in eval
                  function object and is completely independent of who
                  calls the function or how the caller accessed the
                  function.</div>
                <div><br>
                </div>
              </blockquote>
              <br>
              Yes, it's clear how it looks/implemented _technically_,
              however doesn't explain a practical rationale. So at the
              moment I have the following conclusion and understanding
              (please correct me if I'm mistaken):<br>
              <br>
              An indirect `eval` introduced into ES spec not because of
              some/any security reason (what I mentioned earlier in my
              explanations), and even not because of some _practical_
              reasons, but just because of _complexity of the
              implementation_. I.e. _initially_ indirect `eval` is
              related with the implementation level only (only after
              that JS devs adapted this _technique_ for already
              mentioned getting of the global object in strict mode).<br>
              <br>
              Is this explanation correct?<br>
            </blockquote>
          </div>
        </blockquote>
        <div><br>
        </div>
        <div>It's not how I would state it.  As a general design
          principle the behavior of any function, when called should
          only depend upon the environment it was defined in and the
          arguments that are explicitly passed to it. </div>
      </div>
    </blockquote>
    <br>
    Yes, as I mentioned -- a normal lexical scope implementation.<br>
    <br>
    <blockquote
      cite="mid:51962BC4-E1C9-4DA0-BC7C-F149524B31D1@wirfs-brock.com"
      type="cite">
      <div>
        <div> eval, as a built-in function, is defined within the global
          environment and it has no explicit arguments that expose the
          scope of its caller.  Hence, it only is allowed to manipulate
          the global scope. </div>
        <div><br>
        </div>
      </div>
    </blockquote>
    <br>
    Yes, only if an implementation can handle its invocation
    differently. I see that you say that built-in `eval` is just a
    simple function which obey the same lexical scoping rules and
    therefore all the identifiers lookup is made in statically saved
    environment.<br>
    <br>
    On the other hand, why the implementation cannot treat the `eval`'s
    activation differently? Why not to save its original lexical
    environment (that is, global), set it to the environment of the
    caller and after the evaluation again restore it?<br>
    <br>
    <br>
    <blockquote
      cite="mid:51962BC4-E1C9-4DA0-BC7C-F149524B31D1@wirfs-brock.com"
      type="cite">
      <div>
        <div>Direct eval, is the "odd duck".  There is no normal
          function mechanism that permits its behavior.   Rather than
          extending the semantics of function calls in general (any call
          may be an indirect eval call) we special case the handling of
          direct eval in 10.4.2 step 2.</div>
        <div><br>
        </div>
      </div>
    </blockquote>
    <br>
    Hm.. and this is the answer on my previous question. No special
    semantics with replacing saved lexical environment.<br>
    <br>
    <blockquote
      cite="mid:51962BC4-E1C9-4DA0-BC7C-F149524B31D1@wirfs-brock.com"
      type="cite">
      <div>
        <div>Implementation impact is something we're alway considering,
          but it isn't needed to justify this behavior.  If you are
          going to treat eval as a normal function object then it needs
          to be callable as such.</div>
        <div><br>
        </div>
      </div>
    </blockquote>
    <br>
    Yes, it's clear now -- the lexical scope and a common functions'
    behavior -- that's the main reason.<br>
    <br>
    <blockquote
      cite="mid:51962BC4-E1C9-4DA0-BC7C-F149524B31D1@wirfs-brock.com"
      type="cite">
      <div>
        <div><br>
        </div>
        <blockquote type="cite">
          <div text="#000000" bgcolor="#ffffff">
            <blockquote cite="mid:4D5F0B11.4030908@gmail.com"
              type="cite"> <br>
              <blockquote
                cite="mid:5DF81334-FA04-410C-8136-7644BFC8788F@wirfs-brock.com"
                type="cite">
                <div>
                  <div>
                    <div>An "indirect eval" is any invocation of the
                      above function.</div>
                    <div><br>
                    </div>
                  </div>
                </div>
              </blockquote>
              <br>
              This is a subtle case, thanks (taking into account your
              following explanation of with the inlining the code to the
              call site). So, _abstractly_ (? -- I can't say precisely
              whether it's _technically_ though, since I'm not the
              implementer), if _syntactically_ we use this form:<br>
              <br>
              eval(...)<br>
              <br>
              it isn't even an `eval` call, but just an inlining. I can
              imagine it abstractly as (with providing a "sandbox"
              environment):<br>
              <br>
              (function foo() {<br>
                eval("var x = 10;")<br>
              })();<br>
              <br>
              is _abstractly_ desugars (inline) into:<br>
              <br>
              (function foo() {<br>
                (function __directEval(configurableBindings?) {<br>
                  var x = 10;<br>
                })(true);<br>
              })();<br>
              <br>
            </blockquote>
            <br>
            Note: this abstract representation doesn't explain also
            dynamic eval's string. i.e. when some variable should be
            determined at runtime, when the environment is formed:<br>
            <br>
            (function foo(x) {<br>
              eval("var x = " + x + ";")<br>
            })(10);<br>
            <br>
            How here the inlining can work?<br>
          </div>
        </blockquote>
        <div><br>
        </div>
        <div>The declaration instantiation rules get in the way of these
          simple inlining models.  Consider this:</div>
        <div>function outer() {</div>
        <div>   var x=0;</div>
        <div>   (function () {</div>
        <div>      x=1;</div>
        <div>      var x=2}</div>
        <div>    )();</div>
        <div>   return x;   //returns 0</div>
        <div>}</div>
        <div><br>
        </div>
        <div>compared to</div>
        <div><br>
        </div>
        <div>
          <div>function outer() {</div>
          <div>   var x=0;</div>
          <div>   (function () {</div>
          <div>      x=1;</div>
          <div>     eval(" var x=2");}</div>
          <div>    )();</div>
          <div>   return x;   //returns 1</div>
          <div>}</div>
          <div><br>
          </div>
        </div>
      </div>
    </blockquote>
    <br>
    Yeah, I know that the "hoisting" breaks my simplified model of
    `eval`'s inlining, but I wanted just to imagine how it is made. If
    to exclude the "hoisting" (i.e. all definitions are made
    sequentially in runtime), then direct `eval`'s desugars quite
    normally.<br>
    <br>
    Thanks, again Allen, I think at this step it became completely
    clear. (probably I'll write a small blog-post note with explaining
    all this suble cases and especially why Function("...") in contrast
    with (direct) `eval` executes in the global scope).<br>
    <br>
    Dmitry.<br>
    <br>
    <blockquote
      cite="mid:51962BC4-E1C9-4DA0-BC7C-F149524B31D1@wirfs-brock.com"
      type="cite">
      <div>
        <blockquote type="cite">
          <div text="#000000" bgcolor="#ffffff"> <br>
            <blockquote cite="mid:4D5F0B11.4030908@gmail.com"
              type="cite"> From this position it looks just an
              optimization technique. And if we do this:<br>
              <br>
              var myEval = eval;<br>
              myEval("var x = 10;");<br>
              <br>
              we already can't inline the `eval` at parsing stage (?),
              right? And if we'd to pass the information about
              strictness of the surrounding context, we just should pass
              additional argument the `myEval`, yep? Though, I don't see
              which issue this passing of this additional argument can
              lead (which by the way?).<br>
              <br>
              <blockquote
                cite="mid:5DF81334-FA04-410C-8136-7644BFC8788F@wirfs-brock.com"
                type="cite">
                <div>
                  <div>
                    <div>A "direct eval" is essentially a special
                      syntactic from in the ES5 language with its own
                      specific semantics. Some people have talked about
                      it as the "eval" operator.  A direct eval does not
                      call the built-in eval function object.  Instead,
                      it has its own slightly different semantics that
                      can be directly implemented at the call site. </div>
                  </div>
                </div>
              </blockquote>
              <br>
              Yes, it was new for me (and for any JS dev I guess). And
              how it looks I tried to describe above (is that
              understanding is correct?).<br>
              <br>
              <blockquote
                cite="mid:5DF81334-FA04-410C-8136-7644BFC8788F@wirfs-brock.com"
                type="cite">
                <div>
                  <div>
                    <div> These semantics include access to the
                      immediately surrounding LexicalEnvironment and the
                      propagation of strictness into the eval code.</div>
                    <div><br>
                    </div>
                  </div>
                </div>
              </blockquote>
              <br>
              Yep, if to accept the inheriting of the strictness by the
              inner functions (with which I desugared the eval
              inlining).<br>
              <br>
              Thanks again, Allen, it seems clear now. But the main
              thing which I found out from it, is that _initially_ it's
              _not about JS-programming_, it's just an _optimization
              technique_ for the _implementers_.<br>
            </blockquote>
          </div>
        </blockquote>
        <blockquote type="cite">
          <div text="#000000" bgcolor="#ffffff">
            <blockquote cite="mid:4D5F0B11.4030908@gmail.com"
              type="cite"><br>
              Dmitry. <br>
              <br>
              <blockquote
                cite="mid:5DF81334-FA04-410C-8136-7644BFC8788F@wirfs-brock.com"
                type="cite">
                <div>
                  <div>
                    <div>Allen</div>
                    <div><br>
                    </div>
                    <div><br>
                    </div>
                    <div>On Feb 18, 2011, at 4:52 AM, Dmitry A.
                      Soshnikov wrote:</div>
                    <br class="Apple-interchange-newline">
                    <blockquote type="cite">
                      <div text="#000000" bgcolor="#ffffff"> Have no
                        idea what with mail sever again, there is no
                        this message there (links in message?). The
                        original question is below:<br>
                        <br>
                        On 18.02.2011 11:51, Dmitry A. Soshnikov wrote:
                        <blockquote
                          cite="mid:4D5E32FA.5000200@gmail.com"
                          type="cite"> Hello,<br>
                          <br>
                          As is known, indirect `eval` evaluates in the
                          global context (this note is not for the TC-39
                          group of course, but for all other who read
                          this list). But what is the big rationale of
                          that indirect eval is allowed to create a
                          global binding even _regardless_ the fact that
                          the global code is _strict_?<br>
                          <br>
                          I.e.:<br>
                          <br>
                          "use strict";<br>
                          <br>
                          eval("var x = 10;"); // direct<br>
                          this.eval("var y = 20;"); // indirect<br>
                          <br>
                          console.log(typeof x, typeof y); //
                          "undefined", "number"<br>
                          <br>
                          The only _practical_ rationale of the indirect
                          `eval` regarding the strict mode is that via
                          its call it's possible to get the global
                          object via `this` value from any place (since
                          just returning `this` won't work as it's set
                          to `undefined` in a simple function call):<br>
                          <br>
                          var global = (function () { return this; })();
                          // ES3, non-strict ES5 way<br>
                          <br>
                          var global = ("indirect", eval)("this"); //
                          strict ES5<br>
                          <br>
                          Which else practical/theoretical/academical
                          rationales of the indirect eval are? And what
                          again the rationale that it's allowed to
                          create the global binding (i.e. not in the
                          "sandbox" environment, but reusing
                          `VariableEnvironment` of the "caller" -- not a
                          direct caller though, but the adjusted -- the
                          global scope)? Could you clarify this, I want
                          to give a more concrete explanations for my
                          readers. <br>
                          <br>
                          P.S.:<br>
                          <br>
                          Just recently Allen brought a good addition
                          (well, a reminder even better to say, since I
                          also wanted to add it ;) to mention this
                          subtle case with indirect eval and it's
                          ability to affect the global environment
                          regardless the strict mode: <a
                            moz-do-not-send="true"
                            class="moz-txt-link-freetext"
href="http://dmitrysoshnikov.com/ecmascript/es5-chapter-2-strict-mode/#comment-5831">http://dmitrysoshnikov.com/ecmascript/es5-chapter-2-strict-mode/#comment-5831</a><br>
                          <br>
                          It's without doubts a very needed addition and
                          as is said -- a subtle case, but still -- what
                          are the exact rationales for that? I mentioned
                          this case in Allen's blog before, and though
                          that this is a bug of the spec -- <a
                            moz-do-not-send="true"
                            class="moz-txt-link-freetext"
                            href="http://www.wirfs-brock.com/allen/posts/39#comment-46">http://www.wirfs-brock.com/allen/posts/39#comment-46</a><br>
                          <br>
                          Allen answered that this is related with
                          complexity of implementation, here:<br>
                          <br>
                          "An <em>indirect</em> eval called from strict
                          code is strict only if the eval code explicit
                          contains an “use strict;” directive. It does
                          not “inherit” the strictness of its caller.
                          <p>Every call is potentially an indirect eval
                            call. If the strictness of indirect evals
                            depended upon the strictness of the caller
                            then we would have to pass the strictness of
                            the caller through every call. That would
                            require either an extra implicit parameter
                            on every call or the ability to a callee to
                            examine the call stack to to determine the
                            strictness of its caller. We don’t want to
                            force this on implementations."</p>
                          The basic idea is seems clear -- we need to
                          pass a flag that the code of an inner function
                          (from which indirect `eval` was called) is
                          strict, but if the _global_ code is strict --
                          and indirect `eval` always evaluates in the
                          global context, and moreover, if the global
                          code is strict that means _any_ inner function
                          (except those which are created via `Function`
                          constructor and have no own strictness) is
                          automatically also strict:<br>
                          <br>
                          "use strict";<br>
                          <br>
                          (function foo() {<br>
                            // this code is also strict<br>
                            ("indirect", eval)("var x = 10;");<br>
                          })();<br>
                          <br>
                          console.log(x); // 10<br>
                          <br>
                          is it also required to pass special flags to
                          handle this case?<br>
                          <br>
                          Thanks,<br>
                          Dmitry.<br>
                        </blockquote>
                        <br>
                      </div>
                      _______________________________________________<br>
                      es-discuss mailing list<br>
                      <a moz-do-not-send="true"
                        href="mailto:es-discuss@mozilla.org">es-discuss@mozilla.org</a><br>
                      <a moz-do-not-send="true"
                        class="moz-txt-link-freetext"
                        href="https://mail.mozilla.org/listinfo/es-discuss">https://mail.mozilla.org/listinfo/es-discuss</a><br>
                    </blockquote>
                  </div>
                  <br>
                </div>
              </blockquote>
              <br>
            </blockquote>
            <br>
          </div>
        </blockquote>
      </div>
      <br>
    </blockquote>
    <br>
  </body>
</html>