(r14) LCS2016_007a < P1076

P1076 Web>VHDL2017>LCS2016_007a (revision 14) (raw view)~~EditAttach~~
---+ Language Change Specification for

---++ 

| <sticky><b>LCS Number:</b></sticky> | LCS-2016-007a |
| <sticky><b>Version:</b>   </sticky> | 1 {24-Jan-2017} %BR% 2 {02-Feb-2017} %BR% 3 {07-Feb-2017} |
| <sticky><b>Date:</b>      </sticky> | 07-Feb-2017  |
| <sticky><b>Status:</b>    </sticky> | Voting |
| <sticky><b>Author:</b>    </sticky> | Patrick Lehmann %BR% Jim Lewis |
| <sticky><b>Email:</b>     </sticky> | [[Main.PatrickLehmann]] %BR% [[Main.JimLewis]] |
| <sticky><b>Source Doc:</b></sticky> | [[SequentialDeclare][Sequential Declaration Regions]] |
| <sticky><b>Summary:</b>   </sticky> | Adds a short form for "Sequential Declaration Regions". |

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

Yes:
   1 %USERSIG{LievenLemiengre - 2017-01-24}% - ver 1
   1 %USERSIG{HendrikEeckhaut - 2017-01-27}% ver 1
   1 %USERSIG{YannGuidon - 2017-01-27}% ver 1
   1 %USERSIG{MartinZabel - 2017-02-08}% ver 3
   1 %USERSIG{KevinJennings - 2017-2-7}% - Ver 2
   1 %USERSIG{PatrickLehmann - 2017-02-07}% - ver 3
   1 %USERSIG{JimLewis - 2017-02-07}% - ver 3
   1 %USERSIG{ThomasPreusser - 2017-02-07}% - ver 3

No:
   1 

Abstain:
   1. %USERSIG{BrentHahoe - 2017-02-16}%  Version 3 - Abstain due to lack of personal time for review.

---++ Style Notes

<noautolink>

<sticky>
Changes are shown in %RED%red font%ENDCOLOR%.%BR%
Deletions are %RED%<del>crossed out</del>%ENDCOLOR%.%BR%
Editing or reviewing notes in %GREEN%green font%ENDCOLOR%.
 
---++ Reviewing Notes
*Version 1:* %BR%
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:* %BR%
Addressed Martin's comments. Added 5x: "The block statement's sequence of statements is the same sequence as in the original statement."

*Version 3:* %BR%
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.

<pre>
if_statement ::=
  [ if_label : ]
    <b>if</b> condition <b>then</b>
      %RED%<del>sequence_of_statements</del>
      sequential_statement_body%ENDCOLOR%
    { <b>elsif</b> condition <b>then</b>
      %RED%<del>sequence_of_statements</del>
      sequential_statement_body%ENDCOLOR% }
    [ <b>else</b>
      %RED%<del>sequence_of_statements</del>
      sequential_statement_body%ENDCOLOR% ]
     <b>end if</b> [ if_label ] ;

%RED%sequential_statement_body ::=
  [ sequential_statement_declarative_part
  <b>begin</b> ]
    sequence_of_statements

sequential_statement_declarative_part ::=
  { process_declarative_item }%ENDCOLOR%
</pre>


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 %BR%
if, and any conditions specified after elsif, are evaluated in succession (treating a final else as elsif TRUE then) until one evaluates to TRUE %BR%
or all conditions are evaluated and yield FALSE. If one condition evaluates to TRUE, then the corresponding sequence of statements is %BR%
executed; otherwise, none of the sequences of statements is executed.

%RED%If a sequential statement body contains a sequential statement declarative part, it is transformed into an equivalent sequential block statement %BR%
as follows:%ENDCOLOR%
   * %RED%The sequential block statement does not have a label.%ENDCOLOR%
   * %RED%The sequential block statement's declarative part contains the original sequential statement declarative part, in the original order.%ENDCOLOR%
   * %RED%The sequential block statement's statement part contains the original sequence of statements, in the original order.%ENDCOLOR%


---+++ 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 %BR%
value of an expression.

<pre>
case_statement ::=
  [ case_label : ]
    <b>case</b> [ ? ] expression <b>is</b>
      case_statement_alternative
      { case_statement_alternative }
    <b>end case</b> [ ? ] [ case_label ] ;

case_statement_alternative ::=
  <b>when</b> choices =>
    %RED%<del>sequence_of_statements</del>
    sequential_statement_body%ENDCOLOR%
