AST in JSON format

Oliver Hunt oliver at
Tue Dec 8 19:59:53 PST 2009

On Dec 8, 2009, at 7:30 PM, Breton Slivka wrote:

> On Wed, Dec 9, 2009 at 6:28 AM, Oliver Hunt <oliver at> wrote:
>> On Dec 8, 2009, at 2:18 AM, David-Sarah Hopwood wrote:
>>> Oliver Hunt wrote:
>> I have also yet to see an actual developer centric use case -- the most frequently repeated use cases seem to be analysis tools used to ensure code can be run on a standard ES implementation while essentially being a stricter subset of ES.  The developer scenario for that is "developer wishes to use 'safe' subset of ES", not "developer wants to perform their own analysis"
>> --Oliver
> Run time mashups? As a developer, I now have access in some browsers
> to a cross domain enabled getJSON method. Suppose I wanted to use that
> to retrieve a javascript program from another server (perhaps some
> kind of module repository), but since I don't trust external code, I
> want to validate it before I compile it to a JS function, or run it.
> This is, as you say, a code analysis task. However, in this case, the
> developer wants to ensure that someone else is using a safe subset of
> js, rather than as you put it, the developer simply wanting to ensure
> their own code is in the safe subset.
> Right now there are projects to do this (caja, adsafe), but to do a
> runtime check requires that the user download a full JS parser, and
> validator. If part of the parsing task was built into the browser,
> there would be less code to download, and the verification would run
> much faster. This has real implications for users and developers, and
> would enable new and novel uses for JS in a browser, and distributed
> code modules.

Providing an AST doesn't get you anything substantial here as the hard part of all this is validation, not parsing.  Realistically you would want the browser to be responsible for validation because it is able to do much more interesting forms of validation, there are in fact already multiple concepts being investigated by the whatwg to solve just this problem, without requiring js subsetting.  Especially given in the mashup scenario you don't just have JS, you have the DOM and html -- assuming you can completely separate html from the js, you're still fairly limited as your validation either prohibits any access to the dom or the validation can be circumvented.

> Perhaps most of this is possible with just a hermetic eval, or some
> kind of worker inspired api as crockford suggested once, however
> consider this:
> There is a nice function in js called map which takes a function. If
> that function could be guaranteed to have certain properties (such as
> being referentially transparent), then map could be safely broken up
> into parts and run in parallel, with perhaps a worker api
> implementation.  You could do that now, but it requires some degree of
> faith that the provided function doesn't do anything naughty. You
> would not be able to accept such a function from a user, or from an
> external server.

Serialisation doesn't get you anything here -- you would have to do a large amount of validation, and then in the end you would need to manually spawn workers.  Realistically there's nothing stopping a browser from doing so itself in the first place, and it would be able to do so more efficiently than an end developer could (and end developer is limited to workers, which are only a dom level tech, messaging between workers requires copying, etc, etc otoh an engine can relatively trivially track referential transparency of a function, both as a standalone function, and with the constraints of the input elements, and is able to ignore threading restrictions that apply to actual ES code).


More information about the es-discuss mailing list