LCS_2016_007_History < P1076

P1076 Web>VHDL2017>LCS2016_007>LCS_2016_007_History (2017-04-06, JimLewis) (raw view)EditAttach
---+ Voting and Comment History for Sequential Declaration Regions

---++ 

| <sticky><b>LCS Number:</b></sticky> | LCS-2016-007 |
| <sticky><b>Version:</b>   </sticky> | 3  |
| <sticky><b>Date:</b>      </sticky> | 11-Mar-2017  |
| <sticky><b>Status:</b>    </sticky> | Voting  |
| <sticky><b>Author:</b>    </sticky> | Jim Lewis |
| <sticky><b>Email:</b>     </sticky> | [[Main.JimLewis]] |
| <sticky><b>Source Doc:</b></sticky> | [[LCS2016_007][LCS]]     [[LCS_2016_007_Examples][Examples]]      [[SequentialDeclare][Proposal]] |
| <sticky><b>Summary:</b>   </sticky> |  Sequential Declaration Regions  |

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

Yes:

   1 %USERSIG{JimLewis - 11-Mar-2017}% ver 1
   1 %USERSIG{RobGaddi - 2016-12-27}% ver 1
   1 %USERSIG{PatrickLehmann - 2016-12-31}% ver 1
   1 %USERSIG{LievenLemiengre - 2017-01-09}% ver 1
   1 %USERSIG{FarrellOstler - 2017-01-17}% ver 1
   1 %USERSIG{ThomasPreusser - 2017-01-17}% ver 3
   1 %USERSIG{MartinZabel - 2017-01-19}% ver 3
   1 %USERSIG{HendrikEeckhaut - 2017-01-27}% ver 1
   1 %USERSIG{KevinJennings - 2017-2-9}% Ver 2

No:

Abstain:
   1 %USERSIG{BrentHahoe - 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 a%RED%<del>n</del>%ENDCOLOR% sequential %RED%block%ENDCOLOR% statement, it shall repeat the sequential block label. 

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


Correction done.  

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

This sentence should be clarified even more:

A sequential block statement encloses a sequence of %RED%sequential%ENDCOLOR% statements.


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

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


This proposal probably isn&#39;t enough. sequential if statements, loop statements & case statements should have a declarative region as well.
 
<pre>
if condition then
block
  variable foo : tpe;
begin
  ...
end
end if;
</pre>
or
<pre>
if condition then
  variable foo : tpe;
begin
  ...
end if;
</pre>
it would also be more consistent with the existing concurrent statements

-- %BUBBLESIG{LievenLemiengre - 2017-01-19}%


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

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


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


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

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

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

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


The rule =sequential_block_declarative_part= also exists as =process_declarative_part=.

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

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.  

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

</noautolink>
Topic revision: r1 - 2017-04-06 - 23:26:16 - JimLewis
P1076