LCS2016_014_history < P1076

P1076 Web>VHDL2017>LCS2016_014>LCS2016_014_history (2017-07-16, JimLewis) (raw view)EditAttach
---+ Language Change Specification for Composites of Protected Types

---++ 

| <sticky><b>LCS Number:</b></sticky> | LCS-2016-014 History |
| <sticky><b>Version:</b>   </sticky> | 5 {2-Feb-2017} %BR% 4 {1-Feb-2017} %BR% 3 {1-Feb-2017} %BR% 2 {23-Jan-2017} %BR% 1 {21-Dec-2016} |
| <sticky><b>Date:</b>      </sticky> | 2-Feb-2017 |
| <sticky><b>Status:</b>    </sticky> | |
| <sticky><b>Author:</b>    </sticky> | Jim Lewis |
| <sticky><b>Email:</b>     </sticky> | [[Main.JimLewis]] |
| <sticky><b>Source Doc:</b></sticky> | [[CompositesProtectedTypes][Composites of Protected Types]] |
| <sticky><b>Summary:</b>   </sticky> | Allow Composites of Protected Types |

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

Yes:

   1 %USERSIG{JimLewis - 2-Feb-2017}% ver 5
   1 %USERSIG{RyanHinton - 2016-12-21}% - ver 1
   1 %USERSIG{TorstenMeissner - 2016-12-27}% - ver 1
   1 %USERSIG{RobGaddi - 2017-01-23}% - ver 1
   1 %USERSIG{LievenLemiengre - 2017-01-27}% - ver 2
   1 %USERSIG{MartinZabel - 2017-02-03}% - ver 5 - (I do not agree that a PT has no value, but I can live with this view.)
   1 %USERSIG{KevinJennings -2017-2-8}% - Ver 5
   1 %USERSIG{PatrickLehmann - 2016-02-21}% - ver 5

No:

Abstain:
   1. %USERSIG{BrentHahoe - 2017-02-16}%  Version 5 - Abstain due to lack of personal time for review.

---+++ Revision Notes

Revision 5: 2017-02-01
   * Rewrote parts of 5.1 again
   * Added edit to first paragraph of 5.3.1
   * Deleted added note about composites of PTs not having a value.

   Revision 4: 2017-02-01
   * Revised the text of 5.3.1 to address Ernst's concerns
   * Added an edit to 8.3 to require the prefix to denote a noncomposite element of a composite

Revision 3: 2017-02-01
   * Revised paragraph 4 of section 5.1
   * Finalized sections with "alternate edits"
   * Revised 5.3.1 to capture Ernst's concerns about elements of a protected type.

Revision 2: 2017-01-23
   * Added edit for 4th paragraph on of section 4.2.2.2 page 21, last sentence of paragraph
      * Note the edit has an "alternate edit"
   * Added "alternate edit" for 5.6.5 note 2, Alternate edit

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

The heart of the change is in 5.3.1.   Much of the rest of the LCS focuses
on making sure the rules that apply to a file type or a protected type also
to a composite containing a file type or protected type.    

My recommendation is to review the changes in 5.3.1 first and then review
the other changes.   Where I felt a comment was relevant, I used HTML
comments.   There did not seem to be a way to integrate comments/rationale
into an edit, so I put them there.    

There are a number of way to express the "a protected type or a composite
that contains a protected type".   I tended to modify them consistently with how
they were originally written.  At least one place uses the thought the type is
or contains a protected type (p60 top wrt access types).   I did not attempt
to make all of the LRM text constructed in a common manner, as I did not
know which is preferred and I certainly would not want to change text that
did not need to be modified otherwise.

Composites of file types are also included in here.  First, for the same reason
we need arrays of protected types, we also need arrays of file types.   Second,
the LRM text will be easier to write if we do both changes in one LCS.

This LCS does not address Use Model 2 arrays created in a declaration of [[CompositesProtectedTypes]].
This is an orthogonal issue that should be addressed in a separate LCS.

Also with arrays, we want to consider run time sizing of the arrays.
This would require pointers/access types. I think this something
worthy of consideration, but as a separate LCS.

<noautolink>
<sticky>
 


<br>
---+++ Comments

Author comments to document were moved into the document using green text as Ryan suggested.

Suggestion: Brent used green text on a proposal for editing instructions.  Perhaps it would be useful here.  The HTML comments don't appear when reading.

Why is it important to restrict elements of a composite type (record) to only protected types?  If I'm defining a type for a variable inside a process, there are no mutual exclusion issues.  


-- %BUBBLESIG{RyanHinton - 2016-12-19}%

Protected types do not allow assignment.   Other types do.   Hence, if we allowed mixed composites, then we will need to deal with objects that do not support assignment to object as a whole.   This would add a additional level of complexity to this LCS that I did not want to take on at this time.    As a side note, when we have interfaces done, interfaces/bundles also do not allow assignment to the entire object as a whole since the directions are individually specified.   Hence, maybe then we will have some good language and that we could leverage that would allow composites of the sort you suggest.  However, even if we take it on in the language revision, I would recommend that it is done in a separate LCS.   Also I think I have other LCS&#39; that I need to write before I would be willing to take on that change.

-- %BUBBLESIG{JimLewis - 2016-12-20}%


