TWiki> P1076 Web>TopLCS2016_036a>LCS2016_094a (revision 12)EditAttach

Language Change Specification for Conditional Return Statement

LCS Number: LCS-2016-094a
Version: 3 {13-Mar-2017}
Date: 13-Mar-2017
Status: Voting
Author: Thomas Preusser
Jim Lewis
Email: Main.ThomasPreusser
Main.JimLewis
Source Doc: Conditional Return Statement
Summary: Conditional Return Statement
Dependencies: LCS036a

Voting Results: Cast your votes here

Yes:

  1. Thomas Preusser - 2017-02-27
  2. Rob Gaddi - 2017-03-13 - ver 2
  3. Patrick Lehmann - 2017-03-21 - ver 2

No:

  1. Jim Lewis - 2017-02-27 - version 1

Abstain:

  1. Brent Hayhoe - 2017-02-16 - Abstain due to lack of personal time for review.
  2. Martin Thompson - 2017-02-17 - Not sure I'd use this

Style Notes

Changes are shown in red font. Deletions are crossed out. Editing notes in green font.

Reviewing Notes

See also alternative LCS094.

Details of Language Change

(Complete Context of 10.13)

10.13 Return statement

A return statement is used to complete the execution of the innermost enclosing function or procedure body.

return_statement ::=
[ label : ] return [ expression ] ;
  plain_return_statement | value_return_statement
plain_return_statement ::=
  [ label : ] return [ when condition ] ;
value_return_statement ::=
  [ label : ] return conditional_or_unaffected_expression ;

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

A return statement appearing in a procedure body shall not have be a plain return statement without an expression. 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.

(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.)

A return statement appearing in a function body shall have an be a value return statement with a conditional or unaffected expression. For the execution of a return value statement, the conditional or unaffected expression (if any) is first evaluated. If its value is unaffected, the return statement completes and the execution of the function continues. Otherwise, its 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. An error occurs at the place of the return statement if the conversion to the result subtype fails. Otherwise, the execution of both the return statement and the enclosing subprogram is completed. It is an error if the execution of a function completes by any means other than the execution of a return statement with an effective return value.

(Original context subsumed by the paragraph above.)

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.

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.

NOTE - If the expression is either a numeric literal, or an attribute that yields a result of type universal_integer or universal_real, then an implicit conversion of the result is performed.

Annex C - Syntax Summary

(Update productions and their references.)

return_statement ::=
[ label : ] return [ expression ] ;
  value_return_statement | plain_return_statement [10.13]

plain_return_statement ::=
  [ label : ] return [ when condition ] ; [10.13]

value_return_statement ::=
  [ label : ] return conditional_or_unaffected_expression ; [10.13]


Comments

This LCS should name it's dependencies to the LCS 036 series. It misses changes for annex C. It also requests too many ";".

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

-- Patrick Lehmann - 2017-02-27

PL: This LCS should name it'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 ";".

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.

-- Thomas Preusser - 2017-02-27

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

-- Patrick Lehmann - 2017-02-28

I do not see where you find a "different elaboration behavior". 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'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.

-- Thomas Preusser - 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
  2. 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.
  2. the first condition resulting in a BOOLEAN value of TRUE wins
  3. 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

-- Patrick Lehmann - 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.

-- Patrick Lehmann - 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 "expression" has never been ambiguous in the context of 10.13, I followed up on your comment and reworded the section altogether.

-- Thomas Preusser - 2017-03-13

Edit | Attach | Print version | History: r15 < r14 < r13 < r12 < r11 | Backlinks | Raw View | Raw edit | More topic actions...
Topic revision: r12 - 2017-03-21 - 20:51:41 - PatrickLehmann
 
Copyright © 2008-2021 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback