I am trying to do something that seems pretty simple, which is adjusting the
root token of a tree in my tree parser.
Basically my parser always sees a=b as a comparison and generates ^( EQUAL a
b) as an AST, and in the tree parser I want to adjust that to ^( ASSIGN a b)
if I am at the statement
My parser grammar can generate a number of subtrees with similar structure,
and just a different root type. In the tree grammar I am trying to just pass
such a subtree along without any changes, but that is turning out to be much
trickier than I expected, am I missing something?
Given this AST:
Christian wrote
Hi,
what is the error/exception message?
Regards,
Christian
MissingTokenException at the second '=', after parsing a=b.c as an
expression. The tail recursion on expr is causing it it seems, but that's a
real issue for me... here is a slightly modified version with
None of those suggestion will help with the actual grammar unfortunately. It
is indeed ambiguous, that is the warning I get if I turn backtracking off,
but I can't refactor the rules (or the actual, large grammar) w/o ending
with a completely meaningless AST.
I still don't understand why antlr
Thanks John,
I had tried the first one (using a label assigned in each branch of the
alternative), I just posted it wrong.
Your 2nd 3rd suggestions should work I expect, thanks!
Too bad the most natural one ^( ( AND | OR ) ... w/o rewrite doesn't work...
--
View this message in context:
In fact the tree has been constructed by the leading (ID-ID), and that
parameter being a tree is exactly why I gave up on hoisting. I am sure it
can be made to work but getting the typing right was a pain.
So here is exactly what I am trying to do, there is probably a better way
than what I have
Bart Kiers wrote
On Sat, Nov 26, 2011 at 9:58 AM, franck102 franck102@ wrote:
In fact the tree has been constructed by the leading (ID-ID),
That tree only exists inside your parenthesis, AFAIK. You can't reference
it outside it (well, you can, but it will be `null`).
This seems
I think I am missing something fundamental about backtracking. The grammar
below won't parse input such as
a=b.
c=d;
... even though I would expect it to backtrack after realizing that a=b.c
leads to a dead-end. What am I missing?
Thanks!
PS: I am not looking for refactoring options, I have
I am trying to match multi-word keywords at the lexer level, I found the
pattern below in previous answers but I can't figure out how to make the
type assigned to $type visible to parser rules... any suggestion
appreciated!
I would rather not modify containOperator to get at the token type, this
The grammar below won't compile, this looks like a bug to me? It seems that
the syntactic predicate automatically generated by the backtrack option
includes the rule parameter but doesn't have a declaration for it.
The error I get is:
[08:49:44] 1 error
[08:50:01]
Hi, I am new to grammar design and I am still struggling with understanding
non LL(*) errors.
In the example below I do understand that call f using 1, 2 is ambiguous,
which I am trying to address with the greedy option, but I still get a fatal
error trying to compile the grammar.
I am looking
Made some progress after lots of head scratching and re-reading the antlr
book:
1. I saw somewhere on a popular antlr web page that syntactic predicates
could only appear at the beginning of an alternative, this is inaccurate, in
fact my problem is solved by adding a predicate at the beginning of
call, but it must not trigger in the first
case because neither 2 or 3 are string literals...
Franck
From: Jim Idle [via ANTLR] ml-node+s1301665n7009129...@n2.nabble.com
To: franck102 franck...@yahoo.com
Sent: Friday, November 18, 2011 6:47 PM
Subject: Re
I am writing a grammar for a fairly complex expression language, and in
particular I need to support string concatenation which is performed simply
by separating string literals with a space; and which automatically converts
other expressions to a string if needed to concatenate:
a b - ab
2+3 mm -
to the string 33)
Franck
From: Bart Kiers [via ANTLR] ml-node+s1301665n7008016...@n2.nabble.com
To: franck102 franck...@yahoo.com
Sent: Friday, November 18, 2011 1:11 PM
Subject: Re: String concatenation expression rule
On Fri, Nov 18, 2011 at 12:39 PM
15 matches
Mail list logo
