[antlr-interest] Translating expressions - advice?

Bart Kiers bkiers at gmail.com
Mon May 9 07:16:53 PDT 2011

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



On Mon, May 9, 2011 at 4:10 PM, Bart Kiers <bkiers at 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 <hrennau at 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

More information about the antlr-interest mailing list