(r27) LCS2016_I13 < P1076

P1076 Web>VHDL2017>LCS2016_I13 (revision 27) (raw view)~~EditAttach~~
---+!! Language Change Specification for Precedence of Unary Operators

%TOC%

| <sticky><b>LCS Number:</b></sticky> | LCS-2016-13 |
| <sticky><b>Version:</b></sticky>  | 5  |
| <sticky><b>Date:</b></sticky>  | v4 8-Feb-2017 v5 2-Mar-2017 |
| <sticky><b>Status:</b></sticky>  | |
| <sticky><b>Author:</b></sticky>  | [[Main.PeterFlake][Peter Flake]] |
| <sticky><b>Email:</b></sticky>  | %USERINFO{"PeterFlake" format="$emails"}% |
| <sticky><b>Source Doc:</b></sticky> | [[LCS2016_I13][Unary Precedence]]  |
| <sticky><b>Summary:</b></sticky>  | Remove ambiguity of precedence of unary operators in formal syntax |

---++ Voting Results: Cast your votes here

* Yes:
   1 %USERSIG{PeterFlake - 2016-12-20}%
   1 %USERSIG{JimLewis - 2017-02-07}% ver 3
   1 %USERSIG{BrentHahoe - 2017-02-02}%
   1 %USERSIG{LievenLemiengre - 2017-02-02}%
   1 %USERSIG{RobGaddi - 2017-03-02}% ver 5
   1 %USERSIG{ThomasPreusser - 2017-02-08}% - ver 3
   1 %USERSIG{PatrickLehmann - 2017-03-02}% ver 5

* No:
   1 

* Abstain:
   1 

---++ Details of Language Change:

Key:
   * Existing LRM text is shown in <sticky>%BLACK%<b>BLACK font</b>%ENDCOLOR%</sticky>
   * Additional LRM text is shown in <sticky>%RED%<b>RED</b>%ENDCOLOR%</sticky>
   * Deleted LRM text is shown in <sticky>%RED%<strike><b>RED with strike-through</b></strike>%ENDCOLOR%</sticky>

---+++ LRM 9 Expressions
---++++!! page 117

9.1 General

An expression is a formula that defines the computation of a value.

<verbatim>
expression ::=
   condition_operator primary
   | logical_expression 
logical_expression ::=
   relation { and relation }
   | relation { or relation }
   | relation { xor relation }
   | relation [ nand relation ]
   | relation [ nor relation ]
   | relation { xnor relation } 
relation ::=
   shift_expression [ relational_operator shift_expression ]
   shift_expression ::=
   simple_expression [ shift_operator simple_expression ] 
simple_expression ::=
   [ sign ] term { adding_operator term } 
term ::=
   factor { multiplying_operator factor } </verbatim> <sticky><pre>%RED%<del> 
factor ::=
   primary [ <b>**</b> primary ]
   | <b>abs</b> primary
   | <b>not</b> primary
   | logical_operator primary </del>
</pre>
<pre>%RED%
factor ::=
   unary_expression [ <b>**</b> unary_expression ] 
</pre>
<pre>%RED%
unary_expression ::=
     primary
   | <b>abs</b> primary
   | <b>not</b> primary
   | <i>unary</i>_logical_operator primary
</pre></sticky> <verbatim>primary ::=
   name
   | literal
   | aggregate
   | function_call
   | qualified_expression
   | type_conversion
   | allocator
   | ( expression ) </verbatim>

Each primary has a value and a type. The only names allowed as primaries are attributes that yield values and names denoting objects or values. In the case of names denoting objects other than objects of file types or protected types, the value of the primary is the value of the object. In the case of names denoting either file objects or objects of protected types, the value of the primary is the entity denoted by the name. The type of an expression depends only upon the types of its operands and on the operators applied; for an overloaded operand or operator, the determination of the operand type, or the identification of the overloaded operator, depends on the context (see 12.5). For each predefined operator, the operand and result types are given in the following subclause.

NOTE 1—The syntax for an expression involving logical operators allows a sequence of binary and, or, xor, or xnor operators (whether predefined or user-defined), since the corresponding predefined operations are associative. For the binary operators nand and nor (whether predefined or user-defined), however, such a sequence is not allowed, since the corresponding predefined operations are not associative.

%RED%<del>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. </del>

NOTE %RED%2<del> 3</del>%ENDCOLOR%—PSL extends the grammar of VHDL expressions to allow PSL expressions, PSL built-in function calls, and PSL union expressions as subexpressions. Such extended expressions can only appear in a VHDL description within PSL declarations and PSL directives, or in a verification unit.

