Language Change Specification for Access Types to protected types and Composites of Protected Types

LCS Number:	LCS-2016-014a
Version:	3 {22-Feb-2017} 2 {20-Feb-2017} 1 {30-Dec-2016}
Date:	22-Feb-2017
Status:	Voting
Author:	Jim Lewis and Patrick Lehmann
Email:	Main.JimLewis and Main.PatrickLehmann
Source Doc:	Allow Access Types to Composites of Protected Types
Related To:	LCS-2016-014 LCS-2016-034 Types for examples in this section come from 034
Summary:	Allow Access Types to Protected Types and Composites of Protected Types

Voting Results: Cast your votes here

Yes:

1. Jim Lewis - 2017-02-22 ver 3
2. Lieven Lemiengre - 2017-01-22 - ver 1
3. Rob Gaddi - 2017-02-27 2- ver 3 (with reservations)
4. Hendrik Eeckhaut - 2017-01-27 ver 1
5. Patrick Lehmann - 2017-02-21 - ver 2

No:

Abstain:

1. Brent Hayhoe - 2017-02-16 Version 1 - Abstain due to lack of personal time for review.
2. Martin Thompson - 2017-02-17 Version 1 - Abstain due to lack of personal time for review.
3. Martin Zabel - 2017-02-24 Version 3 introduced a major change. Haven't yet reviewed it.

Revision Notes

Revision 3:

• Added generic_map_aspect to access types
• Added generic_map_aspect to new
• Added examples
• Afterword notes merged into examples as all became valid
• Added elaboration of access type definition
• Added elaboration of an allocator

Revision 2:

• Deleted the sentence to address Martin's concern
• Added a sentence to paragraph 3.
• Added notes about 5.4.2
• Added afterword notes

Style Notes

Changes are shown in red font. Author comments are shown in green font and are not part of the LRM text.

Reviewing Notes

This is an extension to LCS-2016-014 which allows access types to protected types, file types, and composites of protected types and file types.

Details of Language Change

Section 5.4 Access types

Section 5.4.1 General (Access types)

2rd paragraph = BNF on page 53

access_type_definition ::= 
    access subtype_indication [ generic_map_aspect ]

3rd paragraph (BNF = 1 paragraph) on page 53 - see LCS_2014_014 - arrays of pt, ft and access types

[comment: supercedes changes of LCS_2014_14 for this same paragraph]

For each access type, there is a literal null that has a null access value designating no object at all. The null value of an access type is the default initial value of the type. Other values of an access type are obtained by evaluation of a special operation of the type, called an allocator. Each such access value designates an object of the subtype defined by the subtype indication of the access type definition. This subtype is called the designated subtype and the base type of this subtype is called the designated type. The designated type shall not be a file type or a protected type. [comment: also delete any edits to the preceding sentence done by LCS_2014_14]

4rd paragraph (BNF = 1 paragraph) on page 53 - see LCS_2014_014 - arrays of pt, ft and access types

An object declared to be of an access type shall be an object of class variable. An object designated by an access value is always an object of class variable. It is an error if object declared to be of an access type is an object of subclass shared variable.

New paragraph after 4rd paragraph (BNF = 1 paragraph) on page 53

[comment: Paragraph 4 establishes that an access type is always stored in a variable. The new paragraphs establish that a pointer to a file type is a file object and that a pointer to a protected type is never a shared variable.]

If the designated type of an access type is a file type or a composite containing a file type, then a reference to the designated type references a file object.

If the designated type of an access type is a protected type or a composite containing a protected type, then a reference to the designated type references an object with a protected type.

New paragraphs after above paragraphs on page 53

When a generic map aspect is present, the subtype indication shall denote an uninstantiated protected type declared in a protected type declaration. The generic map aspect, in this case, optionally associates a single actual with each formal generic (or member thereof) in the corresponding protected type declaration. Each formal generic (or member thereof) shall be associated at most once. The generic map aspect is described in 6.5.7.2.

For an access type definition whose designated type is specified by an uninstantiated protected type and a generic map aspect there is an equivalent implicit protected type instance declaration and an access type definition whose designated type is the implicitly defined protected type instance. The implicit protected type instance is defined immediately prior to the access type declaration in the same declarative region. A reference to the access type whose designated type is is specified by an uninstantiated protected type and a generic map aspect is the same as a reference to an access type whose designated type is an explicitly declared protected type instance. The implicitly defined protected type instance declaration does not have a simple name.