So we can now create a record containing a scalar element and a file element ?  Not sure this is a good idea.
What about relational operators if a subelement is a protected type (or a file type) ?

-- %BUBBLESIG{TristanGingold - 2016-12-21}%


Re: TristanGingold.  No.  That is not allowed.   Specifically in section 5.3.1 the proposal says:<br>
If a composite type contains a protected type, it shall only contain protected types or composites consisting of protected types. If a composite type contains a file type, it shall only contain file types or composites consisting of file types.

-- %BUBBLESIG{JimLewis - 2016-12-21}%


Do you have a better way of expression this?

-- %BUBBLESIG{JimLewis - 2016-12-21}%


I made a few editorial corrections as I read.  If that bugs you, I won&#39;t do it in the future.

-- %BUBBLESIG{RyanHinton - 2016-12-21}%


Thanks Ryan.   

It is interesting to note that the history view does not quite render correctly - some of the colors and strike outs are lost - fortunately it was so obviously wrong that I knew it had to be a rendering issue.  

-- %BUBBLESIG{JimLewis - 2016-12-22}%


I think clause 4.2.2.2 needs to be updated as well.

The 3rd paragraph of clause 4.2.2.2 allows that &#34;parameters whose type is an array or record&#34; are passed by copy instead of reference.

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


@MZ  Thanks.   Revision 2 adds this.   Note the alternate edits.   Like to hear comments on thos. 

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


*Regarding the alternate edits:*

For the one in section 4.2.2.2: 

I prefer the first solution with two sentences because, the first sentence defines how such a parameter is passed. I would remove &#34;shall be&#34; from the first sentence. The second sentence defines a requirement which must be fulfilled by the user.


For the one in section 5.6.2:

I prefer the first solution with &#34;conforms to the rules of this section&#34; because it does define more clearly which check is required / meant. 


*Regarding the change in section 5.1*:

I am not sure whether this change should be included in the LCS, because the value (of an instance) of a protected type is actually the value of the shared data, see also 5.6.1.


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


@MZ 4.2.2.2.   Interesting perspective on the 2 sentence approach.  I find it harder to read as I have seen many sections where the 2nd sentence of a paragraph refers to something entirely different from the first sentence.  With the IEEE style guide, the word &#34;shall&#34; is intended to convey something that is a requirement of the standard.   

@MZ 5.6.2 Thanks.

@MZ 5.1  The &#34;English&#34; in this paragraph troubles me and does not seem to be correct for composites of PT and FT.   See my email on the reflector.   



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


1076-2008 5.6.1: &#34;A protected type implements instantiatiable regions of sequential statements, each of which are guaranteed exclusive access to shared data.&#34; With composites of protected types proposed in this LCS, do the methods of a scalar subelement of a protected type object have access to just that one subelement, or can they &#34;work&#34; on all subelements? I suppose it has to be the former because a method cannot know how many elements the composite has or how they are structured. I didn&#39;t check the LRM to see whether this behavior is implied or whether it needs to be stated explicitly, but it seems worth at least a note.

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


@EC:  Each element of a composite is a separate object with of the protected type.

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


&#34;Each element of such a composite is an independent protected type. Hence, for such a composite, one process may access a method of one element while another process simultaneously accesses a method of a different element.&#34;
This isn&#39;t quite correct LRM-ese, for two reasons: it mixes types and objects, and it seems to allow methods to access elements that themselves are composite. I propose to rewrite as: 
&#34;For an object of such a composite type, each element is independent of each other element. Thus, one process may access a method of one scalar subelement of the object while another process concurrently accesses a method of a different scalar subelement.&#34;

-- %BUBBLESIG{ErnstChristen - 2017-02-02}%


Why do we need this sentence? Page 213 describes that the locking is based on the prefix of the selected name of a method call. It is at max. a note. But even if you feel such sentence is required, because the sentences on page 213 are deeply hidden, then a similar sentence is required for composites of file objects. They have the same locking mechanisms as PTs.

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


In my previous comment, I just clarified Jim&#39;s sentence. As I had stated earlier, I had not checked the LRM whether such exclusion is implied. I now did some research, and I found, in 8.3: &#34;An expanded name denotes a named entity declared immediately within an elaborated protected type if the prefix denotes an object of the protected type and the suffix is a simple name of a method whose declaration appears immediately within the protected type declaration.&#34; This allows the prefix of an expanded name to be a composite, so the question I posed arises. One possible solution to remove the issue, and in fact the one I would prefer, would restrict the prefix of such an expanded name to denote a scalar object, for example by adding a new sentence immediately following the cited text: &#34;In this case, the prefix shall denote a scalar object.&#34; This would allow the other text to become a note.

-- %BUBBLESIG{ErnstChristen - 2017-02-02}%


@EC   PTs are not scalars - they are PTs.   
The previous paragraph in section 5.3.1 talked about objects, so the wording you proposed seems to be a fit there.   Lets do that.

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


Posted revision 4.    Intended to address Ernst&#39;s concerns in section 5.3.1 and 8.3.

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


Posted revision 5 to address issues received by email. 

-- %BUBBLESIG{JimLewis - 2017-02-03}%
%COMMENT%</sticky>

</noautolink>
Topic revision: r1 - 2017-07-16 - 20:16:54 - JimLewis
P1076