9.2 Operators

9.2.1 General

The operators that may be used in expressions are defined as follows. Each operator belongs to a class of operators, all of which have the same precedence level; the classes of operators are listed in order of increasing precedence.

condition_operator ::= ??

logical_operator ::= and | or | nand | nor | xor | xnor

relational_operator ::= = | /= | &lt; | &lt;= | &gt; | &gt;= | ?= | ?/= | ?&lt; | ?&lt;= | ?&gt; | ?&gt;=

shift_operator ::= sll | srl | sla | sra | rol | ror

adding_operator ::= + | – | &

sign ::= + | –

multiplying_operator ::= * | / | mod | rem

%RED% _binary_ _miscellaneous_operator ::= **%ENDCOLOR%

%RED% _unary_ _%ENDCOLOR%miscellaneous_operator ::= %RED%<del>** |</del>%ENDCOLOR% abs | not | %RED% _unary_ _logical_operator%ENDCOLOR%

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. In general, operands in an expression are evaluated before being associated with operators. For certain operations, however, the right-hand operand is evaluated if and only if the left-hand operand has a certain value. These operations are called short-circuit operations. The binary logical operations and, or, nand, and nor defined for operands of types BIT and BOOLEAN are all short-circuit operations; furthermore, these are the only short-circuit operations.

Every predefined operator and every predefined MINIMUM and MAXIMUM operation is a pure function (see 4.2.1). No predefined operators have named formal parameters; therefore, named association (see 6.5.7.1) cannot be used when invoking a predefined operator.

NOTE 1—The predefined operators for the standard types are declared in package STANDARD as shown in 16.3.

%RED%<del>NOTE 2—The operator not is classified as a miscellaneous operator for the purposes of defining precedence, but is otherwise classified as a logical operator.</del>%ENDCOLOR%

9.2.2 General

%GREEN%[Delete note at end of section on page 120]%ENDCOLOR%

%RED%<del>NOTE—All of the binary logical operators belong to the class of operators with the lowest precedence. The unary logical operators belong to the class of operators with the highest precedence.</del>%ENDCOLOR%

---+++ LRM Annex C
---++++!! page 486
<pre>%RED%<del>
factor ::=
   primary [ <b>**</b> primary ]
   | <b>abs</b> primary
   | <b>not</b> primary
   | logical_operator primary </del>
</pre> <pre>%RED%
factor ::=
   unary_expression [ <b>**</b> unary_expression ] 
</pre>

---++++!! page 500 (top)
<pre>%RED%
unary_expression ::=
     primary
   | <b>abs</b> primary
   | <b>not</b> primary
   | <i>unary</i>_logical_operator primary
</pre>

---++ Comments

In section 9.2.2 - Logical operators is the following: NOTE—All of the binary logical operators belong to the class of operators with the lowest precedence. The unary logical operators belong to the class of operators with the highest precedence.

Perhaps this note needs to be copied (or possibly moved), to section 9.2.1 to define the precedence of unary operators rather than defining new 'unary_expression'. Would seem to me to be simpler way to accomplish the goal of defining unary operator precedence.

-- %BUBBLESIG{KevinJennings - 2016-12-08}%

The EBNF rule for "unary_expression" should refer to //unary_//logical_operator. The EBNF rule "miscellaneous_operator" should also use "logical_operator" with "unary_" in italic font.

-- %BUBBLESIG{PatrickLehmann - 2016-12-31}%

It's not clear what the intent is for the proposed introduction of unary_expression in 9.1. Its effect is that expressions of the form abs x *&zwj;*** y become legal while in 1076-2008 this would have to be written as (abs x) *&zwj;*** y. In my perspective the parenthesized form is clear with regards to associativity while the form that becomes legal with the proposed change is not (I am referring to the expression text; of course it's clear when referring to the LRM). A rationale for the proposed change would be welcome.

Regarding the proposed change to 9.2.1, the prefix _unary_ should be in tialics. The change works because there is no syntactic reference to the production miscellaneous_operators, otherwise the grammar would become ambiguous. However, I second Kevin in his proposal to add a NOTE 3 that repeats the NOTE from 9.2.2.

-- %BUBBLESIG{ErnstChristen - 2017-01-26}%

I agree: NOTE 2 should be removed because it is not true even in the current LRM:

   * “and A and B” as well as “A and and B” are legal in VHDL 2008.
   * “and (and A)” as well as “and and A” are not possible because after the first reduction, the result will not be an one-dimensional array of type bit or std_logic_vector any more.

