(r13) TopLCS2016_055 < P1076

P1076 Web>Vhdl2019CollectedRequirements>SyntaxRegularlization>TopLCS2016_055 (revision 13) (raw view)~~EditAttach~~
---+ Language Change Specification for Syntax regularization for endings
---+ Proposal

---++ 

| <sticky><b>LCS Number:</b></sticky> | LCS-2016-055 |
| <sticky><b>Version:</b></sticky>  | 1 |
| <sticky><b>Date:</b></sticky>  | 22-Dec-2016 |
| <sticky><b>Status:</b></sticky>  | Voting |
| <sticky><b>Author:</b></sticky>  | Ryan Hinton |
| <sticky><b>Email:</b></sticky>  | [[Main.RyanHinton]] |
| <sticky><b>Source Doc:</b></sticky> | [[SyntaxRegularlization][Syntax regularization - end]] <!--proposal page spelling is not mine--> |
| <sticky><b>Summary:</b></sticky>  | Make ends of things have a similar syntax for what is required and optional. |

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

Yes:
   1 %USERSIG{RyanHinton - 2016-12-22}%
   1 %USERSIG{PatrickLehmann - 2016-12-31}% - ver 1
   1 %USERSIG{MartinZabel - 2017-01-11}% - ver 1
   1 %USERSIG{LievenLemiengre - 2017-01-27}%
   1 %USERSIG{HendrikEeckhaut - 2017-01-27}% ver 1

No:
   1 %USERSIG{ThomasPreusser - 2016-12-27}% - ver1 (would support regularizing the *component* declaration only)
   1 %USERSIG{FarrellOstler - 2017-01-08}% -ver1
   1 %USERSIG{MartinThompson - 2017-02-17}% Version 1
   1 %USERSIG{MarkZwolinski - 2017-02-27}% Version 1. Might support for components, but otherwise seems like a backwards step.
   1 %USERSIG{JimLewis - 2017-02-27}% -- agree that we should support this for a component only

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

---+++ Details of Language Change

Changes are shown in %RED%red font%ENDCOLOR%.  Deleted text is %RED%<del>crossed out</del>%ENDCOLOR%.  Editing comments are in %GREEN%green%ENDCOLOR%.

%GREEN%(rhinton:) I didn't touch the configuration rules because the proposal mentioned a possible ambiguity in this area.  I am happy for someone to review and suggest which rules can be optional down to the =end= keyword.  Skipped: =block_configuration=, =component_configuration=, =compound_configuration_specification=, and =simple_configuration_specification=.  %ENDCOLOR%

%GREEN%Also mentioned on the proposal page in the "generalization" section is the =generate_statement_body=.  I didn't change this production because the ending is already all optional.  It would make the grammar more regular to make this =end= required, but it would be a serious break of backward compatibility.%ENDCOLOR%

---++++ LRM Annex C Syntax Summary

%GREEN%Following are the changes for the syntax sumary in the annex.  Each production references the section of the text where it also *needs to be changed*.  Since the productions and changes are identical, I specified only one for easier reviewing.%ENDCOLOR%

---+++++ page 480 (pdf 494)
<pre> block_statement ::= [§ 11.2]
    <i>block</i>_label :
        <b>block</b> [ ( <i>guard</i>_condition ) ] [ <b>is</b> ]
            block_header
            block_declarative_part
        <b>begin</b>
            block_statement_part
        <b>end</b> %RED%<del><b>block</b></del> [ <b>block</b> ]%ENDCOLOR% [ <i>block</i>_label ] ;

...

 case_generate_statement ::= [§ 11.8]
    <i>generate</i>_label :
        <b>case</b> expression <b>generate</b>
            case_generate_alternative
            { case_generate_alternative }
        <b>end</b> %RED%<del><b>generate</b></del> [ <b>generate</b> ]%ENDCOLOR% [ <i>generate</i>_label ] ;

 case_statement ::= [§ 10.9]
    [ <i>case</i>_label : ]
        <b>case</b> [ ? ] expression <b>is</b>
            case_statement_alternative
            { case_statement_alternative }
        <b>end</b> %RED%<del><b>case</b></del> [ <b>case</b> ]%ENDCOLOR% [ ? ] [ <i>case</i>_label ] ;
</pre>

---+++++ page 481 (pdf 495)
<pre> component_declaration ::= [§ 6.8]
    <b>component</b> identifier [ <b>is</b> ]
        [ <i>local</i>_generic_clause ]
        [ <i>local</i>_port_clause ]
    <b>end</b> %RED%<del><b>component</b></del> [ <b>component</b> ] %ENDCOLOR% [ <i>component</i>_simple_name ] ;
</pre>

---+++++ page 494 (pdf 508)
<pre> for_generate_statement ::= [§ 11.8]
    <i>generate</i>_label :
        <b>for</b> <i>generate</i>_parameter_specification <b>generate</b>
            generate_statement_body
        <b>end</b> %RED%<del><b>generate</b></del> [ <b>generate</b> ] %ENDCOLOR% [ <i>generate</i>_label ] ;
</pre>

---+++++ page 488 (pdf 502)
<pre> if_generate_statement ::= [§ 11.8]
    <i>generate</i>_label :
        <b>if</b> [ <i>alternative</i>_label : ] condition <b>generate</b>
            generate_statement_body
        { <b>elsif</b> [ <i>alternative</i>_label : ] condition <b>generate</b>
            generate_statement_body }
        [ <b>else</b> [ <i>alternative</i>_label : ] <b>generate</b>
            generate_statement_body ]
        <b>end</b> %RED%<del><b>generate</b></del> [ <b>generate</b> ]%ENDCOLOR% [ <i>generate</i>_label ] ;
    
 if_statement ::= [§ 10.8]
    [ <i>if</i>_label : ]
        <b>if</b> condition <b>then</b>
            sequence_of_statements
        { <b>elsif</b> condition <b>then</b>
            sequence_of_statements }
        [ <b>else</b>
            sequence_of_statements ]
        <b>end</b> %RED%<del><b>if</b></del> [ <b>if</b> ]%ENDCOLOR% [ <i>if</i>_label ] ;
