On 7 November 2012 21:37, Peter van der Zee <e...@qfox.nl> wrote:
> How would you deal with cases like `foo(/)/);` and `foo(5//)/g);` ?
> So how would you deal with combinations of regular expressions and
> divisions in awkward places? Or are you already using a tokenizer and
> hardcoded rules on when to parse for regex/div?
The first stage I use is to assign a "left" value for example if an
expression occurs then I give it a value of true if not then false. If the
left value is false then it's a regex. Where it isn't as easy is when you
have var statements or need to know what a colon is. Is it a case colon or
label or ternary. I decided to hardcode the entire js syntax into a series
of very specific rules for example:
var rules = {
ArrayComma:createRule('NewExpressions,Expression,Postfix'),
ArrayOpen:createRule('Statements,Operators,NewExpressions,Prefix'),
ArrayClose:createRule('ArrayComma,ArrayOpen,Expression,Postfix'),
.....
The property name is the current state and the values are the previous
state. This allows you to control what certain statements do what they are
allowed to follow. I tokenize and parse simultaneously.
Both your cases are invalid javascript in the browser. So they will never
reach the MentalJS parser because I do a syntax check in the browser first
before passing it to MentalJS. However if I turn off this check here is how
Mental JS parses `foo(/)/);`
<Identifier>$foo$</Identifier><FunctionCallOpen>(</FunctionCallOpen><RegExp>/)/</RegExp><FunctionCallClose>)</FunctionCallClose><EndStatement>;</EndStatement>
I could fix your invalid syntax automatically in the regex state machine by
rewriting /)/ to /\)/ and then it would execute :)
The second example would fail mental js syntax check because the comment
removes the paren and so the opening and closing parens are uneven which
will result nicely in a syntax error.
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