The designated type of an access type may denote an uninstantiated protected type without a generic map aspect. It is an error if a generic map aspect is present and the subtype indication is not an uninstantiated protected type.

Add new examples at end of 5.4.1 on page 53 after other examples

Examples:

type ADDRESS is access MEMORY;
type BUFFER_PTR is access TEMP_BUFFER;

type SB_Ptr_Type_slv is access ScoreBoardPType_slv ;
  -- ScoreBoardPType_slv is defined in 5.6.4
  
type SB_Generic_Ptr_Type is access ScoreBoardGenericPType ;
  -- access to uninstantiated protected types is allowed
  -- ScoreBoardGenericPType is defined in 5.6.2

type SB_Ptr_Type_int is access ScoreBoardGenericPType 
    generic map (
        ExpectedType    => integer,  
        ActualType      => integer,  
        check           => std.standard."="
    ) ;  

Section 5.4.2 Incomplete type declarations (Access types)

1st paragraph on page 53

[Comment: The first paragraph of 5.4.2 was already edited by LCS_2016_014. First sentence deleted and text re-written]

9.3.7 Allocators

2nd paragraph = BNF on page 138

allocator ::= new subtype_indication [ generic_map_aspect ] | new qualified_expression

New paragraphs after 1st paragraph on page 139

When a generic map aspect is present, the subtype indication shall denote an uninstantiated protected type declared in a protected type declaration. The generic map aspect, in this case, optionally associates a single actual with each formal generic (or member thereof) in the corresponding protected type declaration. Each formal generic (or member thereof) shall be associated at most once. The generic map aspect is described in 6.5.7.2.

For an allocator whose type is specified by an uninstantiated protected type and generic map aspect there is an equivalent implicit protected type instance declaration and an allocator whose subtype indication is the implicitly defined protected type instance. The implicit protected type instance is defined in the delarative region that immediately encloses the allocator. A reference to the variable whose designated type is the uninstantiated protected type is the same as a reference to a variable declaration whose designated type is an explicitly declared protected type instance. The implicitly defined protected type instance declaration does not have a simple name.

It is an error if the subtype for an allocator denotes an uninstantiated protected type and a formal generic does not get a value through either association or a default value. It is an error if a generic map aspect is present and the subtype indication is not an uninstantiated protected type.

Add new examples at end of 9.3.7 on page 139

Examples:
new NODE                       -- Takes on default initial value.
new NODE'(15 ns, null)         -- Initial value is specified.
new NODE'(Delay => 5 ns,
          \Next\=> Stack)      -- Initial value is specified.
new BIT_VECTOR'("00110110")    -- Constrained by initial value.
new STRING (1 to 10)           -- Constrained by index constraint.
new STRING                     -- Illegal: must be constrained.

-- Example using a generic map aspect with new:
process 
  -- Using types defined in 5.4.1
    variable SB_Ptr_slv     : SB_Ptr_Type_slv ;
    variable SB_Generic_Ptr : SB_Generic_Ptr_Type ;
    variable SB_Ptr_int     : SB_Ptr_Type_int ;
begin
    . . . 
    SB_Ptr_slv := new ScoreBoardPType_slv ;
    
    SB_Generic_Ptr := new ScoreBoardGenericPType generic map (
            ExpectedType    => std_logic_vector,  
            ActualType      => std_logic_vector,  
            check           => std_match
        ) ;
        
    SB_Ptr_slv := new SB_Ptr_Type_int'DESIGNATED_TYPE ;
    . . .

14.4.2.3 Type declarations

Edit paragraph 6 of 14.4.2.3 on page 207

For an access type definition whose designated type is not an uninstantiated protected type, Elaboration elaboration of an access type definition consists of the elaboration of the corresponding subtype indication. For a access type definition whose designated type is specified by an uninstantiated protected type and a generic map aspect, elaboration consists of elaborating the equivalent implicit protected type instance declaration and elaborating the access type definition whose designated type is the implicitly defined protected type instance. For an access type definition whose designated is specified by an uninstantiated protected type but does not have a generic map aspect, elaboration consists of elaborating the uninstantiated protected type.

14.6 Dynamic elaboration

Edit List Item c) of 14.6 on page 214

c) Evaluation of an allocator that contains a subtype indication involves the elaboration of the subtype indication prior to the allocation of the created object.

