Precedence of Unary Logical Operators

Proposal Information

• Who Updates: JimLewis, YourName>, ...
• Date Proposed: 2013-11-14
• Date Last Updated: 2013-11-14
• Priority:
• Complexity:
• Focus: Testbench

Requirement Summary

In VHDL-2008 LRM p118, the precedence of the unary logical operators is not listed and needs to be.

Related and/or Competing Issues: NONE

Issue Summary: Bugzilla 278 and 280

Bugzilla 278 ... Skipping over the part that is ok ...

the list on 9.2.1, Operators-General, is misleading and technically incorrect, since it lists logic_operators as second in the list and states the the "operators are listed in order of increasing precedence." This statement implies that my original claim about precedence is true. One possible solution is to add "logical reduction operators" or "unary logical operators" to the miscellaneous_operator list, to give them the correct precedence.

A further issue is that NOTE 2 on page 118 is wrong. It appears to be a relic of the way the grammar was originally written, not as it was finally approved.

Bugzilla 280 ... Closes saying it is ok and to see 278 for discussion

Actions

Change the grammar production for miscellaneous operator to

miscellaneous_operator ::= ** | abs | not | unary _logical_operator

Delete note 2 at the top of 118 that reads:

"NOTE 2—The syntax for an expression involving a unary condition operator or unary logical operator in combination with any other operator requires that the unary operator and its operand be a parenthesized expression. For example, the expressions “(and A) and B” and “A and (and B)” are legal, whereas the expression “and A and B” and “A and and B” are not. Similarly, “and (and A)” is legal, whereas “and and A” is not. An expression consisting only of a unary condition oprator or unary logical operator and its operand need not be parenthesized."

General Comments

-- DavidKoontz - 2014-10-07

If 9.1 Note 2 (top of P.118) where it would represent a lexical ambiguity between the EBNF and

9.2 Operators, 9.2.1 General, para 10:

Operators of higher precedence are associated with their operands before operators of lower precedence. Where the language allows a sequence of operators, operators with the same precedence level are associated with their operands in textual order, from left to right. The precedence of an operator is fixed and cannot be changed by the user, but parentheses can be used to control the association of operators and operands.

This would require parentheses to avoid an elaboration time error.

-- DavidKoontz - 2017-02-05

You could note that the BNF non-terminal production factor is correct in that it includes an alternative logical_operator primary. What's missing is support in the precedence table found in 9.2.1, a text narrative issue, noting the that NOTE 2 in 9.2.2 (top of page 118) is inaccurate - logical operators are not the lowest precedence. Also note the production miscellaneous_operator is found no where else in the BNF (other than Annex C) instead choices given in the production demonstrate the the highest precedence class.

A proper solution might be to remove the mentions of BNF productions in the precedence table instead proving lead in text mentioning the classes of operators and the unary not logical operator, remove 9.2.2 NOTE 2, delete the Annex C BNF notation for the production miscellaneous_operator and to remove NOTE 2 of 9.2.1 which is specific to the unary not operator.

It might be worth adding two headers to 9.2.2:

This does not provide an additional level of precedence as implied in Peter Flake's LCS ( LCS2016_I13 R15) to eliminate parenthesis needed today to specify precedence order among the current highest level of precedence. That LCS does not reference this proposal and provides no readily apparent support for the added level of precedence.

Supporters

_Add your signature here to indicate your support for the proposal

-- Brent Hayhoe - 2014-10-13