Language Change Specification for Attributes for Enumerated Types

Voting Results: Cast your votes here

Yes:

1. Jim Lewis - 2017-01-04 ver 3

No:

1. Patrick Lehmann - 2017-01-10 - as this LCS started as a fork to propose an alternative wording, I prefer the initial LCS number, which now merges all changes (LCS 018, 018b, 018c).

2. Kevin Jennings - 2017-01-11 - Ver 3. Switched my 'Yes' vote to LCS 18 which merges LCS 18c back into LCS 18.

Abstain:

Style Notes

Changes are shown in red font. Deletions are crossed out. Editing notes in green font.

Reviewing Notes

Each edit is identified separately with edit flag: Edit1a, Edit2, Edit3, Edit1b, Edit4, Edit5

You may reference these when voting if desired.

This LCS LCS2016_18c is in direct compilation / conflict with the attributes defined in:

• LCS-2016-18 - Attributes for Enumerated Types in combination with LCS2016-18b - Algorithm to create object attributes

It should also be noted that the above two bullet point items conflict with each other - so this LCS makes it as 3 way conflict - ie: 1 must be selected the others or items from the others must be deleted.

Details of Language Change

16.2.2 Predefined attributes of types and objects

[Edit2: Add new attributes as follows ]

[Edit3: Add new POS_RANGE and POS_REVERSE_RANGE attribute as follows ]

[Edit1b: Edit existing attribute as follows ]

[Edit 4: Insert each of the following attributes after the attribute with the same name]

[Edit 5: Edit Note 1 as below]
NOTE 1 - The relationship between the values of the LEFT, RIGHT, LOW, and HIGH attributes is expressed as follows:

Comments

- Overlaps with section 16.2.3

- Does not cover all of the attributes of 16.2.3

- Does not at all address the key contribution of LCS-2016-072a ( Attributes with Function Knows Vector Size) which is to define a mechanism within a subprogram to get at the declared range for the actual that is bound to the formal parameter.

- Since this LCS lacks a way for a subprogram to get at the attributes of the actual, it then limits the FunctionsKnowsVectorSize proposal (LCS-2016-072) since it would not allow for a function to determine the bounds of the target if that target happens to be a scalar.

- Merging a section that describes attributes of types with something that attempts to describe attributes of objects doesn't add any value over current LRM with LCS-2016-072a but that was NIH I suppose.

-- Kevin Jennings - 2017-01-04

@KJ1: No. There is no overlap with 16.2.3. Section 16.2.3 applies to array types and objects of array types. These edits apply to scalar types (or a subset of scalar types) and objects of scalar types (or a subset of scalar types). Hence, while these edits make 16.2.2 and 16.2.3 converge in styles of defining the attributes for types and objects in the same place, they are non-overlapping.

@KJ2: These are in LCS-2016-18_alt which I am working on now. [Note: In version 2, these are included here and there is no "_alt" version]

@KJ3.1: This LCS is was developed based on Enumerated Attributes proposal.

@KJ3.2 Doing things with attributes in a subprogram (part of 72a) is a separate issue from creating additional attributes. Please separate your LCS 72a into 2 pieces. At this point we have 3 approaches for handling the attributes.

@KJ4: Same separate issue identified in @KJ3.2

@KJ5.1: The title of 16.2.2 is: "Predefined attributes of types and objects". Hence objects belong here. In addition, 16.2.3 is array types and objects, and the prefix in the revision of 16.2.2 makes both sections done in exactly the same style.

@KJ5.2 NIH never entered my mind. My biggest concern is getting these done correctly in a timely fashion. The attribute descriptions you provided in 72a are currently wrong.

-- Jim Lewis - 2017-01-04

Version 3: Removed the parameters from attributes as they don't belong in the short hand. Fixed color of P in P'LEFT, ...

-- Jim Lewis - 2017-01-05