c) For an allocator that contains a subtype indication other than an uninstantiated protected type, evaluation of the allocator involves the elaboration of the subtype indication prior to the allocation of the created object. For an allocator that contains a subtype indication that is an uninstantiated protected type subtype indication, evaluation of the allocator involves the elaboration of the equivalent implicit protected type instance declaration and evaluation of the allocator whose subtype indication is the implicitly defined protected type instance.

Comments

Section 5.4.2 restricts access types to not designate file and protected types. => strike out parts of sentence 1.

This LCS should reference other LCS' because this LCS doesn't allow creation of composites with file and protected types. Access types can only be created by type allocation. This LCS or any other referenced LCS should handle alocators for protected types and allocators for composite types containing file and protected types.

-- Patrick Lehmann - 2017-01-21

Needs to consider how to create a pointer to a PT with generics. Without modifications, can do an instance of the PT and then new. But should we be able to do the generic map in the new. Do we need text that allows an instance of a PT to be used as claimed above.

-- Jim Lewis - 2017-01-21

Consider how pointers and files interact to dynamically size and perhaps resize arrays of files

-- Jim Lewis - 2017-01-24

I have some questions regarding this new paragraph after the 4th paragraph on page 4:

"If the designated type of an access type is a protected type or a composite containing a protected type, then a reference to the designated type references an object with a protected type. Furthermore since access types are regular variables, such an object is never a shared variable."

1. Which object is meant in the 2nd sentence? That of the protected type?
2. If yes, which permissions and/or prohibitions are enforced by the 2nd sentence?

-- Martin Zabel - 2017-01-28

I think, clause 12.3, 4th paragraph, item s) on page 188 needs to be updated as well:

s) For a subprogram declared immediately within a given protected type declaration: at the place of the suffix in a selected name whose prefix denotes an object of is appropriate for the protected type.

See also item g) on page 187.

-- Martin Zabel - 2017-01-28

@MZ.1 I made a note to re-write the second sentence when I return to editing ok. @MZ.s "denotes an object of" is the same terminology the LRM uses in other places what the protected type is the prefix. I am trying to main consistency with that.

As an addendum, "denotes an object of" means that the prefix identifies an object that is a protected type.

-- Jim Lewis - 2017-01-29

The wording "denotes an object" is used in the LRM only for object aliases and protected types. Especially for the latter, there is no access type in the VHDL-2008.

The term "appropriate for" is defined in clause 8.1 (page 107) as:

A prefix is said to be appropriate for a type in either of the following cases:

• The type of the prefix is the type considered.
• The type of the prefix is an access type whose designated type is the type considered.

This is what we want for clause 12.3, 4th paragraph, item s) on page 188, or not?

-- Martin Zabel - 2017-01-30

@MZ Not sure why the LRM defined "appropriate for" Also from 8.1 Names can denote declared entities, whether declared explicitly or implicitly. Names can also denote the following: ? Objects denoted by access values ? Methods (see 5.6.2) of protected types ? Subelements of composite objects ? Subelements of composite values ? Slices of composite objects ? Slices of composite values ? Attributes of any named entity

Hence, it would seem that if the text is appropriate for protected types, then it is also appropriate for pointers to protected types.

-- Jim Lewis - 2017-02-20

@Jim: It seems that I got tricked by the LRM. The paragraph I have cited from clause 8.1 defines "appropriateness for a type", but we talking about "objects", of course.

-- Martin Zabel - 2017-02-20

Updated to revision 2. @Martin, I deleted the sentence that concerned you and added a sentence to paragraph 3 which conveys the same thought, hopefully more concisely.

-- Jim Lewis - 2017-02-21

Fixed example 1 in afterword.

-- Patrick Lehmann - 2017-02-21

Posted revision 3

-- Jim Lewis - 2017-02-22

This will work, and I'm voting yes because I too need the basic functionality here, but I'm concerned that the addition of the generic maps into things may lead to some very difficult to read code, in a way that only allowing access to fully instantiated protected types keeps it locked down. Specifically, by allowing the instantiation to wait all the way down to the allocator, it means that you can slew a given pointer back and forth between several different variations of a single protected type. Here there be some seriously ill-tempered dragons.

I'd feel better about this if you had to nail down the fully instantiated version as an explicitly declared (sub?)type, and then create an access to it.

-- Rob Gaddi - 2017-02-27