Welcome, Guest
Username: Password:
  • Page:
  • 1

TOPIC:

Operator precedence in EBNF 22 Oct 2002 20:58 #6234

This is the operator precedence table (section 15.0):

priority | operator type | operator
| if not binary |
+
+
highest | | ( ... )
| unary | +, -, *, /, mod
| | +, -, &
| unary | not4b
| | and4b
| | xor4b
| | or4b
| | <<, >>, <@, @>
| | <, >, <=, >=
| | ==, !=
| unary | not
| | and
| | xor
lowest | | or


But this operator precedence is not reflected in the EBNF.
The operator precedence in the EBNF is:

priority | operator type | operator
| if not binary |
+
+
highest | | ( ... )
| unary | +, -
| | *, /, mod
| | +, -, &
| unary | not4b
| | and4b, xor4b, or4b
| | <<, >>, <@, @>
| | <, >, <=, >=,==, !=
| unary | not
| | and, xor, or

The operators are in these incorrect groupings:

and4b, xor4b, or4b
<, >, <=, >=,==, !=
and, xor, or


The EBNF should either explicitly separate out different levels
of precedence like:

SingleExpression ::= XorExpression { or XorExpression }
XorExpression ::= AndExpression { xor AndExpression }
AndExpression ::= SingleExpression { and SingleExpression }

Or the EBNF should ignore the operator precedence and refer to
the table in section 15.0. Something like:

SingleExpression ::= SingleExpression BinaryOp SingleExpression |
UnaryOp SingleExpression |
"(" SingleExpression ")" |
OpCall | Value
BinaryOp ::= ... /* see section 15.0 for resolving operator precedence */

My opinion is operator precedence should not be partly explicit
and partly ignored in the EBNF. Either fully specify the precedence
or fully ignore it. I have no preference either way, but I am not
in favour of keeping the current mixed-up EBNF definition for
expressions.

Cheers,
--
Carl Cerecke - Software Designer
Da Vinci Communications Ltd
Christchurch - New Zealand
TEL : +64 3 3838311
FAX : +64 3 3838310
e-mail: This email address is being protected from spambots. You need JavaScript enabled to view it.
www : www.davinci-communications.com

Please Log in to join the conversation.

Operator precedence in EBNF 23 Oct 2002 06:54 #6236

Hi Carl,

I believe there is no need to have a further discussion
on this subject in this mailing list, because you said
everything.

Please write a CR with your preferred complete solution.
The TTCN-3 maintenance group can only work based on CRs
in order to have a transparent maintenance procedure.

Regards
Jens



> This is the operator precedence table (section 15.0):
>
> priority | operator type | operator
> | if not binary |
>
+
+
> highest | | ( ... )
> | unary | +, -, *, /, mod
> | | +, -, &
> | unary | not4b
> | | and4b
> | | xor4b
> | | or4b
> | | <<, >>, <@, @>
> | | <, >, <=, >=
> | | ==, !=
> | unary | not
> | | and
> | | xor
> lowest | | or
>
>
> But this operator precedence is not reflected in the EBNF.
> The operator precedence in the EBNF is:
>
> priority | operator type | operator
> | if not binary |
>
+
+
> highest | | ( ... )
> | unary | +, -
> | | *, /, mod
> | | +, -, &
> | unary | not4b
> | | and4b, xor4b, or4b
> | | <<, >>, <@, @>
> | | <, >, <=, >=,==, !=
> | unary | not
> | | and, xor, or
>
> The operators are in these incorrect groupings:
>
> and4b, xor4b, or4b
> <, >, <=, >=,==, !=
> and, xor, or
>
>
> The EBNF should either explicitly separate out different levels
> of precedence like:
>
> SingleExpression ::= XorExpression { or XorExpression }
> XorExpression ::= AndExpression { xor AndExpression }
> AndExpression ::= SingleExpression { and SingleExpression }
>
> Or the EBNF should ignore the operator precedence and refer to
> the table in section 15.0. Something like:
>
> SingleExpression ::= SingleExpression BinaryOp SingleExpression |
> UnaryOp SingleExpression |
> "(" SingleExpression ")" |
> OpCall | Value
> BinaryOp ::= ... /* see section 15.0 for resolving operator
precedence */
>
> My opinion is operator precedence should not be partly explicit
> and partly ignored in the EBNF. Either fully specify the precedence
> or fully ignore it. I have no preference either way, but I am not
> in favour of keeping the current mixed-up EBNF definition for
> expressions.
>
> Cheers,
> --
>
> Carl Cerecke - Software Designer
> Da Vinci Communications Ltd
> Christchurch - New Zealand
>
> TEL : +64 3 3838311
> FAX : +64 3 3838310
> e-mail: This email address is being protected from spambots. You need JavaScript enabled to view it.
> www : www.davinci-communications.com
>
>

Please Log in to join the conversation.

  • Page:
  • 1

FacebookTwitterGoogle BookmarksRedditNewsvineTechnoratiLinkedin