Language Change Specification for

LCS Number:	LCS-2016-007a
Version:	1 {24-Jan-2017} 2 {02-Feb-2017} 3 {07-Feb-2017}
Date:	07-Feb-2017
Status:	Voting
Author:	Patrick Lehmann Jim Lewis
Email:	Main.PatrickLehmann Main.JimLewis
Source Doc:	Sequential Declaration Regions
Summary:	Adds a short form for "Sequential Declaration Regions".

Voting Results: Cast your votes here

Yes:

1. Lieven Lemiengre - 2017-01-24 - ver 1
2. Hendrik Eeckhaut - 2017-01-27 ver 1
3. Yann Guidon - 2017-01-27 ver 1
4. Martin Zabel - 2017-02-08 ver 3
5. Kevin Jennings - 2017-2-7 - Ver 2
6. Patrick Lehmann - 2017-02-07 - ver 3
7. Jim Lewis - 2017-02-07 - ver 3
8. Thomas Preusser - 2017-02-07 - ver 3

No:

Abstain:

1. Brent Hayhoe - 2017-02-16 Version 3 - Abstain due to lack of personal time for review.

Style Notes

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

Reviewing Notes

Version 1:
This LCS adds a transformation rule to allow a begin reserved word in all sequential statements which support a list of nested statements.

Version 2:
Addressed Martin's comments. Added 5x: "The block statement's sequence of statements is the same sequence as in the original statement."

Version 3:
Reworded transformations. Replaced transformations in case and loop statements with a note to 10.8.

Details of Language Change

10.8 If statement

An if statement selects for execution one or none of the enclosed sequences of statements, depending on the value of one or more corresponding conditions.

if_statement ::=
  [ if_label : ]
    if condition then
      sequence_of_statements
      sequential_statement_body
    { elsif condition then
      sequence_of_statements
      sequential_statement_body }
    [ else
      sequence_of_statements
      sequential_statement_body ]
     end if [ if_label ] ;

sequential_statement_body ::=
  [ sequential_statement_declarative_part
  begin ]
    sequence_of_statements

sequential_statement_declarative_part ::=
  { process_declarative_item }

If a label appears at the end of an if statement, it shall repeat the if label. For the execution of an if statement, the condition specified after
if, and any conditions specified after elsif, are evaluated in succession (treating a final else as elsif TRUE then) until one evaluates to TRUE
or all conditions are evaluated and yield FALSE. If one condition evaluates to TRUE, then the corresponding sequence of statements is
executed; otherwise, none of the sequences of statements is executed.

If a sequential statement body contains a sequential statement declarative part, it is transformed into an equivalent sequential block statement
as follows:

• The sequential block statement does not have a label.
• The sequential block statement's declarative part contains the original sequential statement declarative part, in the original order.
• The sequential block statement's statement part contains the original sequence of statements, in the original order.

10.9 Case statement

A case statement selects for execution one of a number of alternative sequences of statements; the chosen alternative is defined by the
value of an expression.

case_statement ::=
  [ case_label : ]
    case [ ? ] expression is
      case_statement_alternative
      { case_statement_alternative }
    end case [ ? ] [ case_label ] ;

case_statement_alternative ::=
  when choices =>
    sequence_of_statements
    sequential_statement_body

A case statement shall include the question mark delimiter either in both places, in which case the case statement is called a matching case
statement, or in neither place, in which case the case statement is called an ordinary case statement.

The expression shall be of a discrete type or of a one-dimensional array type whose element base type is a character type. This type shall be
determined by applying the rules of 12.5 to the expression considered as a complete context, using the rule that the expression shall be of
a discrete type or a one-dimensional character.

NOTE 1 -- A sequential statement body that contains a sequential statement declarative part is transformed into a sequential block statement
per the rules of 10.8.

10.10 Loop statement

A loop statement includes a sequence of statements that is to be executed repeatedly, zero or more times.

loop_statement ::=
  [ loop_label : ]
    [ iteration_scheme ] loop
      sequence_of_statements
      sequential_statement_body
    end loop [ loop_label ] ;

iteration_scheme ::=
    while condition
  | for loop_parameter_specification

parameter_specification ::=
  identifier in discrete_range

If a label appears at the end of a loop statement, it shall repeat the label at the beginning of the loop statement.

Execution of a loop statement is complete when the loop is left as a consequence of the completion of the iteration scheme (see the
following), if any, or the execution of a next statement, an exit statement, or a return statement.

