LCS2016_014a < P1076

P1076 Web>VHDL2017>LCS2016_014a (2017-09-11, JimLewis) (raw view)EditAttach
---+ Language Change Specification for Access Types to protected types and Composites of Protected Types

---++ 

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

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

Yes:

   1 %USERSIG{JimLewis - 2017-02-22}% ver 3
   1 %USERSIG{LievenLemiengre - 2017-01-22}% - ver 1
   1 %USERSIG{RobGaddi - 2017-02-27}%2- ver 3 (with reservations)
   1 %USERSIG{HendrikEeckhaut - 2017-01-27}% ver 1
   1 %USERSIG{PatrickLehmann - 2017-02-21}% - ver 2

No:
   1 

Abstain:
   1 %USERSIG{BrentHahoe - 2017-02-16}% Version 1 - Abstain due to lack of personal time for review.
   1 %USERSIG{MartinThompson - 2017-02-17}% Version 1 - Abstain due to lack of personal time for review.
   1 %USERSIG{MartinZabel - 2017-02-24}% Version 3 introduced a major change. Haven't yet reviewed it.

<noautolink>
<sticky>

---+++ 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

<noautolink>

<sticky>
 

---+++ Section 5.4 Access types
---++++ Section 5.4.1 General (Access types)

---+++++ 2rd paragraph = BNF on page 53  
<pre>
access_type_definition ::= 
    access subtype_indication %RED%[ generic_map_aspect ]%ENDCOLOR%</pre>

---+++++ 3rd paragraph (BNF = 1 paragraph) on page 53  - see LCS_2014_014 - arrays of pt, ft and access types
<font color="green">[comment:  supercedes changes of LCS_2014_14 for this same paragraph]</font>

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. 
<font color="red"><strike>The designated type shall not be a file type or a protected type.</strike></font>
<font color="green">[comment:  also delete any edits to the preceding sentence done by LCS_2014_14]</font>

---+++++ 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.   
%RED%It is an error if object declared to be of an 
access type is an object of subclass shared variable.%ENDCOLOR%

---+++++ New paragraph after 4rd paragraph (BNF = 1 paragraph) on page 53  
<font color="green">[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.]</font>

<font color="red">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.</font>

---+++++ New paragraphs after above paragraphs on page 53  
<font color="red">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.
</font>

---+++++ Add new examples at end of 5.4.1 on page 53 after other examples
Examples:
<pre>
type ADDRESS is access MEMORY;
type BUFFER_PTR is access TEMP_BUFFER;

%RED%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."="
    ) ;  
%ENDCOLOR%</pre>


---++++ Section 5.4.2 Incomplete type declarations (Access types)
---+++++ 1st paragraph on page 53
<font color="green">[Comment:  The first paragraph of 5.4.2 was already edited by LCS_2016_014.
First sentence deleted and text re-written]</font>


---++++ 9.3.7 Allocators
---+++++ 2nd paragraph = BNF on page 138

allocator ::=
      new subtype_indication %RED%[ generic_map_aspect ]%ENDCOLOR%
      | new qualified_expression

---+++++ New paragraphs after 1st paragraph on page 139
<font color="red">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.
</font>

---+++++ Add new examples at end of 9.3.7 on page 139
<pre>
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.
</pre>
<pre><font color="red">

-- 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 ;
    . . .
</font></pre>

---++++ 14.4.2.3 Type declarations
---+++++ Edit paragraph 6 of 14.4.2.3 on page 207
%RED%For an access type definition whose designated type is not an
uninstantiated protected type, <del>Elaboration</del> elaboration%ENDCOLOR% 
of an access type definition consists of the elaboration of the corresponding subtype indication.
%RED%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. %ENDCOLOR%

---++++  14.6 Dynamic elaboration
---+++++ Edit List Item c) of 14.6 on page 214
%RED%<strike>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.</strike>%ENDCOLOR%

%RED%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.
%ENDCOLOR%

<br>
<br>



---+++ Comments


Section 5.4.2 restricts access types to not designate file and protected types. =&#62; strike out parts of sentence 1.

This LCS should reference other LCS&#39; because this LCS doesn&#39;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.

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

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


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

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


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

&#34;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.&#34;

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


-- %BUBBLESIG{MartinZabel - 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 %RED%<strike>denotes an object of</strike> is appropriate for%ENDCOLOR% the protected type.

See also item g) on page 187.

-- %BUBBLESIG{MartinZabel - 2017-01-28}%


@MZ.1  I made a note to re-write the second sentence when I return to editing ok.
@MZ.s &#34;denotes an object of&#34;  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.   

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


The wording &#34;denotes an object&#34; 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 &#34;appropriate for&#34; 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?

-- %BUBBLESIG{MartinZabel - 2017-01-30}%


@MZ  Not sure why the LRM defined &#34;appropriate for&#34;   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.

-- %BUBBLESIG{JimLewis - 2017-02-20}%


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

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

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


Fixed example 1 in afterword.

-- %BUBBLESIG{PatrickLehmann - 2017-02-21}%




Posted revision 3

-- %BUBBLESIG{JimLewis - 2017-02-22}%


This will work, and I&#39;m voting yes because I too need the basic functionality here, but I&#39;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&#39;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.

-- %BUBBLESIG{RobGaddi - 2017-02-27}%
%COMMENT%</sticky>

</noautolink></sticky>

</noautolink>
Topic revision: r28 - 2017-09-11 - 17:08:47 - JimLewis
P1076