Wait I think I misunderstood. Your example `(a OR (b OR (c AND d)))` is just an example expression, right? In that case, yes, these parenthesis are part of the token stream, but if you apply rewrite rules (or AST operators `^` and `!`) properly, these parenthesis are easily removed from your parse tree.
See: http://www.antlr.org/wiki/display/ANTLR3/Tree+construction or: http://stackoverflow.com/questions/4931346/how-to-output-the-ast-built-using-antlr Regards, Bart. On Mon, May 9, 2011 at 4:10 PM, Bart Kiers <bki...@gmail.com> wrote: > I get the impression you think that when creating AST's, ANTLR inserts > parenthesis (brackets). This is not the case: I guess what you're seeing is > just the tree's `toStringTree()` that displays these parenthesis to make the > hierarchy of the tree apparent. > Or am I misinterpreting your question? > > Regards, > > Bart. > > > > > On Mon, May 9, 2011 at 3:10 PM, Hans-Juergen Rennau <hren...@yahoo.de>wrote: > >> Hello People, >> >> being an ANTLR beginner, I would very much appreciate advice concerning >> good >> practise for a rather simple task. The task is the translation of a JPQL's >> (Java >> Persistence Query Language) "where clause" into a proprietary query >> language. >> The clause has the well-known expression structure: operands conncected by >> three >> operators: OR, AND and NOT, where precedence increases in that order. >> Example: >> a.x='1' AND (a.y='2' OR b.z='3') AND a.v like 'abc%' >> >> An important point is that the translation result will have a similar >> structure, >> that is, it will also be operands connected by those operators. Example: >> x='1' AND (y='2' OR z='3') AND v='123*' >> >> For this reason I am not sure if the "classical" approach for dealing with >> left-associative operators, as shown in the "Definitve ANTLR Reference" >> (3. A >> quick tour...) is the most appropriate one in this case. I mean rules >> like: >> conditional_term ('OR'^ conditional_term)* >> conditional_factor ('AND'^ conditional_factor)* >> >> This creates deep trees, where each operator creates a new level. That is >> fine >> for processing the operations. But a straightforward translation of the >> tree >> into a similar sequence of operands and operators yields a result which is >> correct but can be ugly, due to superflous brackets, example: >> (a OR (b OR (c AND d))) >> >> One possibility is to process the tree, removing superfluous brackets - >> perhaps >> by passing the "context operator" into the rule as a parameter, so that >> the rule >> can decide if to create brackets or not. This should not be too difficult, >> but >> my question is: is there a good practise for accomplishing the task? Would >> you >> recommend the approach just sketched, or a different tree representation >> to >> start with? >> >> (A tree I do want because there are other parts to be translated, not only >> the >> where clause, and a tree seems to me the way to deal with (possibly yet >> growing) >> complexity. >> >> Thank you very much for any suggestions. >> >> -- Hans-Juergen >> >> >> 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 -- 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.