</pre>

A case statement shall include the question mark delimiter either in both places, in which case the case statement is called a matching case %BR%
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 %BR%
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 %BR%
a discrete type or a one-dimensional character.

%RED%NOTE 1 -- A sequential statement body that contains a sequential statement declarative part is transformed into a sequential block statement %BR%
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.

<pre>
loop_statement ::=
  [ loop_label : ]
    [ iteration_scheme ] <b>loop</b>
      %RED%<del>sequence_of_statements</del>
      sequential_statement_body%ENDCOLOR%
    <b>end loop</b> [ loop_label ] ;

iteration_scheme ::=
    <b>while</b> condition
  | <b>for</b> loop_parameter_specification

parameter_specification ::=
  identifier <b>in</b> discrete_range
</pre>

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 %BR%
following), if any, or the execution of a next statement, an exit statement, or a return statement.

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


---+++ Annex C
%GREEN%[Altered EBNF rules]%ENDCOLOR%

<pre>
if_statement ::=
  [ if_label : ]
    <b>if</b> condition <b>then</b>
      %RED%<del>sequence_of_statements</del>
      sequential_statement_body%ENDCOLOR%
    { <b>elsif</b> condition <b>then</b>
      %RED%<del>sequence_of_statements</del>
      sequential_statement_body%ENDCOLOR% }
    [ <b>else</b>
      %RED%<del>sequence_of_statements</del>
      sequential_statement_body%ENDCOLOR% ]
     <b>end if</b> [ if_label ] ;

case_statement_alternative ::=
  <b>when</b> choices =>
    %RED%<del>sequence_of_statements</del>
    sequential_statement_body%ENDCOLOR%

loop_statement ::=
  [ loop_label : ]
    [ iteration_scheme ] <b>loop</b>
      %RED%<del>sequence_of_statements</del>
      sequential_statement_body%ENDCOLOR%
    <b>end loop</b> [ loop_label ] ;
</pre>

%GREEN%[New EBNF rule]%ENDCOLOR%
<pre>%RED%
sequential_statement_body ::=
  [ sequential_statement_declarative_part
  <b>begin</b> ]
    sequence_of_statements

sequential_statement_declarative_part ::=
  { process_declarative_item }
%ENDCOLOR%</pre>

---++ 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.

-- %BUBBLESIG{HendrikEeckhaut - 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=.

-- %BUBBLESIG{ThomasPreusser - 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&#39;m against an additional end in case statement alternatives. See the case generate statement for a negative example.

-- %BUBBLESIG{PatrickLehmann - 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.   

-- %BUBBLESIG{JimLewis - 2017-01-25}%


I think I&#39;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? 

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


<strike>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.</strike>

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):

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

-- %BUBBLESIG{MartinZabel - 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.

-- %BUBBLESIG{PatrickLehmann - 2017-01-30}%


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

-- %BUBBLESIG{MartinZabel - 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.

-- %BUBBLESIG{ThomasPreusser - 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= -&#62; =begin= -&#62; statements -&#62; 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, ...

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


*PL*: Please see Annex C. EBNF rules with suffix _body mostly contain *_declarative_part -&#62; begin -&#62; statements -&#62; 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.

-- %BUBBLESIG{ThomasPreusser - 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&#39;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= -&#62; =begin= -&#62; _statements_ -&#62; =end=.

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

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

-- %BUBBLESIG{PatrickLehmann - 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.

-- %BUBBLESIG{ThomasPreusser - 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&#39;t worry, I just emailed some candidate re-writes on the transformations to Patrick.

-- %BUBBLESIG{JimLewis - 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 <tt>function</tt>s, <tt>procedure</tt>s,
<tt>process</tt>es, sequential <tt>block</tt>s 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.

-- %BUBBLESIG{ThomasPreusser - 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.
   1 The transformations do not address what happens if the construct contains a begin and not declarations.
   1 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&#39;s declarative part contains the original sequential statement declarative part, in the original order.
   * The sequential block statement&#39;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.

-- %BUBBLESIG{JimLewis - 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?

-- %BUBBLESIG{ThomasPreusser - 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.

-- %BUBBLESIG{ThomasPreusser - 2017-02-08}%
%COMMENT%</sticky>
</noautolink>
Topic revision: r1 - 2017-04-02 - 15:22:11 - TWikiGuest
P1076