(r10) LCS2016_094a < P1076

P1076 Web>VHDL2017>LCS2016_094a (revision 10) (raw view)~~EditAttach~~
---+ Language Change Specification for Conditional Return Statement

---++ 

| <sticky><b>LCS Number:</b></sticky> | LCS-2016-094a |
| <sticky><b>Version:</b>   </sticky> | 3 {13-Mar-2017} |
| <sticky><b>Date:</b>      </sticky> | 13-Mar-2017  |
| <sticky><b>Status:</b>    </sticky> | Voting  |
| <sticky><b>Author:</b>    </sticky> | Thomas Preusser<br />Jim Lewis |
| <sticky><b>Email:</b>     </sticky> | [[Main.ThomasPreusser]]<br /> [[Main.JimLewis]] |
| <sticky><b>Source Doc:</b></sticky> | [[ConditionalReturn][Conditional Return Statement]] |
| <sticky><b>Summary:</b>   </sticky> | Conditional Return Statement |
| <sticky><b>Dependencies:</b> </sticky> | [[LCS2016_036a][LCS036a]] |

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

Yes:
   1 %USERSIG{ThomasPreusser - 2017-02-27}%
   1 %USERSIG{RobGaddi - 2017-03-13}% - ver 2
   1 %USERSIG{PatrickLehmann - 2017-03-21}% - ver 2

No:


Abstain:
   1 %USERSIG{BrentHahoe - 2017-02-16}% - Abstain due to lack of personal time for review.
   1 %USERSIG{MartinThompson - 2017-02-17}% - Not sure I'd use this
   1 %USERSIG{JimLewis - 2017-02-27}% - version 1

---+++ Style Notes

Changes are shown in %RED%red font%ENDCOLOR%.  
Deletions are %RED%<del>crossed out</del>%ENDCOLOR%.
Editing notes in %GREEN%green font%ENDCOLOR%.

---+++ Reviewing Notes

See also alternative [[TopLCS2016_094][LCS094]].

---+++ Details of Language Change

<noautolink>

%GREEN%(Complete Context of 10.13)%ENDCOLOR%
---+++ 10.13 Return statement
---++++ edit 94a.1

A return statement is used to complete the execution of the innermost enclosing function or procedure body.
<pre>return_statement ::=
%RED%<strike>[ label : ] <b>return</b> [ expression ] ;</strike>
  plain_return_statement | value_return_statement%ENDCOLOR%
</pre> <pre>%RED%plain_return_statement ::=
  [ label : ] <b>return</b> [ <b>when</b> condition ] ;%ENDCOLOR%
</pre> <pre>%RED%value_return_statement ::=
  [ label : ] <b>return</b> conditional_or_unaffected_expression ;%ENDCOLOR%
</pre>

A return statement is only allowed within the body of a function or procedure, and it applies to the innermost enclosing function or procedure.

---++++ edit 94a.2
A return statement appearing in a procedure body shall %RED%<strike>not have</strike> be a plain return statement without%ENDCOLOR% an expression.
%RED%For the execution of the return plain statement, its condition, if present, is first evaluated. If there is a condition and its value is FALSE, the return statement
completes and the execution of the subprogram continues. Otherwise, the execution of both the return statement and the enclosing procedure is completed.%ENDCOLOR%

---++++ edit 94a.3
%GREEN%(The sentences from the original context have been re-arranged - black text is, indeed, copied but may appear out of its original order. See below for original text.)%ENDCOLOR%

A return statement appearing in a function body shall %RED%<strike>have an</strike> be a value return statement with a conditional or unaffected%ENDCOLOR% expression.
For the execution of a return %RED%value%ENDCOLOR% statement, the %RED%conditional or unaffected%ENDCOLOR% expression (if any) is first evaluated. %RED%If its value is *unaffected*, the return statement completes and the execution of the function continues. Otherwise, its <strike>The</strike>%ENDCOLOR% value %RED%<strike>of the expression</strike>%ENDCOLOR% defines the result returned by the function. The type of this expression shall be the base type of the type mark given after the reserved word *return* in the specification of the function. An error occurs at the place of the return statement if the conversion %RED%to the result subtype%ENDCOLOR% fails. %RED%Otherwise, the execution of both the return statement and the enclosing subprogram is completed.%ENDCOLOR% It is an error if %RED%the%ENDCOLOR% execution of a function completes by any means other than the execution of a return statement %RED%with an effective return value%ENDCOLOR%.

%GREEN%(Original context subsumed by the paragraph above.)%ENDCOLOR%

---++++ edit 94a.4
%RED%<strike>The value of the expression defines the result returned by the function. The type of this expression shall be the base type of the type mark given after the reserved word *return* in the specification of the function. It is an error if execution of a function completes by any means other than the execution of a return statement.</strike>%ENDCOLOR%