NOTE 1 -- A sequential statement body that contains a sequential statement declarative part is transformed into a sequential block statement
per the rules of 10.8.

Annex C

[Altered EBNF rules]

if_statement ::=
  [ if_label : ]
    if condition then
      sequence_of_statements
      sequential_statement_body
    { elsif condition then
      sequence_of_statements
      sequential_statement_body }
    [ else
      sequence_of_statements
      sequential_statement_body ]
     end if [ if_label ] ;

case_statement_alternative ::=
  when choices =>
    sequence_of_statements
    sequential_statement_body

loop_statement ::=
  [ loop_label : ]
    [ iteration_scheme ] loop
      sequence_of_statements
      sequential_statement_body
    end loop [ loop_label ] ;

[New EBNF rule]

sequential_statement_body ::=
  [ sequential_statement_declarative_part
  begin ]
    sequence_of_statements

sequential_statement_declarative_part ::=
  { process_declarative_item }

Comments

Draft

I like the idea, but I recommend to drop the [ end [ alternative_label ] ; ] part.

There is already an end in the outer structure (e.g loop, ...).

It is also unclear to me what alternative_label label should point o.

-- Hendrik Eeckhaut - 2017-01-23

Version 1

This is a neat and tremendously flexible approach! I think we should nonetheless also keep 007 so as to be able to create a declarative scope without a suitable wrapping control-flow statement at hand. In fact, I would rather refrain from adopting the short hand proposed for the case statement as this would create the first awkward situation of a begin without an end.

-- Thomas Preusser - 2017-01-24

This LCS does not replace LCS-2016-007, in contrast it relies on it. Otherwise I could not describe such a transformation. It is an extension to cover the most common use case of one seq. block statement per seq. statement.

I love end foo, but I'm against an additional end in case statement alternatives. See the case generate statement for a negative example.

-- Patrick Lehmann - 2017-01-25

I see the sequential block statement (007) as something I need infrequently. Although I like the syntax form of this, I am having a hard time convincing myself that I would actually use this, and hence, I am having a hard time justifying asking vendors to implement it.

-- Jim Lewis - 2017-01-25

I think I'm with Jim here. It seems like 007 would allow you to accomplish all this anyhow, by wrapping the if/for/while in a sequential_block_statement. Or for that matter, wrapping a sequential_block_statement inside the if/for/while. 007 exists because there are use cases that can't be met without it. Is there a similar case here?

-- Rob Gaddi - 2017-01-26

I agree with Thomas, begin without end in case statements would be awkward. Same applies to an if / elsif block followed by an elsif or else block.

The construction rules miss to copy also the sequential statements into the sequential block. Copying only the declarative part is not enough.

In the construction rules for elsif, the 1st sentence must be extended as follows (the blue part):

The equivalent if statement contains as many elsif branches as the original statement contains with the same conditions and in the same order.

-- Martin Zabel - 2017-01-30

Why should I add a rule for an optional end keyword like in generate statements, when nobody ever uses it? Every elsif, else or when has the same meaning as end. This is not Pascal, where begin .. end is equal to { ... } like in C. A begin keyword is a delimiter between the declarative part and statement part -- at least in my eyes.

-- Patrick Lehmann - 2017-01-30

Accepted, having a begin without end is just a matter of style. The other issues of my last comment still persist.

-- Martin Zabel - 2017-02-02

Two things you might consider:

TBP#1: sequential_statement_body does not quite sound right as it suggests to be a part of a single statement. Maybe, naming it sequential_section or sequential_bock_body is getting closer.

TBP#2: The semantic description is based on a transformation to a sequential block statement. This creates unnecessary dependency chains through the LRM. I would prefer a flatter hierarchy and define the semantics bottom up based on a common sequential_section or something similar that is used by both the sequential block statement and the control-flow structures. I believe that this will also create a significantly shorter update combining 007 and 007a as the description of the transformation can be dropped.

-- Thomas Preusser - 2017-02-03

TBP: sequential_statement_body does not quite sound right as it suggests to be a part of a single statement.

PL: Please see Annex C. EBNF rules with suffix _body mostly contain *_declarative_part -> begin -> statements -> end productions.

TBP: The semantic description is based on a transformation to a sequential block statement. This creates unnecessary dependency chains through the LRM.

PL: A major parts of the LRM are written as transformations. E.g. generated statements are block statements, entities are block statements as well, every concurrent assignment or concurrent procedure call is translated into a process, ...

