> Hi Sam,
>
> I'm working on an ANTLR preproc with Peter Burns here at USF.
Can the preproc deal with a grammar targetting several languages at once? What
about creating different ASTs from a parse tree?
Johannes
>
> Peter: we don't require unary higher than binary do we?
>
> Ter
> On Apr 23, 2009, at 10:59 AM, Sam Harwell wrote:
>
> > I’m working on a generalized expression parser backend that I hope
> > to integrate as generated code in ANTLR targets. The forwarded email
> > below shows a particular issue that needs to be addressed before the
> > expression parser can be used with languages with “odd” precedence
> > orders. I’m looking for feedback on my proposed resolution in my
> > parser backend.
> >
> > There shouldn’t be a restriction in the code that says all unary
> > operators have to have higher precedence than any binary operators.
> > As such, I’m planning on handling this by adding the following
> > enumeration, and either allowing it (with a default value of
> > Elevate) or explicitly requiring it for unary operators that come
> > before some binary operator in the precedence order.
> >
> > This issue fully addresses ternary operators as well, where the
> > required elevation involves the use of unary and/or binary operators
> > in the middle section, such as the {value if true} section of the C+
> > + ternary operator: {condition} ? {value if true} : {value if false}.
> >
> > /// <summary>
> > /// Controls the behavior of lower priority, lower cardinality
> > operator next to higher priority,
> > /// higher cardinality operator.
> > /// </summary>
> > /// <example>
> > /// In languages like Matlab, the unary +/- operators have a lower
> > priority than the binary
> > /// exponentiation operator. The user needs to be able to configure
> > the handling of the unary
> > /// +/- operators in the following case:
> > ///
> > /// 2^-2
> > ///
> > /// If the unary operator's precedence remains lower than the
> > exponentiation operator, this
> > /// is syntactically incorrect. As an option, and one that Matlab
> > uses, the operator's
> > /// precedence immediately following an exponentiation operator is
> > elevated, so the expression
> > /// above is allowed.
> > /// </example>
> > public enum MixedCardinalityAction
> > {
> > /// <summary>
> > /// Never re-order the operator precedence of the lower priority
> > operator to allow its
> > /// use next to a higher priority operator.
> > /// </summary>
> > None,
> > /// <summary>
> > /// When syntactically unambiguous, elevates the lower
> > cardinality operator's precedence
> > /// to allow its usage next to a higher cardinality operator.
> > /// </summary>
> > Elevate
> > }
> >
> > Thank you,
> > Sam Harwell
> >
> > From: Sam Harwell
> > Sent: Thursday, April 23, 2009 10:05 AM
> > To: '[email protected]'
> > Subject: Unary operator precedence
> >
> > Hello,
> >
> > I am having some trouble with the unary operator precedence in
> > certain situations. According to the spec, the multiplication
> > operator has higher precedence than the unary - operator, which is
> > posing a problem for the following expression:
> >
> > 3 * -2
> >
> > For the fixed precedence levels as documented, this appears to be a
> > syntax error unless written like this:
> >
> > 3 * (-2)
> >
> > One way to allow this syntax is cause the unary operator immediately
> > following a *, /, %, reduce, scan, !, ~, or ** to have higher than
> > normal precedence. Operators ! and ~ do not need this clarification
> > following *, /, or %. The following is an extract of a grammar for a
> > recursive descent LL parser.
> >
> > not_expression
> > : ('!' | '~')*
> > reduce_scan_expression
> > ;
> >
> > multiply_expression
> > : not_expression
> > ( ('*' | '/' | '%') =>
> > ('*' | '/' | '%')
> > not_expression
> > )*
> > ;
> >
> > negate_expression
> > : ('+' | '-')*
> > multiply_expression
> > ;
> >
> > addition_expression
> > : negate_expression
> > ( ('+' | '-') =>
> > ('+' | '-')
> > negate_expression
> > )*
> > ;
> >
> > I would have to make the following alteration which, despite being
> > unambiguous, clearly shows that a unary operator following a
> > multiplicative operator has a different precedence from the same
> > operator in other contexts.
> >
> > multiply_expression
> > : not_expression
> > ( ('*' | '/' | '%') =>
> > ('*' | '/' | '%')
> > ('+' | '-')? not_expression
> > )*
> > ;
> >
> > negate_expression
> > : ('+' | '-')*
> > multiply_expression
> > ;
> >
> > Octave (and hence Matlab I’m guessing) follows this approach
> > (-2^2=-4 and 2*-2=-4). C++ handles this problem by making .* and ->*
> > their own operators, then making all unary operators have a higher
> > precedence than any binary operators. Either way it goes, I believe
> > the order should be documented so it does not pose a problem for
> > people creating a Chapel compiler in the future. :)
> >
> > Thank you,
> > Sam Harwell
> >
> > _______________________________________________
> > antlr-dev mailing list
> > [email protected]
> > http://www.antlr.org/mailman/listinfo/antlr-dev
>
> _______________________________________________
> antlr-dev mailing list
> [email protected]
> http://www.antlr.org/mailman/listinfo/antlr-dev
--
Psssst! Schon vom neuen GMX MultiMessenger gehört? Der kann`s mit allen:
http://www.gmx.net/de/go/multimessenger01
_______________________________________________
antlr-dev mailing list
[email protected]
http://www.antlr.org/mailman/listinfo/antlr-dev
