Voting and Comment History for Sequential Declaration Regions

Voting Results: Cast your votes here

Yes:

1. Jim Lewis - 11-Mar-2017 ver 1
2. Rob Gaddi - 2016-12-27 ver 1
3. Patrick Lehmann - 2016-12-31 ver 1
4. Lieven Lemiengre - 2017-01-09 ver 1
5. Farrell Ostler - 2017-01-17 ver 1
6. Thomas Preusser - 2017-01-17 ver 3
7. Martin Zabel - 2017-01-19 ver 3
8. Hendrik Eeckhaut - 2017-01-27 ver 1
9. Kevin Jennings - 2017-2-9 Ver 2

No:

Abstain:

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

Revision Notes

Revision 3: 11-Mar-2017

• Added path element for INSTANCE_NAME and PATH_NAME

Revision 2: 06-Feb-2017

• Added section on Scope (12.1)

Revision 1: 24-Dec-2016

Comments

Consider rewording 10.15:

If a label appears at the end of an sequential block statement, it shall repeat the sequential block label.

-- Thomas Preusser - 2016-12-27

Correction done.

-- Jim Lewis - 2017-01-05

This sentence should be clarified even more:

A sequential block statement encloses a sequence of sequential statements.

-- Martin Zabel - 2017-01-09

Could we eliminate the productions for sequential_block_declarative_part and sequential_block_statement_part and replace their appearance in sequential_block_statement with {process_declarative_item} and {sequential_statement}, respectively? This makes the BNF shorter and easier to grasp.

-- Farrell Ostler - 2017-01-17

This proposal probably isn't enough. sequential if statements, loop statements & case statements should have a declarative region as well.

if condition then
block
  variable foo : tpe;
begin
  ...
end
end if;

if condition then
  variable foo : tpe;
begin
  ...
end if;

-- Lieven Lemiengre - 2017-01-19

@Lieven I'm going to prepare this until today's meeting. It should be a quick edit based in this LCS.

-- Patrick Lehmann - 2017-01-19

@MZ_Jan_09: Done. Thanks.

@FO_Jan_17: Using sequential_block_declarative_part and sequential_block_statement_part gives the text in the LRM something to talk about. Without it we have to say things like the declarative part of a sequential block statement or worse - in older parts of the LRM it talks about form 1 and form 2 - my head spins every time I see something like that.

@LL_Jan_19: Sure. However, from my perspective too many other things that need work first. I see Patrick is making LCS_2016_007a. Consider that everything you add to the language is an investment you are asking EDA vendors to make. Is it a good investment or is it the one that is going to cause them to throw up their arms and walk away? My preference would be to defer this to the next language revision.

-- Jim Lewis - 2017-01-21

Why does section 10.15 talk about execution, which is handled in section 14.6. It repeats the rules of execution.

-- Patrick Lehmann - 2017-01-21

@PL: I agree. However, the pattern in many of the similar subsections of 10 seem to do the same. If others think it should be deleted, I would be happy to, but otherwise, I would like to opt for consistency.

-- Jim Lewis - 2017-01-21

The EBNF rule sequential_block_statement_part already exists and should refer to sequence_of_statements. No need to create a new sequence list.

-- Patrick Lehmann - 2017-01-23

The rule sequential_block_declarative_part also exists as process_declarative_part.

-- Patrick Lehmann - 2017-01-23

@PL same question asked by @FO on Jan 17: Using sequential_block_declarative_part and sequential_block_statement_part give the text in the LRM something to talk about. Without it we have to say things like the declarative part of a sequential block statement or worse - in older parts of the LRM it talks about form 1 and form 2 - my head spins every time I see something like that.

Other than the above, I don't know why this pattern is preferred, however, in a casual search, all of the declarative regions and statement parts in the LRM follow the above pattern. At the end of the day, it is important to be consistent with the rest of the LRM.

  architecture_declarative_part ::= [§ 3.3.2]
      { block_declarative_item }
  architecture_statement_part ::= [§ 3.3.3]
      { concurrent_statement }
  block_declarative_part ::= [§ 11.2]
      { block_declarative_item }
  block_statement_part ::= [§ 11.2]
      { concurrent_statement }
  package_declarative_part ::= [§ 4.7]
      { package_declarative_item }
  process_declarative_part ::= [§ 11.3]
      { process_declarative_item }
  process_statement_part ::= [§ 11.3]
      { sequential_statement }
  protected_type_declarative_part ::= [§ 5.6.2]
      { protected_type_declarative_item }
  protected_type_body_declarative_part ::= [§ 5.6.3]
      { protected_type_body_declarative_item }
  sequence_of_statements ::= [§ 10.1]
      { sequential_statement }
  subprogram_declarative_part ::= [§ 4.3]
      { subprogram_declarative_item }
  subprogram_statement_part ::= [§ 4.3]
      { sequential_statement }

One thing I noted is that currently subprogram_declarative_item and process_declarative_item are one and the same. Perhaps this should be added to our some day maybe list.

-- Jim Lewis - 2017-01-23