-- Patrick Lehmann - 2017-02-03

PL: Please see Annex C. EBNF rules with suffix _body mostly contain *_declarative_part -> begin -> statements -> end productions.

TBP: Arguing this way, you would need to call it sequential_statement_list_body because it is a list and not a statement.

PL: A major parts of the LRM are written as transformations.

TBP: Sometimes transformations make life easier. Concurrent assignments are most easily described this way and a bottom-up composition is not really an option. I do not see any such advantage or even need here.

-- Thomas Preusser - 2017-02-03

TBP: Arguing this way, you would need to call it sequential_statement_list_body because it is a list and not a statement.

PL: The suffix _list is used for unordered lists; otherwise it's a sequence. Regarding the use of _body : see architecture_body, generate_statement_body, subprogram_body, package_body and finally protected_type_body. They all fit into the scheme *_declarative_part -> begin -> statements -> end.

TBP: I do not see any such advantage or even need here.

PL: You can still submit alternative LCS' until mid of February. I've written a lot of LCS'. I have to write some new LCS' and I also have to finalize three LCS' in the next two weeks. So I won't change anything, other then for technical objections.

-- Patrick Lehmann - 2017-02-03

While I like the idea, I still think this LCS requires a careful consistency check:

• The term sequential_statement_body is misleading.
• The introductory sentences of 10.8/9/10 have not been updated and reference plain sequences of sequential statements. The immediately following grammar production does not match these sentences anymore.
• 14.6 d) (-> see LCS 007) should probably mention the short forms introduced by this LCS in some way or another.
• IMHO, the transformative descriptions are horribly repetitive. Such text bloat may just become a maintenance nightmare.

-- Thomas Preusser - 2017-02-06

@TP.1 WRT names for terminals, I think sequential_statement_body is as good as any. @TP.3 The exact reason for the transformation is so satellite sections like 12.1 and 14.6 do not need to mention these. @TP.4 The current transformations are a little long. Do you have any suggestions to re-write it? Yep I am calling you out, but don't worry, I just emailed some candidate re-writes on the transformations to Patrick.

-- Jim Lewis - 2017-02-07

Jim, thank you for your comments. I must admit that I do not have a quick re-write solution available either. I am thinking about the option of introducing something like a sequential elaboration block/unit or whatever that can be re-used in a bottom-up fashion for defining the syntax and the semantics of functions, procedures, processes, sequential blocks and all its short forms. I do expect a considerable reduction of text by this approach but kind of fear the reaction on and implications of touching so many sections of the LRM. It simply may be too late to get this clean and ready at this point of time.

-- Thomas Preusser - 2017-02-07

Changed my vote to no:

1. The transformations are verbose. When I think of bullet lists, I think of one sentence per bullet.
2. The transformations do not address what happens if the construct contains a begin and not declarations.
3. If it works in the transformation, it may make sense to reuse the terminals sequential_block_declarative_part and sequential_block_statement_part (a thought I borrowed from Thomas).

For the if statement, I am thinking of a transformation such as the following: If a sequential statement body of an if, elsif, or else branch of an if statement contains either a sequential declarative part or starts with the keyword begin, an equivalent if, elsif, or else branch is constructed as follows:

• The label of the equivalent if statement is the same.
• The equivalent if statement contains one if, elsif, or else branch for each if, elsif, or else branch in the original if statement.
• The equivalent if or elsif branch has the same condition as the original if or elsif branch.
• The equivalent if, elsif, or else branch contains exactly one sequential block statement.
• The sequential block statement does not have a label.
• The sequential block statement's declarative part contains the original sequential statement declarative part, in the original order.
• The sequential block statement's statement part contains the original sequence of statements, in the original order.

Getting back to sequential_statement_body, I note that generate_statement_body also has a declarative part. So as odd an uncomfortable as it sounds, it must be ok since it is similar to generate statements.

-- Jim Lewis - 2017-02-07

@Jim: I do not quite get your reference to generate statements. They are concurrent - well with the exception of their declarative part. Is this what you are after?

-- Thomas Preusser - 2017-02-07

Thanks! This is a great compromise avoiding both a significant rewrite and extreme verbosity. Good job.

The added paragraphs in 10.9 and 10.10 are only classified as notes. This appears a little like an understatement to me. But I will not object.

PS: Fixed a few minor typos.

-- Thomas Preusser - 2017-02-08