Language Change Specification for Attributes for Enumerated Types

Voting Results:

1. Patrick Lehmann - 2017-01-03 - ver 2
2. Jim Lewis - 2017-01-11 - ver 2
3. Martin Zabel - 2017-01-11 - ver 2
4. Thomas Preusser - 2017-01-13 - ver 2
5. Lieven Lemiengre - 2017-01-27 - ver 2
6. Hendrik Eeckhaut - 2017-01-27 ver 2
7. Rob Gaddi - 2017-02-09 - ver 2

No:

1. Kevin Jennings - 2017-2-3 - Approved with Kevin's dissenting vote. Ver 2. With LCS72a being rejected, there is no defined use case for this LCS. The original proposal did not define an actual use case so all that is accomplished is to allow for two different ways to do the same thing (i.e. Obj'attribute instead of Obj'subtype'attribute). Not an improvement to the language, rather a detriment.

Abstain:

1. Brent Hayhoe - 2017-02-16 Version 2 - Abstain due to lack of personal time for review.

Revisions

• Consolidated LCS 018 series.

Version 1: 03-Jan-2017

• Initial LCS

Comments

Version 1

My no vote is based on moving objects to a new section

-- Jim Lewis - 2017-01-04

JL: My no vote is based on moving objects to a new section

PL: Moving text into the "correct" sub-section doesn't break any LRM rules. All references are for 16.2 never for 16.2.x. Even if so, such changes are solved by the type setting system by named labels and named references. I see no issue in this cleanup. O'SUBTYPE is in no relation to T'XXX attributes, other then someone attached a leftover attribute to the nearest fitting headline. So in my eyes, we should clean it up and spend a separate sub-section for object attributes.

-- Patrick Lehmann - 2017-01-04

Note that the new section numbering is conflicting with LCS-2016-072a. If both are approved, then would need to resolve the final section numbering.

-- Kevin Jennings - 2017-01-04

KJ: Note that the new section numbering is conflicting with LCS-2016-072a.

PL: Thanks for the hint. I think this is the work of an editor :). But good to know where conflicts might arise. I can adjust my LCS if LCS-2017-072a gets approved before mine

-- Patrick Lehmann - 2017-01-04

Version 2

-- Kevin Jennings - 2017-01-10

KJ: I think the use of O'attribute shorthands for O'SUBTYPE'attribute are going to lead to odd looking code, for example report xyz'image(xyz)

PL: Please review the definition of for example 'IMAGE for objects. 'IMAGE has no parameter anymore, so it's just xyz'image

-- Patrick Lehmann - 2017-01-10

I must admit, I'm a bit lost on the necessity of the "Any prefix P that is appropriate for..." language. It seems to be doing two things.

1. Allowing the use of objects O of subtype T so as to create a shorthand O'WIDGET for O'SUBTYPE'WIDGET and
2. Clarifying that aliases to types and expressions like O'SUBTYPE that yield types are equivalent to types.

That new language is technically correct as I can tell, but it took me a sound dozen readings to figure out what it meant. I know I'm not the smartest person who's going to have to deal with all this, but I'm probably not the dumbest either.

Point 1 can be addressed by being explicit. T'LEFT remains unchanged, and O'LEFT is described later as being explicitly equal to O'SUBTYPE'LEFT . It makes the table longer, but more graspable. You don't even need to restrict the kinds of O that are usable, it's always equivalent to O'SUBTYPE'LEFT even if it then throws an error because the result of O'SUBTYPE doesn't have a 'LEFT .

Point 2 I don't think needs addressing. Attributes are processed from left to right, so of course anything that yields a type looks like a T when you hit the next tick mark.

Right now I'm marking my vote as an abstain. From a technical standpoint I want these things implemented the way it says above; I think it will make VHDL code more readable. But as written, it definitely turns what is currently one of the more readable sections of the LRM into an impenetrable text wall.

Also, of far less importance, are you sure the Kind: of P'LENGTH is "Pure function" rather than "Value"?

-- Rob Gaddi - 2017-01-15

RG: You don't even need to restrict the kinds of O that are usable, it's always equivalent to O'SUBTYPE'LEFT even if...

KJ: O'LEFT might not always be equivalent to O'SUBTYPE'LEFT depending on whether LCS 72a is adopted or not. If the object happens to be a parameter to a subprogram, then within that subprogram, LCS 18 and LCS 72a conspire to make O'LEFT to be the attribute from the actual whereas O'SUBTYPE'LEFT would remain as it is today which is to return the attribute from the formal.

-- Kevin Jennings - 2017-01-16

@RG The language here for attributes like 'LEFT should sound familiar as it is patterned exactly from the array attributes. I would prefer that we write both in the same style. Since it is not practical to split the array attributes, it seems logical to keep scalar types and objects together.

@KJ I do not see anything here that allows O'LEFT return the actual of a subprogram.

-- Jim Lewis - 2017-01-26

Just an observation: The LCS title suggests this is for enumeration types, but the body of the LCS goes much further.

-- Ernst Christen - 2017-02-10

Questions:

• Is appropriate for the correct wording?
• http://stackoverflow.com/questions/40274025/vhdl-why-does-using-the-length-attribute-directly-on-a-function-produce-a-warn?rq=1#comment67822836_40279014
• http://web.archive.org/web/20110822072144/http://eda.org/isac/IRs-VHDL-93/IR1005.txt

The prefix doesn't allow functions to be a prefix, whereas e.g. indexed names allow functions as a prefix. An attribute prefix should include returned values from functions.

-- Patrick Lehmann - 2017-03-14

'low and 'high are derived values from left and right and the direction. Seems the Kind of these two should also be "Pure function".

-- Karl Eisenhofer - 2017-03-23