Language Change Specification for Deferred Shared Variables Proposal

Primary LCS:

This is the main LCS describing the changes to support extended deferred object classes within a package declaration.

LCS Number: LCS-2016-080a
Version: 2
Date: 18-Dec-16
Status: Ballot
Author: Brent Hayhoe
Email:  
Source Doc: Deferred Shared Variables
Summary: Enable a shared variable declaration within the same package as its associated protected type declaration
Related LCS: LCS-2016-080b

Voting Results: Cast your votes here

  • Yes:
    1. Brent Hayhoe - 2016-12-18 - Version 2
    2. Patrick Lehmann - 2016-12-31 - Version 2
    3. Thomas Preusser - 2017-01-17 - Version 2

Details of Language Change:

Key:

  • LRM text is shown between single quotes '... P1076 LRM quoted text ...'
  • Existing LRM text is shown in BLACK coloured font
  • Additional LRM text is shown in RED coloured font
  • Deleted LRM text is shown in RED with strike-through
  • In order to try and emphasize text in italic font:
    • Italic font in existing LRM text is shown in GRAY italic font
    • Italic font in new LRM text is shown in ORANGE italic font
    • Italic font in deleted LRM text is shown in ORANGE with strike-through
  • Editing instructions are shown in GREEN coloured font

LRM 4.7 Package declarations

page 30 middle

Replace the BNF productions with:


package_declaration ::=
     package identifier is
          package_header
          package_declarative_part
     end [ package ] [ package_simple_name ] ;

package_header ::=
     [ generic_clause
     [ generic_map_aspect ; ] ]

package_declarative_part ::=
     { general_package_declarative_itempart }
   | { concurrent_package_declarative_part }
   | { sequential_package_declarative_part }

general_package_declarative_part ::=
     general_package_declarative_item
concurrent_package_declarative_part ::=
     general_package_declarative_item
   | concurrent_package_declarative_item
sequential_package_declarative_part ::=
     general_package_declarative_item
   | sequential_package_declarative_item

general_package_declarative_item ::=
     subprogram_declaration
   | subprogram_instantiation_declaration
   | package_declaration
   | package_instantiation_declaration
   | nonprotected_type_declaration
   | subtype_declaration
   | protected_type_declaration
   | normal_constant_declaration
   | deferred_constant_declaration
   | signal_declaration
   | variable_declaration
   | file_declaration
   | alias_declaration
   | component_declaration
   | attribute_declaration
   | attribute_specification
   | disconnection_specification
   | use_clause
   | group_template_declaration
   | group_declaration
   | PSL_Property_Declaration
   | PSL_Sequence_Declaration

concurrent_package_declarative_item ::=
     normal_signal_declaration
   | deferred_signal_declaration
   | normal_shared_variable_declaration
   | deferred_shared_variable_declaration
   | disconnection_specification
   | PSL_Property_Declaration
   | PSL_Sequence_Declaration

sequential_package_declarative_item ::=
     normal_variable_declaration
   | deferred_variable_declaration

page 31 top

After the paragraph beginning:

'Items declared immediately within ...'

insert the following paragraph:

'For a package declaration, or package body, that appears as a library design unit, in an entity statement, in an architecture statement, or in a block statement, it is an error if a variable declaration in the declarative part of the package declaration, or package body, does not declare a shared variable.'


Replace the 4th paragraph beginning:

'For a package declaration that appears in a subprogram ...'

with the following paragraph:

'For a package declaration, or package body, that appears in a subprogram body, a process statement, or a protected type body, it is an error if a variable declaration in the package declarative part of the package declaration, or package body, declares a shared variable. Moreover, it is an error if a signal declaration, a disconnection specification, or a PSL declaration appears as a package declarative item of such a package declaration.'


Replace the 5th paragraph beginning:

'NOTE--Not all packages ...'

with the following paragraph:

