Fwd: Hermetic Evaluation, Modules Strawman
kris.kowal at cixar.com
Wed Sep 30 12:45:53 PDT 2009
Sorry, used to google groups, where reply is implicitly reply-all.
Here's my response to Charles:
---------- Forwarded message ----------
From: Kris Kowal <kris.kowal at cixar.com>
Date: Wed, Sep 30, 2009 at 12:45 PM
Subject: Re: Hermetic Evaluation, Modules Strawman
To: Charles Jolley <charles at sproutit.com>
On Wed, Sep 30, 2009 at 10:20 AM, Charles Jolley <charles at sproutit.com> wrote:
> You can tell me why this module design relies on eval'ing a string? It
> would be nice to be able to pass a Function object also.
> I wonder if that might be better for performance also as an optimized
> implementation could potentially avoid re-parsing the JS. [Note: I haven't
> implemented this kind of code before so there might not be any gains to be
> had here...]
> I'm thinking of a case where you have a large-ish module where the cost of
> eval'ing is non-trivial.
Absolutely. The idea is that the proposed new eval.Module(names,
text) case would be analogous to a Function(names..., text)
constructor, which would give the implementation an opportunity to
compile the program, sharing the AST or byte code between invocations
of the Module.
However, the purpose is definitely to transform text into a reusable
component. The same purpose could potentially be achieved by
"reparenting" a function declaration, such that the closure's parent
scope reference is the hermetic, deeply frozen, primordial scope, but
that would break lexical analysis in odd ways. Free variables in the
function would become reference errors at call time.
More information about the es-discuss