Language Change Specification for Composites of Protected Types

Voting Results: Cast your votes here

Yes:

1. Jim Lewis - 2-Feb-2017 ver 5
2. Ryan Hinton - 2016-12-21 - ver 1
3. Torsten Meissner - 2016-12-27 - ver 1
4. Rob Gaddi - 2017-01-23 - ver 1
5. Lieven Lemiengre - 2017-01-27 - ver 2
6. Martin Zabel - 2017-02-03 - ver 5 - (I do not agree that a PT has no value, but I can live with this view.)
7. Kevin Jennings -2017-2-8 - Ver 5
8. Patrick Lehmann - 2016-02-21 - ver 5

No:

Abstain:

1. Brent Hayhoe - 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.

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.

-- Ryan Hinton - 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' that I need to write before I would be willing to take on that change.

-- Jim Lewis - 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) ?

-- Tristan Gingold - 2016-12-21

Re: TristanGingold. No. That is not allowed. Specifically in section 5.3.1 the proposal says:
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.

-- Jim Lewis - 2016-12-21

Do you have a better way of expression this?

-- Jim Lewis - 2016-12-21

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

-- Ryan Hinton - 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.

-- Jim Lewis - 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 "parameters whose type is an array or record" are passed by copy instead of reference.

-- Martin Zabel - 2017-01-22

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

-- Jim Lewis - 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 "shall be" 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 "conforms to the rules of this section" 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.

-- Martin Zabel - 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 "shall" is intended to convey something that is a requirement of the standard.

@MZ 5.6.2 Thanks.

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

-- Jim Lewis - 2017-01-29

1076-2008 5.6.1: "A protected type implements instantiatiable regions of sequential statements, each of which are guaranteed exclusive access to shared data." 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 "work" 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'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.

-- Ernst Christen - 2017-01-30

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

-- Jim Lewis - 2017-02-01

"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." This isn'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: "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."

-- Ernst Christen - 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.

-- Patrick Lehmann - 2017-02-02

In my previous comment, I just clarified Jim'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: "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." 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: "In this case, the prefix shall denote a scalar object." This would allow the other text to become a note.

-- Ernst Christen - 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.

-- Jim Lewis - 2017-02-02

Posted revision 4. Intended to address Ernst's concerns in section 5.3.1 and 8.3.

-- Jim Lewis - 2017-02-02

Posted revision 5 to address issues received by email.

-- Jim Lewis - 2017-02-03