[il-antlr-interest: 35035] [antlr-interest] Changing the root of a tree in a tree parser
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 level:
statement
: ifStatement
| ...
| expressionStatement { if ($expressionStatement.tree.getType() ==
EQUALS) { set tree type to ASSIGN }
If I try to introduce an assignmentStatement (just in the tree parser) I get
mutually recursive rule, so that isn't an option...
Any suggestion?
--
View this message in context:
http://antlr.1301665.n2.nabble.com/Changing-the-root-of-a-tree-in-a-tree-parser-tp7038239p7038239.html
Sent from the ANTLR mailing list archive at Nabble.com.
List: http://www.antlr.org/mailman/listinfo/antlr-interest
Unsubscribe:
http://www.antlr.org/mailman/options/antlr-interest/your-email-address
--
You received this message because you are subscribed to the Google Groups
il-antlr-interest group.
To post to this group, send email to il-antlr-inter...@googlegroups.com.
To unsubscribe from this group, send email to
il-antlr-interest+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/il-antlr-interest?hl=en.
[il-antlr-interest: 35036] [antlr-interest] Tree building limitation in tree grammars?
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: ^( AND true false ) I want the tree grammar to generate the same AST subtree. The following attempts are not working: ^( ( AND | OR ) booleanExpression booleanExpression ) // no rewrite = flattens the tree, // I get a nil root and 3 children ^( ( root=AND | root=OR ) booleanExpression booleanExpression ) - ( ( AND | OR ) booleanExpression booleanExpression ) // syntax error ^( ( root=AND | root=OR ) booleanExpression booleanExpression ) - ( AND? OR? booleanExpression booleanExpression ) // syntax error ^( root=(AND | OR ) booleanExpression booleanExpression ) - ( $root booleanExpression booleanExpression ) // runtime error, $root is empty Am I going to have to split those rules?? Any suggestion appreciated! -- View this message in context: http://antlr.1301665.n2.nabble.com/Tree-building-limitation-in-tree-grammars-tp7038639p7038639.html Sent from the ANTLR mailing list archive at Nabble.com. List: http://www.antlr.org/mailman/listinfo/antlr-interest Unsubscribe: http://www.antlr.org/mailman/options/antlr-interest/your-email-address -- You received this message because you are subscribed to the Google Groups il-antlr-interest group. To post to this group, send email to il-antlr-inter...@googlegroups.com. To unsubscribe from this group, send email to il-antlr-interest+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/il-antlr-interest?hl=en.
[il-antlr-interest: 35039] Re: [antlr-interest] Confused about backtracking
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 the recursion made explicit that has the same problem: program : statement* EOF ; statement : ID '=' expr | sep ; expr : ID ( '.' expr )*; sep : ';' | '.'; -- View this message in context: http://antlr.1301665.n2.nabble.com/Confused-about-backtracking-tp7033712p7038881.html Sent from the ANTLR mailing list archive at Nabble.com. List: http://www.antlr.org/mailman/listinfo/antlr-interest Unsubscribe: http://www.antlr.org/mailman/options/antlr-interest/your-email-address -- You received this message because you are subscribed to the Google Groups il-antlr-interest group. To post to this group, send email to il-antlr-inter...@googlegroups.com. To unsubscribe from this group, send email to il-antlr-interest+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/il-antlr-interest?hl=en.
[il-antlr-interest: 35049] Re: [antlr-interest] Confused about backtracking
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 won't backtrack there, I suspect this is a limitation of the implementation strategy that uses predicates; or maybe I am expecting too much and the kind of backtracking required here would be too hard or expensive to implement? Basically I have an ambiguous but valid non left-recursive grammar, and I don't see why antlr after failing on one branch doesn't backtrack to try the other branch of the ambiguity. I do use the debugger, and it shows that the (automatically generated) syntactic predicate for expr passed ( DOT ^( EXPR c ) ) and that b.c was accepted as an expr, and the next node in the parse tree is the MissingTokenExpression at = (the parser expects a separator at that point). Replacing the '.' literal by an explicit DOT token doesn't make any difference. -- View this message in context: http://antlr.1301665.n2.nabble.com/Confused-about-backtracking-tp7033712p7039721.html Sent from the ANTLR mailing list archive at Nabble.com. List: http://www.antlr.org/mailman/listinfo/antlr-interest Unsubscribe: http://www.antlr.org/mailman/options/antlr-interest/your-email-address -- You received this message because you are subscribed to the Google Groups il-antlr-interest group. To post to this group, send email to il-antlr-inter...@googlegroups.com. To unsubscribe from this group, send email to il-antlr-interest+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/il-antlr-interest?hl=en.
[il-antlr-interest: 35051] Re: [antlr-interest] Tree building limitation in tree grammars?
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: http://antlr.1301665.n2.nabble.com/Tree-building-limitation-in-tree-grammars-tp7038639p7039835.html Sent from the ANTLR mailing list archive at Nabble.com. List: http://www.antlr.org/mailman/listinfo/antlr-interest Unsubscribe: http://www.antlr.org/mailman/options/antlr-interest/your-email-address -- You received this message because you are subscribed to the Google Groups il-antlr-interest group. To post to this group, send email to il-antlr-inter...@googlegroups.com. To unsubscribe from this group, send email to il-antlr-interest+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/il-antlr-interest?hl=en.
[il-antlr-interest: 35028] Re: [antlr-interest] Possible bug with backtrack-generated predicate methods
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 (untested pseudo-grammer, but you should get the idea): expr :( prefix - prefix ) ( suffix - /* *insert prefix as first child of suffix and return suffix * */ ) * prefix : ID; suffix :DOT ID - ^( DOT ID ) |'[' expr ']' - ^( INDEX expr ) I guess I could use a scope to pass down the prefix; or have suffix return both the root type and a flat list and build the tree in expr; but both seem painful to get right typing wise... Franck -- View this message in context: http://antlr.1301665.n2.nabble.com/Possible-bug-with-backtrack-generated-predicate-methods-tp7033324p7033439.html Sent from the ANTLR mailing list archive at Nabble.com. List: http://www.antlr.org/mailman/listinfo/antlr-interest Unsubscribe: http://www.antlr.org/mailman/options/antlr-interest/your-email-address -- You received this message because you are subscribed to the Google Groups il-antlr-interest group. To post to this group, send email to il-antlr-inter...@googlegroups.com. To unsubscribe from this group, send email to il-antlr-interest+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/il-antlr-interest?hl=en.
[il-antlr-interest: 35030] Re: [antlr-interest] Possible bug with backtrack-generated predicate methods
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 to work for me, I am referring to it using $expr. The rewrite in (ID-ID) sets the global tree afaik. -- View this message in context: http://antlr.1301665.n2.nabble.com/Possible-bug-with-backtrack-generated-predicate-methods-tp7033324p7033470.html Sent from the ANTLR mailing list archive at Nabble.com. List: http://www.antlr.org/mailman/listinfo/antlr-interest Unsubscribe: http://www.antlr.org/mailman/options/antlr-interest/your-email-address -- You received this message because you are subscribed to the Google Groups il-antlr-interest group. To post to this group, send email to il-antlr-inter...@googlegroups.com. To unsubscribe from this group, send email to il-antlr-interest+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/il-antlr-interest?hl=en.
[il-antlr-interest: 35031] [antlr-interest] Confused about backtracking
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 the issue in a complex
grammar that can't easily be refactored.
=
grammar Test;
options {
output=AST;
backtrack=true;
}
program
: statement* EOF
;
statement
: ID '=' expr
| sep
;
expr: ID suffix;
suffix : ( '.' expr )*
;
sep : ';' | '.';
// LEXER
// ==
ID
: ('a'..'z'|'A'..'Z'|'_') ('a'..'z'|'A'..'Z'|'0'..'9'|'_')*
;
WS : ( ' '
| '\t'
| '\r'
| '\n'
) {$channel=HIDDEN;}
;
--
View this message in context:
http://antlr.1301665.n2.nabble.com/Confused-about-backtracking-tp7033712p7033712.html
Sent from the ANTLR mailing list archive at Nabble.com.
List: http://www.antlr.org/mailman/listinfo/antlr-interest
Unsubscribe:
http://www.antlr.org/mailman/options/antlr-interest/your-email-address
--
You received this message because you are subscribed to the Google Groups
il-antlr-interest group.
To post to this group, send email to il-antlr-inter...@googlegroups.com.
To unsubscribe from this group, send email to
il-antlr-interest+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/il-antlr-interest?hl=en.
[il-antlr-interest: 35020] [antlr-interest] Matching compound keywords in the lexer
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
would make the grammar much less readable.
containOperator : CONTAINS_TEXT | CONTAINS_MATCH
CONTAINS_TEXT
: 'contains' WS+ ( 'match' { $type=CONTAINS_MATCH }
| 'text' )
;
// CONTAINS_MATCH:; // causes token definitions can never be matched
error
--
View this message in context:
http://antlr.1301665.n2.nabble.com/Matching-compound-keywords-in-the-lexer-tp7032358p7032358.html
Sent from the ANTLR mailing list archive at Nabble.com.
List: http://www.antlr.org/mailman/listinfo/antlr-interest
Unsubscribe:
http://www.antlr.org/mailman/options/antlr-interest/your-email-address
--
You received this message because you are subscribed to the Google Groups
il-antlr-interest group.
To post to this group, send email to il-antlr-inter...@googlegroups.com.
To unsubscribe from this group, send email to
il-antlr-interest+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/il-antlr-interest?hl=en.
[il-antlr-interest: 35026] [antlr-interest] Possible bug with backtrack-generated predicate methods
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] C:\Temp\output\TestParser.java:548: cannot find symbol
[08:50:01] symbol : variable $program
[08:50:01] location: class TestParser
[08:50:01] rule($program.tree);
=
grammar Test;
options {
output=AST;
backtrack=true;
}
program
: 'raw'? ( ID-ID ) ( rule[$program.tree] - rule )*
| 'raw' ID
;
rule[Object tree]
: 'some' ID
;
// LEXER
// ==
ID
: ('a'..'z'|'A'..'Z'|'_') ('a'..'z'|'A'..'Z'|'0'..'9'|'_')*
;
WS : ( ' '
| '\t'
| '\r'
| '\n'
) {$channel=HIDDEN;}
;
--
View this message in context:
http://antlr.1301665.n2.nabble.com/Possible-bug-with-backtrack-generated-predicate-methods-tp7033324p7033324.html
Sent from the ANTLR mailing list archive at Nabble.com.
List: http://www.antlr.org/mailman/listinfo/antlr-interest
Unsubscribe:
http://www.antlr.org/mailman/options/antlr-interest/your-email-address
--
You received this message because you are subscribed to the Google Groups
il-antlr-interest group.
To post to this group, send email to il-antlr-inter...@googlegroups.com.
To unsubscribe from this group, send email to
il-antlr-interest+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/il-antlr-interest?hl=en.
[il-antlr-interest: 35012] [antlr-interest] Understanding non LL(*) errors
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 for general tips that would help me get from such an error
message (the actual grammar is complex and those errors keep coming up with
every change) to a specific input example where I can understand which rule
sequence would send antlr into a recursive loop?
Thanks in advance!
Franck
grammar Test;
tokens {
ON='on';
COMMA=',';
}
callExpression
: primaryExpression
| 'call' primaryExpression ( 'using' primaryExpression ( options
{greedy=true;} : COMMA primaryExpression )* )?
;
primaryExpression
: '(' callExpression ')'
| ID
;
argumentList
: callExpression ( COMMA callExpression )*
;
// $
// LEXER
// ==
ID
: ('a'..'z'|'A'..'Z'|'_') ('a'..'z'|'A'..'Z'|'0'..'9'|'_')*
;
--
View this message in context:
http://antlr.1301665.n2.nabble.com/Understanding-non-LL-errors-tp7027459p7027459.html
Sent from the ANTLR mailing list archive at Nabble.com.
List: http://www.antlr.org/mailman/listinfo/antlr-interest
Unsubscribe:
http://www.antlr.org/mailman/options/antlr-interest/your-email-address
--
You received this message because you are subscribed to the Google Groups
il-antlr-interest group.
To post to this group, send email to il-antlr-inter...@googlegroups.com.
To unsubscribe from this group, send email to
il-antlr-interest+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/il-antlr-interest?hl=en.
[il-antlr-interest: 35015] Re: [antlr-interest] Understanding non LL(*) errors
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 a ( )*
subrule (see below)
2. I found the methodology I was looking for, simply add a global
backtrack=true option, parse a few inputs that you suspect are trouble
makers and look at the parse tree which shows the backtracking in green
red - much much easier for me to figure things out that way for recursive
errors.
Still not too sure about the performance impact of my predicate, but
hopefully looking at the parse tree for some complex inputs should give me
an indication since apparently it also shows the predicate evaluations in
green or red?
Refactoring seems at least as attractive but much harder to do right, and
without ending up with a useless AST.
Congratulations on the antlrworks tool, it is a life saver for inexperienced
grammar designers like me!
program : callExpression ( ',' callExpression )*;
callExpression
: primaryExpression
| 'call' primaryExpression ( ( ',' primaryExpression )= ','
primaryExpression )*
;
primaryExpression
: '(' callExpression ')'
| ID
;
--
View this message in context:
http://antlr.1301665.n2.nabble.com/Understanding-non-LL-errors-tp7027459p7029627.html
Sent from the ANTLR mailing list archive at Nabble.com.
List: http://www.antlr.org/mailman/listinfo/antlr-interest
Unsubscribe:
http://www.antlr.org/mailman/options/antlr-interest/your-email-address
--
You received this message because you are subscribed to the Google Groups
il-antlr-interest group.
To post to this group, send email to il-antlr-inter...@googlegroups.com.
To unsubscribe from this group, send email to
il-antlr-interest+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/il-antlr-interest?hl=en.
[il-antlr-interest: 34981] Re: [antlr-interest] String concatenation expression rule
Here is the kind of practical example I need to handle (again, this is an
existing, very ambiguous language, nothing I can do about that):
I need
call myFunc on 2 3 to parse as Concatenate(myFunc(2), 3)
call myFunc on 2 3 to parse as myFunc(23)
Concat has higher precedence than 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: String concatenation expression rule
Don't make the parser trap that error as a syntax error. It is a semantic
error and so you should parser any operand type, then reject the incorrect
types with code.
jim
-Original Message-
From: [hidden email] [mailto:antlr-interest-
[hidden email]] On Behalf Of franck102
Sent: Friday, November 18, 2011 8:53 AM
To: [hidden email]
Subject: Re: [antlr-interest] String concatenation expression rule
Hi Bart, thanks very for the quick reply.
I should have made it clear that concatenating is only legal if at
least one of the operands is a string literal - that is where I am
having an issue. In other terms the input
3 3EOF
should cause a syntax error, while
3 3EOF
should not (and evaluates to the string 33)
Franck
From: Bart Kiers [via ANTLR] ml-
[hidden email]
To: franck102 [hidden email]
Sent: Friday, November 18, 2011 1:11 PM
Subject: Re: String concatenation expression rule
On Fri, Nov 18, 2011 at 12:39 PM, franck102 [hidden email] wrote:
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 - 5mm
I suspect I could use predicates to write a rule like this:
concatExpression
: ( expression | STRING_LITERAL )+ { apply only if at
least
one of the elements is a string literal }?
Is there a way to achieve this? The alternative formulations I can
think of
are pretty messy...
As far as I understand it, you don't need any predicate. I see a
concat-expression has a lower precedence than addition, in which case
this
could do the trick:
grammar T;
options {
output=AST;
}
tokens {
ROOT;
CONCAT;
}
parse
: (expression ';')* EOF - ^(ROOT expression*)
;
expression
: (add - add) (add+ - ^(CONCAT add+))?
;
add
: atom (('+' | '-')^ atom)*
;
atom
: Number
| String
| '(' expression ')' - expression
;
Number : '0'..'9'+ ('.' '0'..'9'+)?;
String : '' ~''* '';
Space : ' ' {skip();};
You can test it with the following class:
import org.antlr.runtime.*;
import org.antlr.runtime.tree.*;
import org.antlr.stringtemplate.*;
public class Main {
public static void main(String[] args) throws Exception {
String src = 42 - 2; 2 + 3 \mm\; \a\ \b\ 4-3-2 \c\; \pi =
\
3.14159;;
TLexer lexer = new TLexer(new ANTLRStringStream(src));
TParser parser = new TParser(new CommonTokenStream(lexer));
CommonTree root = (CommonTree)parser.parse().getTree(); ;
System.out.println(new DOTTreeGenerator().toDOT(root));
}
}
Regards,
Bart.
List: http://www.antlr.org/mailman/listinfo/antlr-interest
Unsubscribe: http://www.antlr.org/mailman/options/antlr-interest/your-
email-address
If you reply to this email, your message will be added to the
discussion below:
http://antlr.1301665.n2.nabble.com/String-concatenation-expression-
rule-tp7007921p7008016.html
To unsubscribe from String concatenation expression rule, click here.
NAML
--
View this message in context:
http://antlr.1301665.n2.nabble.com/String-concatenation-expression-
rule-tp7007921p7008934.html
Sent from the ANTLR mailing list archive at Nabble.com.
List: http://www.antlr.org/mailman/listinfo/antlr-interest
Unsubscribe: http://www.antlr.org/mailman/options/antlr-interest/your-
email-address
List: http://www.antlr.org/mailman/listinfo/antlr-interest
Unsubscribe:
http://www.antlr.org/mailman/options/antlr-interest/your-email-address
If you reply to this email, your message will be added to the discussion below:
http://antlr.1301665.n2.nabble.com/String-concatenation-expression-rule-tp7007921p7009129.html
To unsubscribe from String concatenation expression rule, click here.
NAML
--
View this message in context:
http://antlr.1301665.n2.nabble.com/String-concatenation-expression-rule-tp7007921p7013416.html
Sent from the ANTLR mailing list archive at Nabble.com.
List: http
[il-antlr-interest: 34963] [antlr-interest] String concatenation expression rule
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 - 5mm
I suspect I could use predicates to write a rule like this:
concatExpression
:( expression | STRING_LITERAL )+ { apply only if at least
one of the elements is a string literal }?
Is there a way to achieve this? The alternative formulations I can think of
are pretty messy...
Thanks!
--
View this message in context:
http://antlr.1301665.n2.nabble.com/String-concatenation-expression-rule-tp7007921p7007921.html
Sent from the ANTLR mailing list archive at Nabble.com.
List: http://www.antlr.org/mailman/listinfo/antlr-interest
Unsubscribe:
http://www.antlr.org/mailman/options/antlr-interest/your-email-address
--
You received this message because you are subscribed to the Google Groups
il-antlr-interest group.
To post to this group, send email to il-antlr-inter...@googlegroups.com.
To unsubscribe from this group, send email to
il-antlr-interest+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/il-antlr-interest?hl=en.
[il-antlr-interest: 34973] Re: [antlr-interest] String concatenation expression rule
Hi Bart, thanks very for the quick reply.
I should have made it clear that concatenating is only legal if at least one of
the operands is a string literal - that is where I am having an issue. In other
terms the input
3 3EOF
should cause a syntax error, while
3 3EOF
should not (and evaluates 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, franck102 [hidden email] wrote:
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 - 5mm
I suspect I could use predicates to write a rule like this:
concatExpression
: ( expression | STRING_LITERAL )+ { apply only if at least
one of the elements is a string literal }?
Is there a way to achieve this? The alternative formulations I can think of
are pretty messy...
As far as I understand it, you don't need any predicate. I see a
concat-expression has a lower precedence than addition, in which case this
could do the trick:
grammar T;
options {
output=AST;
}
tokens {
ROOT;
CONCAT;
}
parse
: (expression ';')* EOF - ^(ROOT expression*)
;
expression
: (add - add) (add+ - ^(CONCAT add+))?
;
add
: atom (('+' | '-')^ atom)*
;
atom
: Number
| String
| '(' expression ')' - expression
;
Number : '0'..'9'+ ('.' '0'..'9'+)?;
String : '' ~''* '';
Space : ' ' {skip();};
You can test it with the following class:
import org.antlr.runtime.*;
import org.antlr.runtime.tree.*;
import org.antlr.stringtemplate.*;
public class Main {
public static void main(String[] args) throws Exception {
String src = 42 - 2; 2 + 3 \mm\; \a\ \b\ 4-3-2 \c\; \pi = \
3.14159;;
TLexer lexer = new TLexer(new ANTLRStringStream(src));
TParser parser = new TParser(new CommonTokenStream(lexer));
CommonTree root = (CommonTree)parser.parse().getTree(); ;
System.out.println(new DOTTreeGenerator().toDOT(root));
}
}
Regards,
Bart.
List: http://www.antlr.org/mailman/listinfo/antlr-interest
Unsubscribe:
http://www.antlr.org/mailman/options/antlr-interest/your-email-address
If you reply to this email, your message will be added to the discussion below:
http://antlr.1301665.n2.nabble.com/String-concatenation-expression-rule-tp7007921p7008016.html
To unsubscribe from String concatenation expression rule, click here.
NAML
--
View this message in context:
http://antlr.1301665.n2.nabble.com/String-concatenation-expression-rule-tp7007921p7008934.html
Sent from the ANTLR mailing list archive at Nabble.com.
List: http://www.antlr.org/mailman/listinfo/antlr-interest
Unsubscribe:
http://www.antlr.org/mailman/options/antlr-interest/your-email-address
--
You received this message because you are subscribed to the Google Groups
il-antlr-interest group.
To post to this group, send email to il-antlr-inter...@googlegroups.com.
To unsubscribe from this group, send email to
il-antlr-interest+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/il-antlr-interest?hl=en.
