Are there 2 approaches to adding AST functionality in ecmascript:
1) The AST as JSON
Either Brendan's original example or the S-expression-ish jsonml.
This covers both the in memory representation of the AST and its
serialization format.
2) API
Similar to the ast module in python where multiple api calls build the
AST nodes.
>From the python doc:
For example, to create and populate an ast.UnaryOp node, you could use
node = ast.UnaryOp(ast.USub(), ast.Num(5, lineno=0, col_offset=0),
lineno=0, col_offset=0)
---
The ecmascript AST+ api would wrap the c/c++ parsing/ast api in the
ecmascript engines implementation. Thus the AST in memory
representation will be whatever spidermonkey, v8 etc use. The
serialization/pretty print format may or may not be json. Could be
xml. Or even something more scheme-y e.g
(or x (or y z))
Maybe the api could have a jquery-ish feel.
3) Or even Both
- A api function which takes a json tree and then calls
- the individual api ast builder functions - which are also available
On Sat, May 9, 2009 at 10:50 PM, Brendan Eich <[email protected]> wrote:
> On May 9, 2009, at 2:32 PM, David-Sarah Hopwood wrote:
>
>> I would mildly prefer to use an S-expression-style AST, like this:
>>
>> ["||",
>> ["||",
>> ["Id", "X"],
>> ["Id", "Y"]],
>> ["Id", "Z"]]
>>
>> which is more concise, does not lose any useful information, and
>> is easier to remember. This is the same style as used in JsonML
>> (www.jsonml.org).
>
> Not bad. I will give it a try in the prototype I've started. Thanks for the
> pointer.
>
>
>> It so happens that this is *semantically* equivalent to "a || (b || c)",
>> but that is not an equivalence of abstract syntax.
>
> I know, that's my point. The connectives can be parsed and evaluated either
> way, but the short-circuiting seems to favor right associativity, on one
> hand.
>
> On the other hand, I'm defying a long tradition here. The precedent going
> back to C (K&R before ANSI got in the loop; ignore Algol and BCPL precedents
> ;-) uses left associativity, and ES1 followed suit.
>
> So this is not a big deal, and it would be quixotic of me to make too much
> of it :-). I wanted to raise it as a potential issue. It's a practical issue
> in SpiderMonkey since we do right-associate || and && in the internal syntax
> tree.
>
> /be
> _______________________________________________
> es-discuss mailing list
> [email protected]
> https://mail.mozilla.org/listinfo/es-discuss
>
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
