Language Change Specification for Syntax regularization for endings

Proposal

Voting Results: Cast your votes here

Yes:

1. Ryan Hinton - 2016-12-22
2. Patrick Lehmann - 2016-12-31 - ver 1
3. Martin Zabel - 2017-01-11 - ver 1
4. Lieven Lemiengre - 2017-01-27
5. Hendrik Eeckhaut - 2017-01-27 ver 1

No:

1. Thomas Preusser - 2016-12-27 - ver1 (would support regularizing the component declaration only)
2. Farrell Ostler - 2017-01-08 -ver1
3. Martin Thompson - 2017-02-17 Version 1
4. Mark Zwolinski - 2017-02-27 Version 1. Might support for components, but otherwise seems like a backwards step.
5. Jim Lewis - 2017-02-27 -- agree that we should support this for a component only

Abstain:

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

Details of Language Change

Changes are shown in red font. Deleted text is crossed out. Editing comments are in 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.

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.

LRM Annex C Syntax Summary

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.

page 480 (pdf 494)

 block_statement ::= [§ 11.2]
    block_label :
        block [ ( guard_condition ) ] [ is ]
            block_header
            block_declarative_part
        begin
            block_statement_part
        end block [ block ] [ block_label ] ;

...

 case_generate_statement ::= [§ 11.8]
    generate_label :
        case expression generate
            case_generate_alternative
            { case_generate_alternative }
        end generate [ generate ] [ generate_label ] ;

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

page 481 (pdf 495)

 component_declaration ::= [§ 6.8]
    component identifier [ is ]
        [ local_generic_clause ]
        [ local_port_clause ]
    end component [ component ]  [ component_simple_name ] ;

page 494 (pdf 508)

 for_generate_statement ::= [§ 11.8]
    generate_label :
        for generate_parameter_specification generate
            generate_statement_body
        end generate [ generate ]  [ generate_label ] ;

page 488 (pdf 502)

 if_generate_statement ::= [§ 11.8]
    generate_label :
        if [ alternative_label : ] condition generate
            generate_statement_body
        { elsif [ alternative_label : ] condition generate
            generate_statement_body }
        [ else [ alternative_label : ] generate
            generate_statement_body ]
        end generate [ generate ] [ generate_label ] ;
    
 if_statement ::= [§ 10.8]
    [ if_label : ]
        if condition then
            sequence_of_statements
        { elsif condition then
            sequence_of_statements }
        [ else
            sequence_of_statements ]
        end if [ if ] [ if_label ] ;

page 490 (pdf 504)

 loop_statement ::= [§ 10.10]
    [ loop_label : ]
        [ iteration_scheme ] loop
            sequence_of_statements
        end loop [ loop ] [ loop_label ] ;

page 493 (pdf 507)

 physical_type_definition ::= [§ 5.2.4.1]
    range_constraint
        units
            primary_unit_declaration
            { secondary_unit_declaration }
        end units [ units ] [ physical_type_simple_name ]

page 494 (pdf 508)

 process_statement ::= [§ 11.3]
    [ process_label : ]
        [ postponed ] process [ ( process_sensitivity_list ) ] [ is ]
            process_declarative_part
        begin
            process_statement_part
        end [ postponed ] process [ process ] [ process_label ] ;

...

 protected_type_body ::= [§ 5.6.3]
    protected body
        protected_type_body_declarative_part
    end protected body [ protected body ] [ protected_type_simple name ]

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

page 495 (pdf 509)

 protected_type_declaration ::= [§ 5.6.2]
    protected
        protected_type_declarative_part
    end protected [ protected ] [ protected_type_simple_name ]

...

 record_type_definition ::= [§ 5.3.3]
    record
        element_declaration
        { element_declaration }
    end record [ record ] [ record_type_simple_name ]

-- RyanHinton - 2016-12-22

Comments

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

-- Tristan Gingold - 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.

-- Ryan Hinton - 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 ends 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 ends 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.

-- Thomas Preusser - 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).

-- Farrell Ostler - 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.

-- Jim Lewis - 2017-01-08