</pre>

---+++++ page 490 (pdf 504)
<pre> loop_statement ::= [§ 10.10]
    [ <i>loop</i>_label : ]
        [ iteration_scheme ] <b>loop</b>
            sequence_of_statements
        <b>end</b> %RED%<del><b>loop</b></del> [ <b>loop</b> ] [ <i>loop</i>_label ] ;
</pre>

---+++++ page 493 (pdf 507)
<pre> physical_type_definition ::= [§ 5.2.4.1]
    range_constraint
        <b>units</b>
            primary_unit_declaration
            { secondary_unit_declaration }
        <b>end</b> %RED%<del><b>units</b></del> [ <b>units</b> ]%ENDCOLOR% [ <i>physical_type</i>_simple_name ]
</pre>

---+++++ page 494 (pdf 508)
<pre> process_statement ::= [§ 11.3]
    [ process_label : ]
        [ <b>postponed</b> ] <b>process</b> [ ( process_sensitivity_list ) ] [ <b>is</b> ]
            process_declarative_part
        <b>begin</b>
            process_statement_part
        <b>end</b> [ <b>postponed</b> ] %RED%<del><b>process</b></del> [ <b>process</b> ]%ENDCOLOR% [ process_label ] ;

...

 protected_type_body ::= [§ 5.6.3]
    <b>protected</b> <b>body</b>
        protected_type_body_declarative_part
    <b>end</b> %RED%<del><b>protected</b> <b>body</b></del> [ <b>protected</b> <b>body</b> ]%ENDCOLOR% [ protected_type_simple name ]
</pre>

%GREEN%(Similar to the package body ending, the "protected body" ending is either all present or all absent.  The "protected" and "body" keywords are not allowed without the other.)%ENDCOLOR%

---+++++ page 495 (pdf 509)
<pre> protected_type_declaration ::= [§ 5.6.2]
    <b>protected</b>
        protected_type_declarative_part
    <b>end</b> %RED%<del><b>protected</b></del> [ <b>protected</b> ]%ENDCOLOR% [ protected_type_simple_name ]

...

 record_type_definition ::= [§ 5.3.3]
    <b>record</b>
        element_declaration
        { element_declaration }
    <b>end</b> %RED%<del><b>record</b></del> [ <b>record</b> ]%ENDCOLOR% [ record_type_simple_name ]
</pre>

-- Main.RyanHinton - 2016-12-22

---++ <a name="Comments"></a>Comments

Personally I don't really like the simplification for statements, as they were coherent.  IMHO.

-- %BUBBLESIG{TristanGingold - 2016-12-23}%

@Thomas and @Tristan: Do you have technical reasons for not regularizing all of these end sequences (e.g. grammar ambiguity), or is it just preference?

We could vote independently for the component change, for all declarations, statements, instantiations, etc.  It's certainly easier to make more things optional later than to make currently optional things required later.

As I said on the proposal page, I like and use the verbose forms.  Like Brent suggested, I would be happy for the identifier to be required, too.  But once some of the pieces become optional in some settings, I would rather have them all be optional.  I'm imagining explaining to a coworker that since it's always been consistent for statements, we made the ending part optional only for declarations.  And seeing the look in his eyes that says,

   * That's a dumb distinction, and
   * I'm never going to be able to remember that rule.

I've been complaining to my coworkers that !SystemVerilog is crazy because the syntax changes between coverage vs. assertions vs. normal HDL code, etc.  We can be just like SV and define one pattern for statements and another for declarations.  But I would rather have it as consistent as possible throughout as much of the language as possible.  

-- %BUBBLESIG{RyanHinton - 2016-12-27}%

I consider the optional =*end* [ *entity|function|procedure* ]= syntax a historic mistake and would not want to give up the proper named bracketing throughout the language to make up for it. This bracketing is especially valuable for statements including *if*, *case*, *loop* and *generate* as these are regularly nested in several levels. Error reporting by many tools is bad enough. It will only worsen when the anchors provided by the named <b>end</b>s are disappearing. And they will disappear as soon as it is allowed.

With respect to teaching, my experience is that students are not at all puzzled by the named <b>end</b>s but rather by the fact that the obviously very closely related *entity* and *component* syntaxes differ in this respect. This is why I would support this single regularization. But I would surely not touch deeply nestable statements.

-- %BUBBLESIG{ThomasPreusser - 2017-01-03}%

I am opposed to removing the ending keywords from statements. Doing so would remove value while giving VHDL language implementors work to do, a lose/lose outcome.

I agree that the ending keyword for component declarations should be made optional. That would be enough for me but I would not resist a consensus taking the position that ending keywords are optional for all non-statements (and, of course, required for all statements).

-- %BUBBLESIG{FarrellOstler - 2017-01-08}%

For me, fixing component will be sufficient.   I like being able to cut an entity and paste it as a component with a simple rule.

I was motivated to change "end if" since many ask why elsif and not endif?   However, that is not a big issue.  It is simple enough to explain it is "end if" because that is the style of end and elsif due to the "dangling if" language design issue.  

-- %BUBBLESIG{JimLewis - 2017-01-08}%
%COMMENT%
Topic revision: r1 - 2017-03-06 - 09:50:31 - TWikiGuest
P1076