'NOTE--Not all packages will have a package body. In particular, a package body is unnecessary if no subprograms, deferred constants, deferred shared variables, deferred signals, deferred variables, or protected type definitions are declared in the package declaration.'

page 31 middle

Replace the second package declaration code with:


   -- A package declaration that needs a package body:
      package TriState is
         type Tri is ('0', '1', 'Z', 'E');
         function BitVal (Value: Tri) return Bit;
         function TriVal (Value: Bit) return Tri;
         type TriVector is array (Natural range <> of Tri;
         function Resolve (Sources: TriVector) return Tri;
         constant TriA_c : Tri;
         deferred constant TriB_c : Tri;
         type Tri_pt is
            protected
               impure function Get return Tri;
               procedure Put (Value : Tri);
            end protected Tri_pt;
         deferred shared variable Tri_sv : Tri_pt;
         deferred signal Tri_s : Tri;
      end package TriState;
   -- or:
      package TriState2 is
         type Tri is ('0', '1', 'Z', 'E');
         function BitVal (Value: Tri) return Bit;
         function TriVal (Value: Bit) return Tri;
         type TriVector is array (Natural range <> of Tri;
         function Resolve (Sources: TriVector) return Tri;
         constant TriA_c : Tri;
         deferred constant TriB_c : Tri;
         type Tri_pt is
            protected
               impure function Get return Tri;
               procedure Put (Value : Tri);
            end protected Tri_pt;
         deferred variable Tri1_v : Tri;
         deferred variable Tri2_v : Tri_pt;
      end package TriState2;

LRM 4.8 Package bodies

page 31 bottom

Replace the 1st paragraph beginning:

'A package body defines ...'

with the following paragraph:

'A package body defines the bodies of subprograms and, the values of deferred constants, the declaration of deferred shared variables (or normal variables of a protected type), the initial values of deferred signals and the initial values of deferred variables (except those of a protected type) that have been declared in the interface to the package.'

page 31 bottom & 32 top

Replace the BNF productions with:


package_body ::=
     package body package_simple_name is
          package_body_declarative_part
     end [ package body ] [ package_simple_name ] ;

package_body_declarative_part ::=
     { general_package_body_declarative_itempart }
   | { concurrent_package_body_declarative_part }
   | { sequential_package_body_declarative_part }

general_package_body_declarative_part ::=
     general_package_body_declarative_item

concurrent_package_body_declarative_part ::=
     general_package_body_declarative_item
   | concurrent_package_body_declarative_item

sequential_package_body_declarative_part ::=
     general_package_body_declarative_item
   | sequential_package_body_declarative_item

general_package_body_declarative_item ::=
     subprogram_declaration
   | subprogram_body
   | subprogram_instantiation_declaration
   | package_declaration
   | package_body
   | package_instantiation_declaration
   | nonprotected_type_declaration
   | subtype_declaration
   | protected_type_declaration
   | protected_type_body
   | normal_constant_declaration
   | variable_declaration
   | file_declaration
   | alias_declaration
   | component_declaration
   | attribute_declaration
   | attribute_specification
   | use_clause
   | group_template_declaration
   | group_declaration

concurrent_package_body_declarative_item ::=
     normal_signal_declaration
   | normal_shared_variable_declaration

sequential_package_body_declarative_item ::=
     normal_variable_declaration

page 32 middle

Replace the 5th paragraph beginning:

'If a given package declaration ...'

with the following paragraph:

'If a given package declaration contains a deferred constant declaration (see 6.4.2.2), a deferred shared variable declaration (see 6.4.2.4), a deferred signal declaration (see 6.4.2.3) or a deferred variable declaration (see 6.4.2.4), then a constant declaration, a shared variable declaration, a signal declaration or a variable declaration with the same respective identifier shall appear as a declarative item in the corresponding package body. This object declaration is called the full declaration of the deferred constant, deferred shared variable, deferred signal or deferred variable. The subtype indication given in the full declaration shall lexically conform to that given in the deferred constant declaration, deferred shared variable declaration, deferred signal declaration or deferred variable declaration. If a signal declaration is present in a package body, then it is an error if the corresponding deferred signal declaration is not present in its package declaration.'

page 32 bottom

Replace the 6th paragraph beginning:

'Within a package declaration ...'

with the following paragraph:

Within a package declaration that contains the declaration of a deferred constant, and within the body of that package (before the end of the corresponding full declaration), the use of a name that denotes the deferred constant is only allowed in the default expression for a local generic, local port, or formal parameter. The result of evaluating an expression that references a deferred constant, a deferred shared variable, a deferred signal or a deferred variable before the elaboration of theits corresponding full declaration is not defined by the language.

LRM 4.10 Conformance rules

page 34 top

Replace the 3rd paragraph beginning:

'Lexical conformance is likewise ...'

with the following paragraph:

'Lexical conformance is likewise defined for subtype indications in deferred constant declarations, deferred shared variable declarations, deferred signal declarations, or deferred variable declarations.'

LRM 6.4.2.2 Constant declarations

page 67 bottom

Replace the BNF production with:


constant_declaration ::=
     normal_constant_declaration
   | deferred_constant_declaration

normal_constant_declaration ::=
     constant identifier_list : constant_subtype_indication [ := expression ] ;

deferred_constant_declaration ::=
     [ deferred ] constant identifier_list : constant_subtype_indication ;

page 67 bottom

Replace the paragraph beginning:

'If the assignment symbol ":=" followed by an expression is not present in a constant declaration, then ...'

with the following paragraph:

'If the assignment symbol ":=" followed by an expression is not present in a constant declaration, or the reserved word constant is preceded by the reserved word deferred, then the declaration declares a deferred constant. It is an error if such a constant declaration appears anywhere other than in a package declaration. The corresponding full constant declaration, which defines the value of the constant, shall appear in the body of the package (see 4.8).'

page 68 top

Add to the end of the 'Examples' list:


constant TOLER: DISTANCE := 1.5 nm;
constant PI: REAL := 3.141592;
constant CYCLE_TIME: TIME := 100 ns;
constant Propagation_Delay: DELAY_LENGTH; -- A deferred constant.
deferred constant Propagation_Delay: DELAY_LENGTH; -- A deferred constant.

LRM 6.4.2.3 Signal declarations

page 68 top

Replace the BNF productions with:


signal_declaration ::=
     normal_signal_declaration
   | deferred_signal_declaration

normal_signal_declaration ::=
     signal identifier_list : signal_subtype_indication [ signal_kind ] [ := expression ] ;

deferred_signal_declaration ::=
     deferred signal identifier_list : signal_subtype_indication [ signal_kind ] ;

signal_kind ::= register | bus

page 68 bottom

After the paragraph beginning:

'In the absence of an explicit default expression ...'

insert the following paragraph:

'If the assignment symbol ":=" followed by an expression is not present in a signal declaration and the reserved word signal is preceded by the reserved word deferred, then the declaration declares a deferred signal. It is an error if such a signal declaration appears anywhere other than in a package declaration. The corresponding full signal declaration, which defines the initial value of the signal, shall appear in the body of the package (see 4.8).'

page 69 middle

Add to the end of the 'Examples' list:

signal S: STANDARD.BIT_VECTOR (1 to 10);
signal CLK1, CLK2: TIME;
signal OUTPUT: WIRED_OR MULTI_VALUED_LOGIC;
deferred signal INPUT: BIT; -- A deferred signal.

LRM 6.4.2.4 Variable declarations

page 70 top

Replace the BNF production with:


variable_declaration ::=
     local_variable_declaration
   | shared_variable_declaration

local_variable_declaration ::=
     normal_variable_declaration
   | deferred_variable_declaration

normal_variable_declaration ::=
     [ shared ] variable identifier_list : nonprotected_subtype_indication [ := expression ] ;
   | variable identifier_list : protected_subtype_indication ;

deferred_variable_declaration ::=
     deferred variable identifier_list : subtype_indication 

shared_variable_declaration ::=
     normal_shared_variable_declaration
   | deferred_shared_variable_declaration

normal_shared_variable_declaration ::=
     shared variable identifier_list :  protected_subtype_indication ;

deferred_shared_variable_declaration ::=
     deferred shared variable identifier_list : protected_subtype_indication ;

page 70 middle

After the paragraph beginning:

'If an initial value expression appears in the declaration of a variable, ...'

insert the following two paragraphs:

'If the assignment symbol ":=" followed by an expression is not present in a variable declaration and the reserved word variable is preceded by the reserved word deferred, then the declaration declares a deferred variable. It is an error if such a variable declaration appears anywhere other than in a package declaration. The corresponding full variable declaration, which defines the initial value of the variable, shall appear in the body of the package (see 4.8).'

'If the reserved words shared variable are preceded by the reserved word deferred in a shared variable declaration, then the declaration declares a deferred shared variable. It is an error if such a shared variable declaration appears anywhere other than in a package declaration. The corresponding full shared variable declaration, which associates the method(s) and variable(s) of the corresponding protected type with the shared variable, shall appear in the body of the package (see 4.8).'

page 71 bottom

Add to the end of the 'Examples' list:

variable INDEX: INTEGER range 0 to 99 := 0;
   -- Initial value is determined by the initial value expression
variable COUNT: POSITIVE;
   -- Initial value is POSITIVE'LEFT; that is,1
variable MEMORY: BIT_MATRIX (0 to 7, 0 to 1023);
   -- Initial value is the aggregate of the initial values of each element
shared variable Counter: SharedCounter;
   -- See 5.6.2 and 5.6.3 for the definitions of SharedCounter
shared variable addend, augend, result: ComplexNumber;
   -- See 5.6.2 and 5.6.3 for the definition of ComplexNumber
variable bit_stack: VariableSizeBitArray;
   -- See 5.6.2 and 5.6.3 for the definition of VariableSizeBitArray;
type SharedCount is protected
   function get return COUNT;
   procedure set(value : COUNT);
end protected SharedCount;
   -- Protected type for deferred variable and deferred shared variable
deferred variable COUNT: POSITIVE;             -- A deferred variable.
deferred variable COUNT2: SharedCount;         -- A deferred variable.
deferred shared variable COUNT3: SharedCount;  -- A deferred shared variable.
   -- Methods and variable(s) defined in the package body

LRM 6.5.2 Interface object declarations

page 73 bottom

Replace the BNF productions with:


interface_object_declaration ::=
     interface_constant_declaration
   | interface_signal_declaration
   | interface_variable_declaration
   | interface_file_declaration

interface_constant_declaration ::=
     [ constant ] identifier_list : [ in ] constant_subtype_indication [ := static_expression ]

interface_signal_declaration ::=
     [ signal ] identifier_list : [ mode ] signal_subtype_indication [ bus ] [ := static_expression ]

interface_variable_declaration ::=
     [ variable ] identifier_list : [ mode ] nonprotected_subtype_indication [ := static_expression ]
   | [ variable ] identifier_list : inout protected_subtype_indication

interface_file_declaration ::=
     file identifier_list : file_subtype_indication

mode ::= in | out | inout | buffer | linkage

LRM 14.4.2.5 Object declarations

page 208 bottom

Replace the paragraph beginning:

'The elaboration of an object of a protected type consists ...'

with the following paragraph:

'The elaboration of an object of a protected type consists of the elaboration of the subtype indication, followed by creation of the object. Creation of the object consists of elaborating, in the order given, each of the declarative items in the protected type body. The elaboration of a deferred object of a protected type within a package declaration, defers the creation of the object until the elaboration of its full declaration within the package body. It is an error if this full declaration precedes the associated protected type body declaration.'

LRM 15.10 Reserved words

page 236

Insert the new reserved word deferred after the reserved word default in the list.

LRM Annex C Syntax summary

page 483

Replace the 'constant_declaration' BNF production with the following:


constant_declaration ::=                                                [§ 6.4.2.2]
     constant identifier_list : subtype_indication [ := expression ] ;
     normal_constant_declaration
   | deferred_constant_declaration


Insert before the 'delay_mechanism' BNF production the following:


deferred_constant_declaration ::=                                       [§ 6.4.2.2]
     [ deferred ] constant identifier_list : constant_subtype_indication ;

deferred_shared_variable_declaration ::=                                [§ 6.4.2.4]
     deferred shared variable identifier_list : protected_subtype_indication ;

deferred_signal_declaration ::=                                         [§ 6.4.2.3]
     deferred signal identifier_list : signal_subtype_indication [ signal_kind ] ;

deferred_variable_declaration ::=                                       [§ 6.4.2.4]
     deferred variable identifier_list : subtype_indication ;

page 489

Replace the 'interface_constant_declaration' BNF production with the following:


interface_constant_declaration ::=                                      [§ 6.5.2]
     [ constant ] identifier_list : [ in ] constant_subtype_indication [ := static_expression ]


Replace the 'interface_signal_declaration' BNF production with the following:


interface_signal_declaration ::=                                        [§ 6.5.2]
     [ signal ] identifier_list : [ mode ] signal_subtype_indication [ bus ] [ := static_expression ]

page 490

Replace the 'interface_variable_declaration' BNF production with the following:


interface_variable_declaration ::=                                      [§ 6.5.2]
     [ variable ] identifier_list : [ mode ] nonprotected_subtype_indication [ := static_expression ]
   | [ variable ] identifier_list : inout protected_subtype_indication

page 490

Insert before the 'logical_expression' BNF production the following:


local_variable_declaration ::=                                          [§ 6.4.2.4]
     normal_variable_declaration
   | deferred_variable_declaration

page 491

Insert before the 'null_statement' BNF production the following:


normal_constant_declaration ::=                                         [§ 6.4.2.2]
     constant identifier_list : constant_subtype_indication := expression ;

normal_shared_variable_declaration ::=                                  [§ 6.4.2.4]
     shared variable identifier_list : protected_subtype_indication ;

normal_signal_declaration ::=                                           [§ 6.4.2.3]
     signal identifier_list : signal_subtype_indication [ signal_kind ] [ := expression ] ;

normal_variable_declaration ::=                                         [§ 6.4.2.4]
     variable identifier_list : nonprotected_subtype_indication [ := expression ] ;
   | variable identifier_list : protected_subtype_indication ;

page 497

Insert before the 'shift_expression' BNF production the following:


shared_variable_declaration ::=                                         [§ 6.4.2.4]
     normal_shared_variable_declaration
   | deferred_shared_variable_declaration


Replace the 'signal_declaration' BNF production with the following:


signal_declaration ::=                                                  [§ 6.4.2.3]
     signal identifier_list : subtype_indication [ signal_kind ] [ := expression ] ;
     normal_signal_declaration
   | deferred_signal_declaration

page 500

Replace the 'variable_declaration' BNF production with the following:


variable_declaration ::=                                                [§ 6.4.2.4]
     [ shared ] variable identifier_list : subtype_indication [ := expression ] ;
     local_variable_declaration
   | shared_variable_declaration

LRM Annex I Glossary

page 563

Insert before the 'deferred constant' item the following:

'deferred: The reserved word deferred inserted at the beginning of statement declaring an object declaration of class constant, signal or the subclass shared variable, within a package declaration, defines the object as deferred and delays the analysis of the object until the associated package body is analysed.'


Replace the 'deferred constant' item with the following:

'deferred constant: A constant that is declared without an assignment symbol (:=) and its corresponding expression, or with the reserved word deferred in a package declaration. A corresponding full declaration of the constant shall exist in the package body to define the value of the constant. (6.4.2.2)'


Insert the three new 'deferred shared variable', 'deferred signal' and 'deferred variable' items after the 'deferred constant' item:

'deferred shared variable: A shared variable that is declared with the reserved word deferred in a package declaration. A corresponding full declaration of the shared variable shall exist in the package body. (6.4.2.4)'

'deferred signal: A signal that is declared with the reserved word deferred in a package declaration. A corresponding full declaration of the signal shall exist in the package body with an initial value of the signal. (6.4.2.3)'

'deferred variable: A local variable that is declared with the reserved word deferred in a package declaration. A corresponding full declaration of the local variable shall exist in the package body. (6.4.2.4)'

page 567

Replace the 'full declaration' item with the following:

'full declaration: A constant declaration, shared variable declaration, signal declaration, or variable declaration occurring in a package body with the same identifier as that of a deferred constant declaration, deferred shared variable declaration, deferred signal declaration, or deferred variable declaration in the corresponding package declaration. A full type declaration is a type declaration corresponding to an incomplete type declaration. (4.8)'

page 571

Replace the 'lexically conform' item with the following:

'lexically conform: Two subprogram specifications are said to lexically conform if, apart from certain allowed minor variations, both specifications are formed by the same sequence of lexical elements, and corresponding lexical elements are given the same meaning by the visibility rules. Lexical conformance is defined similarly for deferred constant declarations, deferred shared variable declarations, deferred signal declarations and deferred variable declarations . (4.10)'

page 578

Replace the 'shared variable' item with the following:

'shared variable: A variable accessible by more than one process. Such variables shall be of a protected type. Shared variables declared in packages can also be deferred shared variables. (6.4.2.4)'

page 579

Replace the 'signal' item with the following:

'signal: An object with a past history of values. A signal may have multiple drivers, each with a current value and projected future values. The term signal refers to objects declared by signal declarations or port declarations. Signals declared in packages can also be deferred signals. (6.4.2.3)'

page 583

Replace the 'variable' item with the following:

'variable: An object with a single current value. Variables declared in packages can also be deferred variables. (6.4.2.4)'

Comments

The production alternatives with a normal and a deferred path do not resolve unambiguously. Take the proposed update for LRM 6.4.2.2 as an example:

constant_declaration ::=
     normal_constant_declaration
   | deferred_constant_declaration
normal_constant_declaration ::=
     constant identifier_list : constant_ subtype_indication [ := expression ] ;
deferred_constant_declaration ::=
     [ deferred ] constant identifier_list : constant_subtype_indication ;

A declaration without the keyword deferred and without an initializing expression satisfies both productions. Making the expression within the normal path non-optional would fix this case easily and classify the declaration correctly.

-- Thomas Preusser - 2016-11-21

Thanks for the comment Thomas.

You have identified an error in the 'constant declaration' BNF productions which has now been corrected.

The square brackets around the initialization portion of the 'normal constant declaration' production (denoting it as optional) have now been removed.

I believe that the respective productions for those of signal, variable and shared variable are correct.

Do you concur?

-- Brent Hayhoe - 2016-11-25

Indeed, the rest appears good.

-- Thomas Preusser - 2016-11-27

Should the 'Draft' status on this LCS (as well as 80b) be removed?

-- Kevin Jennings - 2016-12-02

Yes, I was still working through some issues. I have now changed the status to 'Ballot'(?) as I thought leaving it blank wasn't sensible. (Applies to 80b as well).

-- Brent Hayhoe - 2016-12-08

This is a preliminary No because this proposal has several issues that should be addressed to make it consistent. There are at least the following issues, in no particular order:

  1. The BNF is in general extremely wordy, attempting to distinguish different cases by syntactic alternatives, frequently using an italicized part in the production to make the distinction. As a result, the productions may become ambiguous because the italicized part carries no syntactic meaning This is a departure from the current style of the LRM, where productions have been kept free of such ambiguities, and it reminiscent of the definitional style of SystemVerilog.
  2. Breaking the production for constant declaration into separate productions for normal and deferred objects is not reflected in the semantic text, which (for constants) still uses the presence/absence of the ":=" and the initial value expression to distinguish a deferred constant declaration from a regular one. My proposal to address this would be to change the current production for constant declaration to
    constant_declaration ::= [ deferred ] constant identifier_list : subtype indication [ := expression ] ;
    and adding a semantic rule immediately preceding the paragraph starting with "Formal parameters …" stating "It is an error if the reserved word deferred is present in a constant declaration that does not declare a deferred constant." No other change in the LRM would then be required.
    An alternative could be to semantically define a subclass of constants, e.g. "A constant is said to be a deferred constant if its declaration does not include the assignment symbol ":=" and the initial value expression. It is an error if the reserved word deferred is present in a constant declaration that does not declare a deferred constant." immediately after the production. The two following paragraphs then can and should make use of this newly introduced subclass.
    The same can be done with signals and likely with variables.
  3. In its current form, the semantic text for deferred signals requires both the absence of ":=" and the presence of deferred, but the syntax rules don't allow one without the other. This means the semantics are overspecified. My proposal would be to formulate this in a similar way as outlined for constant declarations, with the difference that deferred is now required for deferred signals.
  4. For variables, the two alternatives for deferred_variable_declaration are indistinguishable syntactically for a variable declaration without initial value expression. One way to avoid such issues is again to define a single production with a semantic disambiguation, e.g.
    variable_declaration ::= [ deferred ] [ shared ] variable identifier_list : subtype_indication [ := expression ] ;
    The following should then be added at the end of the paragraph defining the concept of shared variables. "A variable declared immediately within a package may optionally include the reserved word deferred; such a declaration declares a deferred variable or a deferred shared variable."
    The following should be added at the end of the paragraph starting with "If the variable declaration …": "Similarly, a variable declaration in a package that declares a deferred variable shall not have an initial value expression."
  5. The proposed change in the productions in 6.5.2 is unnecessary, and it creates a syntactic ambiguity. Expressing that variables of a protected type must have mode inout is better expressed by a semantic rule stating that "It is an error if an interface variable declaration whose subtype indication denotes a protected type has a mode other than inout." at the end of the first paragraph following the productions. The restriction that in this case no initial value expression is allowed is already stated in the LRM.
  6. I believe something needs to be stated in 14.4.2.5 about the elaboration of deferred objects. While for deferred constants it's possible to create the object at step c) because all the information necessary to do this is available, this is not the case for deferred shared variables because the guts of the protected type are unknown until after the package body has been elaborated. It's possible and even likely that deferred variables and (non-shared) signals may not need special rules, but I did not analyze that. --> Ernst's comment

-- Ernst Christen - 2016-12-11

Version 2

BNF productions of entity structures declarative items have been removed to LCS-2016-080a. They are as follows:

  • entity_declarative_part
  • architecture_declarative_part
  • block_declarative_part
  • subprogram_declarative_part
  • protected_type_body_declarative_part
  • process_declarative_part
  • primary_unit
  • secondary_unit

BNF productions of package structures declarative items have added to clarify their dependency on the package declarative region. They are as follows:

  • general_package_declarative_part
  • concurrent_package_declarative_part
  • sequential_package_declarative_part
  • general_package_body_declarative_part
  • concurrent_package_body_declarative_part
  • sequential_package_body_declarative_part

Italic prefixes have been added to the BNF entity structures declarative items mentioned above to reflect this declarative region usage.

Declarative items have been divided into a general group (declared in any package declaration), a concurrent group (declared in a package declared in a concurrent code region) and a sequential group (declared in a package declared in a sequential code region).

Answers to Ernst Christen's comments above:

There is an analysis section in the proposal Deferred Shared Variables which attempts to detail and justify these LCS modifications.

    1. Yes, the BNF descriptions have become long winded and this is an outcome of extensions to the original proposal/LCS.
    2. The syntactic alternatives have been created to more precisely define the BNF productions, specifically to avoid ambiguities. If there are any then please highlight them.
    3. You are correct in stating that the italicized parts have no syntactic meaning, however as per section 1.3.2 bullet g of the LRM, they are intended to impart semantic information. Here, they are mainly concerned with limitations on the BNF 'subtype indication' non-terminal and the (hopefully meaningful) italic prefixes indicate that the LRM text defines the exact details of these limitations in their various sections.
    4. This is not a departure from the current LRM style as these techniques are used extensively in the LRM. This LCS (pair to be precise) has been used to bring consistency by extending the use of italicized text where required.
    1. Your proposal for the BNF production of object class constant is ambiguous. It includes a conditional optional part. If you include the optional reserved word deferred, then the expression part must be omitted, i.e. it is no longer optional. Hence the expansion of the BNF productions to clarify this circumstance.
    2. The deferred reserved word is intended to be a modifier and not to define a sub-class. The deferred declaration does not declare a new class of object, it merely delays the elaboration of that object until the package body is elaborated.
    1. The BNF productions for a deferred signal require the presence of the deferred reserved word and the absence of the initialization expression. However, a normal signal declaration does not require an initialization expression, hence it is optional in the normal signal production.
    1. Your proposal for the BNF production of object class variable and object sub-class shared variable is also ambiguous. It includes a conditional optional part. If you include the optional reserved word deferred, then the expression part must be omitted, i.e. it is no longer optional. Hence the expansion of the BNF productions to clarify this circumstance. Similarly, if you include the optional reserved word shared (with or without deferred), then the expression part must be omitted, i.e. because an object with a 'protected subtype indication' cannot be initialized and it is no longer optional, hence the expansion of the BNF productions to clarify this circumstance.
    1. The italics added to the BNF productions in section 6.5.2 are to clarify the semantic use of the 'subtype indication' non-terminal. The requirements detailing this are already documented in the LRM text.
    2. The additional production detailing that object class variable may be associated with a 'protected subtype indication' and must be of mode inout adds clarity for a condition often overlooked, but already specified within the LRM text.
    3. I see no "syntactic ambiguity" in these BNF productions.
    1. I'm not sure what you mean by "(non-shared) signals". A signal 'declaration item' may appear in a package declaration. It then becomes a global object made visible by an appropriate use clause, rather than through interface associations. A signal 'declaration item' may not appear in the package body unless a deferred version is present in the package declaration. I have added some extra LRM text additions to clarify this error condition.

-- Brent Hayhoe - 2016-12-17

My original comment may not have been clear enough to describe my concerns. It is indeed true that the LRM uses italicized prefixes to the names of productions where it helps to clarify the intent, for example

constrained_array_definition ::= array index_constraint of element _subtype_indication

My concern is not so much about that (although this and the related LCS2016_080b bring it to new levels), it is about creating additional syntactic rules to disambiguate cases when the style of the LRM since its beginning has been to provide concise syntax and define different cases by means of semantic rules. This LCS proposes a complete departure from the current LRM style, but only for additions. As a result, we'll get a document that is neither fish nor fowl.

I have given an example of how the constant declaration could be modified to accommodate the proposed reserved word deferred, and I have outlined that for variable declarations and signal declarations a similar approach could be used. This approach is unambiguous if syntactic and semantic rules are both considered, as its done everywhere in the LRM, for example an alias declaration, where one production covers both object aliases and non-object aliases.

-- Ernst Christen - 2017-01-24

Topic revision: r36 - 2017-02-17 - 11:33:59 - MartinThompson
 
Copyright © 2008-2025 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback