Syntax Regularization

Proposal Information

  • Who Updates: JimLewis, ...
  • Date Proposed: 2013-10-20
  • Date Last Updated: 2013-10-20
  • Priority:
  • Complexity:
  • Focus: General Language

Language Change Specification link

LCS-2016-055

Requirement Summary

Current focus on differences between Entity and Component Declarations

See Bugzilla 258

Rationale

Related Issues: None = General

Competing Issues: None at this time

Current Syntax:

Component Syntax:

component identifier [ is ]
  [ local_generic_clause ]
  [ local_port_clause ]
end component [ component_simple_name ] ;

Entity Syntax:

entity identifier is
  entity_header
  entity_declarative_part
[ begin
  entity_statement_part ]
end [ entity ] [ entity_simple_name ] ;

Proposed syntax change for Component Declarations

For components make the final "component" optional.

component identifier [ is ]
  [ local_generic_clause ]
  [ local_port_clause ]
end [component] [ component_simple_name ] ;

Proposed syntax change for Entity Declarations

For entity declarations make the "is" optional. Not as important. What I am looking for is to simplify copying an entity declaration to create a component declaration.

entity identifier [is]
  entity_header
  entity_declarative_part
[ begin
  entity_statement_part ]
end [ entity ] [ entity_simple_name ] ;

Generalisation of the proposal

To make this 'end' rule consistent throughout the specification the proposed syntax should also be applied to the following syntax rules:

process_statement

protected_type_body
protected_type_declaration
record_type_definition
simple_configuration_specification
generate_statement_body
block_configuration
block_statement
case_generate_statement
case_statement
component_configuration
component_declaration
compound_configuration_specification
for_generate_statement
if_generate_statement
if_statement
loop_statement
physical_type_definition

Possible Issues

For rule 'simple_configuration_specification' using the 'end'-keyword is optional. This might make it impossible for the compiler to determine which rule the 'end' belongs to.

Arguments FOR

Arguments AGAINST

General Comments

Syntax regularization is "busy" work and may not be worthy to do in the next revision.

-- Brent Hayhoe - 2013-10-30

One of the things I like in VHDL is its verbosity (I'm odd) and rather than adding more optional syntax, I'd rather take some away thus:

component identifier is 
  [ local_generic_clause ]
  [ local_port_clause ]
end component [ component_simple_name ] ;

and:

entity identifier is
  entity_header
  entity_declarative_part
[ begin
  entity_statement_part ]
end entity [ entity_simple_name ] ;

Reluctantly, I've refrained from suggesting that the 'simple_name' should be compulsary also.

I believe the current situation arose from maintaining backward compatability?

My suggestion would break this, but in general, do not most tools handle VHDL version compilation control?

-- /Brent Hayhoe/ - 2013-10-30

Main.RyanHinton - 2014-11-05 I think consistency is paramount in a programming language. Whenever I work on a colleague's code, I try to maintain their style as much as possible. I completely agree that I rather like VHDL's verbosity, and I have my editor configured to include all the optional keywords because I think they make the code more understandable. The more terse forms can be useful in email discussions and book examples. But most of all I want them to be consistent.

Coming from the (Visual) Basic world: I like <keyword> .... End <keyword> languages.

-- PatrickLehmann - 2016-02-19

Supporters

-- RyanHinton - 2014-11-05

-- LievenLemiengre - 2015-06-04

-- PatrickLehmann - 2016-02-19

Add your signature here to indicate your support for the proposal

Edit | Attach | Print version | History: r10 | r8 < r7 < r6 < r5 | Backlinks | Raw View | Raw edit | More topic actions...
Topic revision: r1 - 2020-02-17 - 15:34:39 - TWikiGuest
 
Copyright © 2008-2024 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback