On Thu, Oct 14, 2010 at 8:57 AM, David Herman <dher...@mozilla.com> wrote:
> > Given <script type="harmony"> as an opt-in, I'm puzzled about how it
> would work anyway. Since it is per script, not per frame, presumably
> >
> > <script type="harmony">"use strict"; var e1 = eval;</script>
> > <script>"use strict"; var e2 = eval;</script>
> > <script ...>"use strict"; e1 === e2 /*results in true*/ </script>
>
> That's not quite right, at least according to the simple modules design.
> But it's my fault for not spelling it out clearly enough in the strawman. In
> particular:
>
> - Harmony scripts would not have the legacy global object as a record in
> their scope chain
> - Harmony eval retains the same value and behavior as ES5-strict eval,
> i.e., it evaluates its code as legacy code, not as Harmony code.
>
> Both of these are open to discussion, of course, but I offer them at least
> as counter-evidence to your implication that there's no answer to the
> versioning question other than eliminating modes.
>
I can we why it seems that I was implying that, but I'm making more modular
arguments than that. In any case, thanks for the clarification.
This issue *by itself* suggests that a harmony opt-in should be managed by a
prologue / pragma at the beginning of a Program production[1], rather than
an attribute on a script tag, so it can follow the same opt-in logic as "use
strict" and apply to eval code as well. Thus,
e2(' "use harmony"; var module = 1');
could be illegal on browsers supporting harmony. And such evaled code would
also not have the global object at the bottom of their scope chain. This
in-language switch makes more sense to me than a markup-based switch such as
<script ...>, and would allow the switch to be recognized in non-browser
environments such as commonjs.
I will address the more general "more modes" and compatibility direction
questions for later messages.
[1] And possibly other productions like FunctionBody, as 'use strict'; does.
For symmetry, I think perhaps it should. But the point above by itself only
argues that it need be recognized at the beginning of a Program production.
OTOH, recognizing it in a nested production likely raises scoping issues
we'd like to avoid, which argues against the symmetric generalization.
> The invariants of Harmony do *not* rely on not interacting with legacy
> code. You still get lexical scope, and ES5-strict eval is sufficient for
> that purpose. (When you run eval, of course, you're running code in a
> language that doesn't have full lexical scope.)
>
> > In other words, that both harmony and non harmony code on the same page
> have the same binding for the global "eval" function. In that case, what
> does the following code do:
> >
> > e2(' "use strict"; var module = 8;');
> >
> > This is currently legal es5/strict code. As suggested by the modules
> strawman, it is not legal harmony code.
>
> It's perfectly legal. It's an indirect eval, regardless of whether it's
> being called from ES5-strict or Harmony.
>
> > es5/strict and harmony share a heap.
>
> Yep, and that's fine.
>
> > I do not see a good answer.
>
> As you say, that's why it's worth discussing.
>
> Dave
>
>
--
Cheers,
--MarkM
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
