Spawn proposal strawman

kevin curtis kevinc1846 at
Tue May 12 01:44:48 PDT 2009

Just an idea -  () seems natural for AST's. jsonML is more than good.

I am _definitely_ not suggesting building a jsonML object graph if the
programmer does not require it. eg sax vs dom.

Is your approach:

// jsonML AST string
var js_str = "2 + 2"
var jsonML_ast_str = eval.parse(js_str)
print(jsonML_ast_str) // ["+", 2, 2] or [, 2, 2]
var res = eval.execute(jsonML_ast_str)
print(res) // 4

// if the programmer wants to manipulate the jsonML AST in memory
var js_lst = ["+", 2]
js_lst[2] = 2
var jsonML_ast_str = JSON.stringify(js_lst)
... then same as above

The eval.execute function (implemented in c/c++) would take the
jsonML_ast_str and build the native c/c++ ast tree. Which is then
walked to generate bytecode (and maybe machine code) for execution.

In the original code snippet which prompted the discussion:
eval.hermetic(program :(string | AST), thisValue, optBindings) :any

I wasn't sure if the AST type meant a string (in jsonML) or a
reference to the native AST object (in c++) which could be be
manipulated via an api.

On Tue, May 12, 2009 at 8:31 AM, Brendan Eich <brendan at> wrote:
> On May 12, 2009, at 12:24 AM, kevin curtis wrote:
>> JsonML looks good for for an AST handling:
>> ["||",
>>  ["||",
>>    ["Id", "X"],
>>    ["Id", "Y"]],
>>  ["Id", "Z"]]
> Yes.
>> Maybe the 'canonical' AST serialized string format could actually be
>> more scheme-y:
>> (or (or X Y) Z)
>> JsonML could be used for building pure js in-memory AST graphs which
>> could then be easily stringified to the 'canonical' format.
> JsonML wouldn't be used to build object graphs -- the JSON decoder would do
> that given JsonML in a string, from the AST encoder. That's the point I made
> in the words you bottom-cite about not mandating a big fat object graph if
> the use-case doesn't need the graph, just the string containing the AST
> serialization.
>> The benefit is that a scheme-y format could help the thinking on the
>> semantics for es6/harmony.
> That seems like no benefit in memory use or cycles, only in thinking. If you
> squint, don't the []s turn into ()s? :-P
>> (Downside compared to a JSON  canonical format is that with JSON the
>> parsing/stringifying is free via the JSON api in es5).
> This is a big downside.
>> For convenience JSON could remain JSON in this scheme-y format:
>> var x = [1,4,5]
>> becomes:
>> (var x [1,4,5])
> I don't see why we'd invent a third language.
> /be

More information about the es-discuss mailing list