Impliment MDV Syntax expressions

Impliment MDV Syntax expressions

Hey,

This patch implements all the expression support we discussed with the exception of function invocation. This includes:

Unary +, -
Binary +, -, *, /, %
Relational <, >, <=, >=
Equality ==, !=, ===, !==
Logical &&, ||
Logical !
Conditional (e.g. foo ? bat : bar)
Literals (e.g. 1, 'foo', null)

Note that this takes a dependency on esprima which is BSD licensed.

R=arv
BUG=

Committed: https://github.com/Polymer/mdv/commit/63e8fad

[rafaelw, 2013-06-06 19:18:00]

Committed patchset #6 manually as r63e8fad (presubmit successful).

[arv, 2013-06-07 16:03:40]

It is kind of unfortunate to have to support parsing full ES5 when all we care
about is a subset of Expresssion. Still we can refactor away ESPrima if this
ever becomes an in issue.

What about: expr[expr]? I didn't see that being handled.

I'm also not sure how you are using the labeledStatements and why there is
special code for them.

https://codereview.appspot.com/9994043/diff/15001/src/mdv_syntax.js
File src/mdv_syntax.js (right):

https://codereview.appspot.com/9994043/diff/15001/src/mdv_syntax.js#newcode140
src/mdv_syntax.js:140: esprima.parse(expressionText, delegate);
Does esprima have a more specific parse function? We need to parse this as an
Expression and not as a Program.

We should wrap this in parens since we only accept a single expression.

https://codereview.appspot.com/9994043/diff/15001/src/mdv_syntax.js#newcode146
src/mdv_syntax.js:146: throw Error('Expression must be a single statement');
This is pretty backwards. An expression is never a statement. What you really
mean here is that we only accept a single Expression.

https://codereview.appspot.com/9994043/diff/15001/src/mdv_syntax.js#newcode148
src/mdv_syntax.js:148: var resolveFn = delegate.labeledStatements.length ?
It is unclear how you intend to use labeledStatements?

https://codereview.appspot.com/9994043/diff/15001/src/mdv_syntax.js#newcode161
src/mdv_syntax.js:161: for (var i = 0; i < paths.length; i++)
{}

https://codereview.appspot.com/9994043/diff/15001/tests/mdv_syntax.js
File tests/mdv_syntax.js (right):

https://codereview.appspot.com/9994043/diff/15001/tests/mdv_syntax.js#newcode203
tests/mdv_syntax.js:203: '{{ (a.b + c.d)/e - (f * g.h) }}' +
maybe remove the second set of parens to ensure specificity is correct

[rafaelw, 2013-06-07 21:07:50]

https://codereview.appspot.com/9994043/diff/15001/src/mdv_syntax.js
File src/mdv_syntax.js (right):

https://codereview.appspot.com/9994043/diff/15001/src/mdv_syntax.js#newcode140
src/mdv_syntax.js:140: esprima.parse(expressionText, delegate);
Per offline discussion, we can't wrap in parens because we need to support
multiple labelled statements.

On 2013/06/07 16:03:41, arv wrote:
> Does esprima have a more specific parse function? We need to parse this as an
> Expression and not as a Program.
> 
> We should wrap this in parens since we only accept a single expression.

https://codereview.appspot.com/9994043/diff/15001/src/mdv_syntax.js#newcode146
src/mdv_syntax.js:146: throw Error('Expression must be a single statement');
On 2013/06/07 16:03:41, arv wrote:
> This is pretty backwards. An expression is never a statement. What you really
> mean here is that we only accept a single Expression.

Done.

https://codereview.appspot.com/9994043/diff/15001/src/mdv_syntax.js#newcode148
src/mdv_syntax.js:148: var resolveFn = delegate.labeledStatements.length ?
Added comment.

On 2013/06/07 16:03:41, arv wrote:
> It is unclear how you intend to use labeledStatements?

https://codereview.appspot.com/9994043/diff/15001/src/mdv_syntax.js#newcode161
src/mdv_syntax.js:161: for (var i = 0; i < paths.length; i++)
On 2013/06/07 16:03:41, arv wrote:
> {}

Done.

https://codereview.appspot.com/9994043/diff/15001/tests/mdv_syntax.js
File tests/mdv_syntax.js (right):

https://codereview.appspot.com/9994043/diff/15001/tests/mdv_syntax.js#newcode203
tests/mdv_syntax.js:203: '{{ (a.b + c.d)/e - (f * g.h) }}' +
On 2013/06/07 16:03:41, arv wrote:
> maybe remove the second set of parens to ensure specificity is correct

Done.