*EDIT*: <strike>The BNF should not be changed. I concur with Ernst here.</strike> See Patrick's comment below.

-- %BUBBLESIG{MartinZabel - 2017-02-03}%

By dividing the EBNF rules into two rules for =factor= and =unary_expression=, you are introducing, as intended, a new level of precedence. You also need to create a new rule/row in 9.2.1 because each line/rule represents one level of precedence. So you need to divide =miscellaneous_operator= into two lines to reflect the new precedence levels.

-- %BUBBLESIG{PatrickLehmann - 2017-02-03}%

I think the note in 9.2.2 needs to be deleted. The lowest precedence is now ??. Like Ernst I too like parentheses, however, only the ** operator requires them. All of the other binary operators do not. Hence, I think the change makes things more consistent. I agree on the usage of unary in itallics in the two places Patrick noted.

WRT precedence of miscellaneous operators (**, abs, not, unary logic operators) the precedence between operators did change, however, the precedence of the group of operators did not change. The precedence between operators was none (parentheses required) and is now left to right. This is still consistent with the LRM text as it allows left to right precedence where the EBNF allows it.

-- %BUBBLESIG{JimLewis - 2017-02-08}%

Updated to revision 3 to address comments above

-- %BUBBLESIG{JimLewis - 2017-02-08}%

@JimLewis:

*JL:* WRT precedence of miscellaneous operators (**, abs, not, unary logic operators) the precedence between operators did change, however, the precedence of the group of operators did not change. The precedence between operators was none (parentheses required) and is now left to right. This is still consistent with the LRM text as it allows left to right precedence where the EBNF allows it.

*MZ:* I don't understand this. Within each group, all operators have the same precedence, as also stated in clause 9.2.1 paragraph 1. But within an expression, operators with the same precedence level are associated from left to right, as stated in clause 9.2.1 paragraph 3 (below BNF).

<strike>Example 1:

=a AND b OR c= is the same as =(a AND b) OR c=.

Example 2:

=a OR b AND c= is the same as =(a OR b) AND c= even if =OR= is listed after =AND= in the group =logical_operator=.</strike>

Example 3:

=abs a <b>**</b> abs b= is not possible in VHDL-2008, but will be possible with this LCS. The expression equals to =(abs a) <b>**</b> (abs b)=. Thus <b>**</b> has a higher precedence *and must be listed in it's own group*.

-- %BUBBLESIG{MartinZabel - 2017-02-08}%

@MZ. WRT Example 3: you state: =abs a <b>**</b> abs b= is equivalent to: =(abs a) <b>**</b> (abs b)=

I agree.

One correct view of this is: "abs" has higher precedence than "**" because "abs" is done first.

Another correct view of this is: "abs" and "**" have equal precedence, and then left to right evaluation results in the same parenthesized expression.

Hence, the current table correctly expresses one of the two possible precedence rules.

For Examples 1 and 2, you have to read the "weasel words": "Where the language allows a sequence of operators". The EBNF does not allow mixing "and" with "or". Interestingly, the EBNF is the sole source of that information. If you try to mix "and" and "or" without parentheses you will get a syntax error.

Honestly, I like parentheses, however, it does not make sense to require parentheses for "**" and not for "and".

-- %BUBBLESIG{JimLewis - 2017-02-08}%

@Jim: Now I understand the "weasel words." Of course, example 1 and 2 have syntax errors.

Regarding example 3: You cannot evaluate it from left to right, this would be =((abs a) <b>**</b>) abs b= which is non-sense. (Or I don't understand your view.)

The only problem with the BNF rule for =miscellaneous_operator= was, that clause 9.2.8 refers to it. What about this change for clause 9.2.1 to split it into two groups:

%RED%binary_miscellaneous_operator ::= **%ENDCOLOR%

%RED%unary_%ENDCOLOR%miscellaneous_operator ::= abs | not | %RED% _unary_ _logical_operator%ENDCOLOR%

-- %BUBBLESIG{MartinZabel - 2017-02-10}%

In example 3, left to right it evaluates to: ((abs a) <b>* abs b). The expression "abs b" is left operand to *</b> and it is evaluated per the text "In general, operands in an expression are evaluated before being associated with operators".

Hence, both are indeed correct.

-- %BUBBLESIG{JimLewis - 2017-02-24}%
%COMMENT%
Topic revision: r1 - 2017-04-02 - 16:30:39 - TWikiGuest
P1076