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 <[email protected]> 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 > > _______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
