Language Change Specification for Conditional Expressions and/or Operators Proposal

Voting Results: Cast your votes here

Yes:

1. Morten Zilmer - 2016-12-11

No:

1. Thomas Preusser - 2016-12-15 - see below, also consider LCS-2016-036a
2. Ryan Hinton - 2016-12-19 ver 1
3. Farrell Ostler - 2017-01-18 ver 1
4. Patrick Lehmann - 2017-01-19 - ver 1 - LCS-2016-036a seams to be a better solution for the proposal.
5. Kevin Jennings - 2017-1-18 - Ver 1, switching vote to 36a, 'when' does fit in better with the historical language than 'if'.
6. Martin Zabel - 2017-01-19 - ver 1 - also prefer LCS-2016-036a.
7. Lieven Lemiengre - 2017-01-27
8. Hendrik Eeckhaut - 2017-01-27

Abstain:

1. Martin Thompson - 2016-12-12

Details_of_Language_Change

LRM Section 9.1 Expressions General and Annex C - Syntax Summary

Page 117 top and page 486 top

Changes are shown in red font.

expression ::=
condition_operator primary
| logical_expression if expression else logical_expression
| logical_expression

-- Kevin Jennings - 2016-10-24

Comments

The syntax is unreadable as soon as conditions are nested: a if b if c else d else e

-- Tristan Gingold - 2016-11-06

Please, use the existing conditional_expressions syntax (i.e. when) so as to use consistent forms throughout the language. It is true that this syntax currently allows the expression to terminate without an unconditional fallback value. You might consider to exclude this case. However, I think it is even useful. Assume the fallback is missing and no conditional value is selected. If the associated constant, signal, attribute, ... initialization is then simply defined to be ignored, many of the use cases that are presented to justify conditional compilation would actually be taken care of in a much more VHDL-like manner.

-- Thomas Preusser - 2016-11-21

@Thomas, parsing if ... else is a better solution for the parser. The when ... else syntax allows e.g. waveforms. Using if ... else restricts the possible parser branches to logical_expressions.

-- Patrick Lehmann - 2016-12-09

It appears this syntax doesn't allow choosing between three or more options. I would prefer the existing when ... else syntax (without waveforms) or importing the Ada if ... elsif ... else ... syntax. If we borrow from Ada, we may as well bring along the case expression form as well.

-- Ryan Hinton - 2016-12-13

Reply to my own issue: three or more options are possible by using a parenthesized expression after the else.

-- Ryan Hinton - 2016-12-14

@Patrick, I do not see how the name of the keyword (if or when) within the same grammatical structure would effect the parser. Even if it would, introducing another syntax for an essentially existing concept is not helpful to the language. It can only be justified if expanding the current scope of the concept is impossible.

-- Thomas Preusser - 2016-12-15

Note that the current LCS introduces a new general version of conditional expressions. The announced goal for conditionals in declarations is a mere side effect. It will also introduce a strange coexistence of alternatives when being combined with the existing conditional variable and signal assignments. y <= x0 if c0 else x1 when c1 else x2; is valid with any other choice of combining ifs and whens. They are not all semantically equivalent.

-- Thomas Preusser - 2016-12-16

I note that the proposal grammar (and above), results in requiring parentheses when doing multiple if's statements: constant A1 : integer := 1 if gVal1 else 2 (if gVal2 else 3) ;

However the following two are equivalent (the first being Tristan's example: constant A2 : integer := 1 if gVal1 if gVal2 else gVal3 else 3 ; constant A3 : integer := 1 if gVal1 (if gVal2 else gVal3) else 3 ;

I think we need to rewrite the BNF to allow A1 without parens as can currently be done with when else. And then check for ambiguity as mixing when else and if else an be exciting.

I am thinking we need to add the term if_expression a the root of the BNF: if_expression ::= expression if expression else if_expression

Then in primary change expression to if_expression: primary :: . . . | (if_expression) . . .

-- Jim Lewis - 2016-12-17

Introducing first-class conditional expressions to VHDL can be built on two established concepts:

1. Generalize the existing when-else construct known from conditional signal and variable assignments.
2. Adopt the if expressions introduced by ADA 2012.

The current LCS is a strange crossover that squeezes the new if expressions into the structure of the established VHDL when constructs. I would really prefer choosing a clean solution following exactly one of the precedents. ADA's conditional if and case expressions could certainly be adopted directly without introducing a new syntax for them.

-- Thomas Preusser - 2016-12-18