Spawn proposal strawman

kevin curtis kevinc1846 at googlemail.com
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 [ast.plus, 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 mozilla.com> 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