---++++ edit 94a.5
%RED%<strike>For the execution of a return statement, the expression (if any) is first evaluated and  converted to the result subtype. The execution of the return statement is thereby completed if the conversion succeeds; so also is the execution of the enclosing subprogram. An error occurs at the place of the return statement if the conversion fails.
</strike>%ENDCOLOR%

---++++ edit 94a.6
NOTE - If  the  expression  is  either  a  numeric  literal,  or  an  attribute  that  yields  a  result  of  type  <i>universal_integer</i>  or  <i>universal_real</i>, then an implicit conversion of the result is performed.
<sticky>
---++++ Annex C - Syntax Summary
---++++ edit 94a.7
 %GREEN% _(Update productions and their references.)_ %ENDCOLOR%

<pre>return_statement ::=
%RED%<strike>[ label : ] <b>return</b> [ expression ] ;</strike>
  value_return_statement | plain_return_statement%ENDCOLOR% [§10.13]
</pre>

<pre>%RED%plain_return_statement ::=
  [ label : ] <b>return</b> [ <b>when</b> condition ] ; [§10.13]%ENDCOLOR%
</pre>

<pre>%RED%value_return_statement ::=
  [ label : ] <b>return</b> conditional_or_unaffected_expression ; [§10.13]%ENDCOLOR%
</pre>

<br>
---++ Comments

This LCS should name it&#39;s dependencies to the LCS 036 series. It misses changes for annex C. It also requests too many &#34;;&#34;.

Why does this LCS generate two different return statements for functions and procedures?

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


*PL*: This LCS should name it&#39;s dependencies to the LCS 036 series.

It _does_ -  in the header. Excuse the misnomer I had used for the label before.

*PL*: It misses changes for annex C.

Added. They are missing in LCS 094 as well.

*PL*: It also requests too many &#34;;&#34;.

Fixed.

*PL*: Why does this LCS generate two different return statements for functions and procedures?

Because a =conditional_or_unaffected_expression= cannot reduce to a =when condition=. Alternate suggestions to put this into a shorter grammar with a concise semantic specification are welcome.

-- %BUBBLESIG{ThomasPreusser - 2017-02-27}%


I'm against the different elaboration behaviors of functions vs. procedures and vs. other conditional flow control statements.

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


I do not see where you find a &#34;different elaboration behavior&#34;. In a way, a return statement in a function does, indeed, differ from all other control flow statements: it needs a value to work with.

Anyhow, you are welcome to be constructive, look at Rob&#39;s comments on LCS 094 and come up with a solution that you like. You will have my vote immediately if you manage to boil this down to a more concise LCS - although this one is not very long either.

-- %BUBBLESIG{ThomasPreusser - 2017-02-28}%


The current conditional control flow statements =exit= and =next= have already an optional condition. The purpose of the proposal is a language regularization.
So the third control flow statement =return= shall get a condition too. This is achieved by LCS 094.

The difference between LCS 094 and 094a is the order of elaboration.

**LCS 094**
   1 the condition is evaluated
   1 the statement is executed, if the condition results in a BOOLEAN value TRUE

Thus we can say elaboration happens from right to left. This is also true for the =next when ...= and =exit when ...= statements.

**LCS 094a:**
   1 conditions are evaluated from left to right.
   1 the first condition resulting in a BOOLEAN value of TRUE wins
   1 the statement is executed, if not unaffected

I dislike that the =return when ...= statement gets another order of evaluation then then =next= and =exit= statements.

I don't need to present a solution, because there already one: 036a + 094, but not 094a

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



This LCS need to change more paragraphs in 10.13. because it exchanges =expression= by =conditional_or_unaffected_expression=. Several text positions reference =expression=.

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


*PL*: Thus we can say elaboration happens from right to left. This is also true for the =next when ...= and =exit when ...= statements.

*TBP*: There is also no unnatural reading of the conditional =return= as suggested by this LCS. It can only be effective if a condition to the right of the keyword evaluates to true. Allowing (not demanding!) the explicit use of =unaffected= in the decision process simplifies hierarchical decision that do not have the =unaffected= case in a natural end position. This _cannot_ be achieved by LCS 036a + 094. They also require extra parentheses needlessly for an internal value selection.

*PL*: This LCS need to change more paragraphs in 10.13. because it exchanges =expression= by =conditional_or_unaffected_expression=. Several text positions reference =expression=.

*TBP*: While the term &#34;expression&#34; has never been ambiguous in the context of 10.13, I followed up on your comment and reworded the section altogether.

-- %BUBBLESIG{ThomasPreusser - 2017-03-13}%
%COMMENT%</sticky>

</noautolink>
Topic revision: r1 - 2017-09-12 - 05:48:29 - TWikiGuest
P1076