Databases
StackOverflow2013
Postsdbo
PO
 

Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <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>
    singulars
    1. This table or related slice is empty.
    1. POLeft-factoring grammar of coffeescript expressions
      singulars
      1. PTQuestion
    1. PTAnswer
    1. USBart Kiers
    1. USBart Kiers
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. POLeft-factoring grammar of coffeescript expressions
      singulars
      1. PTQuestion
    1. This table or related slice is empty.
    1. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    2. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTAcceptedByOriginator
    3. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    1. COYour explanation about the error messages and the parser paths helped me a lot understanding the problem and made the cryptic-looking Antlr messages more meaningful. wrt to your comments on the grammar, I'm not interested in the lexer part yet (see my update). I still find your first comment useful, I wasn't aware of that.
      singulars
      1. PO
      1. USAdam Schmideg
    2. CO@Adam, I guessed your grammar had the ambiguity, but I was wrong: CoffeeScript is full of ambiguities! It appears a single identifier is a valid statement (as an implicit return value) causing the parser to possibly parse a single identifier as a return-statement, the start of an assignment, or a function-call (to name just 3 possibilities). It's a horrible language to parse, but after playing around with it a bit, it does make JavaScript so much more fun! A cute little language to work with! Really nice.
      singulars
      1. PO
      1. USBart Kiers
    3. CO@AdamSchmideg, a final word of caution: I also see that input like `f 1 + f 2` is valid and should be interpreted as `f(1 + f(2))`. An LR parser which matches input from right to left will have little trouble with this, but trying to do so with an LL parser, will get clunky. But there are many more things in the original CoffeeScript grammar that won't work: left recursion in the LR grammar won't work at all in the LL grammar, for example. I'm sure it's not impossible, but it's going to get tough to write a decent CoffeeScript grammar in ANTLR syntax. Best of luck, of course!
      singulars
      1. PO
      1. USBart Kiers
 

Querying!

 
Guidance
A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.

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