Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p>When you generate a lexer and parser from your grammar, you see the following error printed to your console:</p> <blockquote> <p>error(211): CoffeeScript.g:52:3: [fatal] <strong><em>rule expression</em></strong> has non-LL(*) decision due to recursive rule invocations reachable from alts 1,3. Resolve by left-factoring or using syntactic predicates or using backtrack=true option.</p> <p>warning(200): CoffeeScript.g:52:3: <strong><em>Decision can match input such as "{NUMBER, STRING}" using multiple alternatives: 1, 3</em></strong></p> <p>As a result, <strong><em>alternative(s) 3 were disabled</em></strong> for that input</p> </blockquote> <p><em>(I've emphasized the important bits)</em></p> <p>This is only the first error, but you start with the first and with a bit of luck, the errors below that first one will also disappear when you fix the first one.</p> <p>The error posted above means that when you're trying to parse either a <code>NUMBER</code> or a <code>STRING</code> with the parser generated from your grammar, the parser can go two ways when it ends up in the <code>expression</code> rule:</p> <pre>expression : value // choice 1 | assign // choice 2 | operation // choice 3 ;</pre> <p>Namely, choice 1 and choice 3 both can parse a <code>NUMBER</code> or a <code>STRING</code>, as you can see by the "paths" the parser can follow to match these 2 choices:</p> <h3>choice 1:</h3> <pre>expression value literal alphaNumeric : {NUMBER, STRING}</pre> <h3>choice 3:</h3> <pre>expression operation logicOp relationOp shiftOp additiveOp mathOp questionOp term value literal alphaNumeric : {NUMBER, STRING}</pre> <p>In the last part of the warning, ANTLR informs you that it ignores choice 3 whenever either a <code>NUMBER</code> or a <code>STRING</code> will be parsed, causing choice 1 to match such input (since it is defined before choice 3).</p> <p>So, either the CoffeeScript grammar is ambiguous in this respect (and handles this ambiguity somehow), or your implementation of it is wrong (I'm guessing the latter :)). You need to fix this ambiguity in your grammar: i.e. don't let the <code>expression</code>'s choices 1 and 3 both match the same input.</p> <hr> <p>I noticed 3 other things in your grammar:</p> <h2>1</h2> <p>Take the following lexer rules:</p> <pre>NEW : 'new'; ... UNARY : '!' | '~' | NEW;</pre> <p>Be aware that the token <code>UNARY</code> can never match the text <code>'new'</code> since the token <code>NEW</code> is defined before it. If you want to let <code>UNARY</code> macth this, remove the <code>NEW</code> rule and do:</p> <pre>UNARY : '!' | '~' | 'new';</pre> <h2>2</h2> <p>In may occasions, you're collecting multiple types of tokens in a single one, like <code>LOGIC</code>:</p> <pre>LOGIC : '&&' | '||';</pre> <p>and then you use that token in a parser rules like this:</p> <pre>logicOp : compareOp (LOGIC compareOp)* ;</pre> <p>But if you're going to evaluate such an expression at a later stage, you don't know what this <code>LOGIC</code> token matched (<code>'&amp;&amp;'</code> or <code>'||'</code>) and you'll have to inspect the token's inner text to find that out. You'd better do something like this (at least, if you're doing some sort of evaluating at a later stage):</p> <pre>AND : '&&'; OR : '||'; ... logicOp : compareOp ( AND compareOp // easier to evaluate, you know it's an AND expression | OR compareOp // easier to evaluate, you know it's an OR expression )* ;</pre> <h2>3</h2> <p>You're skipping white spaces (and no tabs?) with:</p> <pre>WS : (' ')+ {skip();} ;</pre> <p>but doesn't CoffeeScript indent it's code block with spaces (and tabs) just like Python? But perhaps you're going to do that in a later stage?</p> <hr> <p>I just saw that <a href="http://jashkenas.github.com/coffee-script/documentation/docs/grammar.html" rel="nofollow">the grammar you're looking at</a> is a jison grammar (which is more or less a bison implementation in JavaScript). But bison, and therefor jison, generates <a href="http://en.wikipedia.org/wiki/LR_parser" rel="nofollow">LR parsers</a> while ANTLR generates <a href="http://en.wikipedia.org/wiki/LL_parser" rel="nofollow">LL parsers</a>. So trying to stay close to the rules of the original grammar will only result in more problems.</p>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload