Eval-invisible let bindings
Lars Hansen
lhansen at adobe.com
Fri Dec 7 02:06:27 PST 2007
> -----Original Message-----
> From: es4-discuss-bounces at mozilla.org
> [mailto:es4-discuss-bounces at mozilla.org] On Behalf Of Thomas Reilly
> Sent: 7. desember 2007 01:16
>
>
> Don't you have to do scope chain dance for function closures
> anyways or did I miss something? How is eval different from
> function closures?
I think Igor's point is that if let bindings are invisible to eval then
you can mostly boil them away at compile time to rib/offset pairs, no
names required. This does not change with closures, and clever
techniques for compiling "with" probably also does not require names to
be available. But eval does.
> The notion piques my curiousity though. We here at Adobe
> have large AS3 code bases where it is frowned upon to use
> function closures b/c local variable scope chain reference
> leaks have caused so much consternation. Having a way to
> hide variables from eval and function closures might be
> useful in that regard. I'm curious what the language folks
> think about it.
If the language does not provide safe-for-space guarantees then the
implementation is not doing anything wrong here, though it may be
considered to be of low quality, of course. To do better the
implementation might need to use closure representations that
incorporate a display (so that a function only closes over what it might
reference). That may in turn require heap-allocating individual
captured storage cells in order to avoid capturing entire rib objects,
which in its turn may cause overall slowdowns in code that does use
closures.
On the web there may also be an issue with needing to know the defining
global environment of a function in order to perform a security check;
that will itself prevent global environments from being
garbage-collected while any functions created in that environment are
still live. (One can probably imagine other mechanisms for that
functionality.)
> I guarantee these types of reference leaks
> will be high on the list of very bad bugs written by Java
> programmer turned ES4 programmer using function closures w/o
> realizing that they are doing. In fact I can already see the
> Slashdot posting "ES4 memory leak crashes University X's
> autonomous vehicle".
I doubt ES4 will provide the necessary safe-for-space guarantees to
prevent this (though ES3 programmers are the more likely culprits IMO
:-)
--lars
> -----Original Message-----
> From: es4-discuss-bounces at mozilla.org on behalf of Igor Bukanov
> Sent: Wed 12/5/2007 2:52 PM
> To: es4-discuss at mozilla.org
> Subject: Eval-invisible let bindings
>
> Hi,
>
> Currently ES4 allows to access from eval scripts the names
> introduced by the let statements and expressions. It leads to
> implementation complexity since the let bindings cannot be
> implemented as a pure compilation-time feature and the
> runtime must be able to expose the names for eval scripts.
>
> Thus I suggest to consider making let bindings invisible to
> the eval scripts. That is, the idea is to exclude any
> let-induced name from the scope chain passed to the eval
> script. For example, given:
>
> let a;
> function f(b) {
> var c;
> let d;
> eval(eval_source);
> }
>
> the script from eval_source when executed would not see a and
> d and would be able to access/modify only b and c.
>
> This not only simplifies implementations, but would also give
> a possibility to prevent eval-injections from discovering the
> internal state of a closure as long as the closure uses let
> for its internal state. Although ES4 mitigates that with
> restrictions on the indirect eval, for compatibility
> implementations may be forced to support it.
>
> Regards, Igor
> _______________________________________________
> Es4-discuss mailing list
> Es4-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es4-discuss
>
> _______________________________________________
> Es4-discuss mailing list
> Es4-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es4-discuss
>
More information about the Es4-discuss
mailing list