[Caja] Open Templates in ES3.1 strict (was: Refactoring out unused material)

# Mike Samuel (17 years ago)

2008/6/16 Mark S. Miller <erights at google.com>:

On Mon, Jun 16, 2008 at 8:01 PM, Mike Samuel <mikesamuel at gmail.com> wrote:

Will the open template stuff [< google-caja.googlecode.com/svn/changes/mikesamuel/string-interpolation-29-Jan-2008/trunk/src/js/com/google/caja/interp/index.html>] work in ES3.1 strict mode?

It looks like they will, but "open" will need to be spelled "eval", as is needed anyway for compatibility with ES3 and today's browsers.

As Lars was working on ES4 strict, he noticed something interesting about the eval operator: All the problematic interactions between eval and strict mode had to do with adding (or removing) bindings from the invoking scope. So long as the strict eval operator is limited to only consuming bindings from its invoking scope, and all occurrences of the strict eval operator are spelled "eval", all strict code remains statically scoped. (Leaving aside a current ES4-only controversy regarding the resurrection of "with".) For purposes of scope analysis, an occurrence of the eval operator should conservatively be treated as a use occurrence of all variables in scope at that point.

From my reading of ES4, the eval operator works that way, and the eval

function works like (new Function (textToEval))(). Is that correct? Is there no way to supply an environment to resolve free variables in textToEval?

2008/6/16 Mark S. Miller <erights at google.com>:

>
> On Mon, Jun 16, 2008 at 8:01 PM, Mike Samuel <mikesamuel at gmail.com> wrote:
> > Will the open template stuff [<
> http://google-caja.googlecode.com/svn/changes/mikesamuel/string-interpolation-29-Jan-2008/trunk/src/js/com/google/caja/interp/index.html>]
> work in ES3.1 strict mode?
>
>
> It looks like they will, but "open" will need to be spelled "eval", as
> is needed anyway for compatibility with ES3 and today's browsers.
>
> As Lars was working on ES4 strict, he noticed something interesting
> about the eval operator: All the problematic interactions between eval
> and strict mode had to do with adding (or removing) bindings from the
> invoking scope. So long as the strict eval operator is limited to only
> consuming bindings from its invoking scope, and all occurrences of the
> strict eval operator are spelled "eval", all strict code remains
> statically scoped. (Leaving aside a current ES4-only controversy
> regarding the resurrection of "with".) For purposes of scope analysis,
> an occurrence of the eval operator should conservatively be treated as
> a use occurrence of all variables in scope at that point.
>

>From my reading of ES4, the eval operator works that way, and the eval
function works like (new Function (textToEval))().  Is that correct?
Is there no way to supply an environment to resolve free variables in
textToEval?



>
> When Lars first suggested it, I was outraged. Then I realized he was
> right. We are adopting this notion of the strict eval operator into
> ES3.1 strict.
>
>
> --
>    Cheers,
>    --MarkM
>
> --~--~---------~--~----~------------~-------~--~----~
> You received this message because you are subscribed to
> http://groups.google.com/group/google-caja-discuss
> To unsubscribe, email google-caja-discuss-unsubscribe at googlegroups.com
> -~----------~----~----~----~------~----~------~--~---
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.mozilla.org/pipermail/es-discuss/attachments/20080616/2f4c7b51/attachment-0002.html

# ihab.awad at gmail.com (17 years ago)

On Mon, Jun 16, 2008 at 8:28 PM, Mike Samuel <mikesamuel at gmail.com> wrote:

Is there no way to supply an environment to resolve free variables in textToEval?

Fwiw, is that needed for eval(Template())? My understanding is that, in either case, free variables are pulled from the local scope, which works in the literal Function ctor case.

Ihab

On Mon, Jun 16, 2008 at 8:28 PM, Mike Samuel <mikesamuel at gmail.com> wrote:

> Is there no way to supply an environment to resolve free variables in
> textToEval?
>

Fwiw, is that needed for eval(Template())? My understanding is that, in
either case, free variables are pulled from the local scope, which works in
the literal Function ctor case.

Ihab

-- 
Ihab A.B. Awad, Palo Alto, CA
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.mozilla.org/pipermail/es-discuss/attachments/20080616/2f2834ce/attachment-0002.html

# Brendan Eich (17 years ago)

On Jun 16, 2008, at 8:28 PM, Mike Samuel wrote:

From my reading of ES4, the eval operator works that way, and the
eval function works like (new Function (textToEval))(). Is that
correct?

The latter (eval function, called indirectly, e.g.) is detectably
different: var bindings at top level in the textToEval do not persist
in the global object, but make local variables in the new Function.

Is there no way to supply an environment to resolve free variables
in textToEval?

The usual way to do this is to wrap the eval call in a function whose
arguments name the free variable, and return the result. The usual
shared prototype and global mutation hazard warnings apply, but any
var bindings in the program will be confined.

On Jun 16, 2008, at 8:28 PM, Mike Samuel wrote:

> From my reading of ES4, the eval operator works that way, and the  
> eval function works like (new Function (textToEval))().  Is that  
> correct?

The latter (eval function, called indirectly, e.g.) is detectably  
different: var bindings at top level in the textToEval do not persist  
in the global object, but make local variables in the new Function.

> Is there no way to supply an environment to resolve free variables  
> in textToEval?

The usual way to do this is to wrap the eval call in a function whose  
arguments name the free variable, and return the result. The usual  
shared prototype and global mutation hazard warnings apply, but any  
var bindings in the program will be confined.

/be