Subject: snmpconf proposed policy language grammar change

From: Ray Byler <[email-masked]>
Date: Mon, 16 Apr 2001 10:55:00 -0400 (EDT)

Since the policy language is formally defined as a
subset of ISO C++, it should follow C/C++ rules of
operator precedence.  The policy language grammar
as written doesn't enforce this, and precedence
rules in yacc/bison don't solve the problem.
The simplest solution is to modify the grammar.
Therefore, I recommend that we replace the following
productions. The new rules are functionally 
equivalent, but enforce C's rules of operator precedence.

/////////////////////////////////////////////////////

OLD
~~~

binary_expression:
    unary_expression
    | binary_expression binary_operator unary_expression

binary_operator:
    '||' | '&&' | '|' | '^' | '&' | '!=' | '==' | '>=' | '<='
    | '>' |  '<' | '>>' | '<<' |  '-' |  '+' |  '%' |  '/' |  '*'

assignment_expression:
    binary_expression
    | unary_expression assignment_operator assignment_expression

/////////////////////////////////////////////////////

NEW
~~~
multiplicative_expression
	:   unary_expression
	|   multiplicative_expression MODULO unary_expression
	|   multiplicative_expression DIVIDE unary_expression
	|   multiplicative_expression TIMES unary_expression

additive_expression
	:   multiplicative_expression
	|   additive_expression MINUS multiplicative_expression
	|   additive_expression PLUS  multiplicative_expression

shift_expression
	:   additive_expression
	|   shift_expression RIGHT_SHIFT additive_expression
	|   shift_expression LEFT_SHIFT  additive_expression

relational_expression 
	:   shift_expression
	|   relational_expression GE shift_expression
	|   relational_expression LE shift_expression
	|   relational_expression GT shift_expression
	|   relational_expression LT shift_expression

equality_expression 
	:   relational_expression
	|   equality_expression NE relational_expression
	|   equality_expression EQ relational_expression

and_expression
	:   equality_expression
	|   and_expression BITWISE_AND equality_expression

exclusive_or_expression 
	:   and_expression
	|   exclusive_or_expression XOR and_expression

inclusive_or_expression
	:   exclusive_or_expression
	|   inclusive_or_expression BITWISE_OR exclusive_or_expression

logical_and_expression
	:   inclusive_or_expression
	|   logical_and_expression LOGICAL_AND inclusive_or_expression

logical_or_expression
	:   logical_and_expression
	|   logical_or_expression LOGICAL_OR logical_and_expression

assignment_expression
	:   logical_or_expression
	|   unary_expression assignment_operator assignment_expression

/////////////////////////////////////////////////////

Ray Byler

---

From: Pablo Halpern <[email-masked]>
Date: Mon, 16 Apr 2001 11:58:04 -0400

>equivalent, but enforce C's rules of operator precedence.

We once had the precedence spelled out in the grammar as you suggested. 
However, Steve felt that compactness was called for, so we went with the 
simpler BNF. There is nothing in the document that suggests that this BNF 
is a yacc grammar and there is no attempt to make it so.  The document 
explicitly states that the BNF is not sufficient in and of itself to 
describe the language. You must refer to the rules of C++ in order to 
complete the picture. Thus, he precedence rules of C++ apply even if they 
are not spelled out in the compact BNF used in the document.  The breakdown 
you suggest is exactly the kind of thing I would do in a real 
implementation (I have not checked your grammar for accuracy, BTW), but it 
is not necessary to express it this way in the Policy document.

BTW, this is the reason we removed the non-if-statement production: it is 
useful for getting a parser generator to work, but the rules of C++ are 
sufficient without using the abbreviated BNF as the arbiter of ambiguity.

- Pablo
---------------------------------------------------------------------
Pablo Halpern                                    [email-masked]
http://www.halpernwightsoftware.com