LCS2016_018_History < P1076

P1076 Web>VHDL_2017>LCS2016_018>LCS2016_018_History (2017-04-02, PatrickLehmann) (raw view)EditAttach
---+ Language Change Specification for Attributes for Enumerated Types
<noautolink>
<sticky>
---++ 

| <sticky><b>LCS Number:</b></sticky> | [[LCS2016_018][LCS-2016-018]] |
| <sticky><b>Version:</b>   </sticky> | 2 |
| <sticky><b>Date:</b>      </sticky> | 11-Jan-2017  |
| <sticky><b>Status:</b>    </sticky> | Approved |

%TOC%

---++ Voting Results:
Yes:
   1 %USERSIG{PatrickLehmann - 2017-01-03}% - ver 2
   1 %USERSIG{JimLewis - 2017-01-11}% - ver 2
   1 %USERSIG{MartinZabel - 2017-01-11}% - ver 2
   1 %USERSIG{ThomasPreusser - 2017-01-13}% - ver 2
   1 %USERSIG{LievenLemiengre - 2017-01-27}% - ver 2
   1 %USERSIG{HendrikEeckhaut - 2017-01-27}% ver 2
   1 %USERSIG{RobGaddi - 2017-02-09}% - ver 2

No:
   1 %USERSIG{KevinJennings - 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 <i>Obj'</i>subtype'<i>attribute</i>). Not an improvement to the language, rather a detriment.

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


---++ Revisions
*Version 2:* 11-Jan-2017
   * 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

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

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

-- %BUBBLESIG{KevinJennings - 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 :)

-- %BUBBLESIG{PatrickLehmann - 2017-01-04}%

---+++ Version 2
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)=.
Yes it is shorter than =xyz'subtype'image(xyz)= but both forms are error prone (i.e. =abc'image(xyz)=).  Something like =report xyz'image= or
=report image(xyz)= is far better form and avoids a latent issue as well as simply avoiding to have to list the object twice in order to get it
completely correct.

-- %BUBBLESIG{KevinJennings - 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=

-- %BUBBLESIG{PatrickLehmann - 2017-01-10}%


I must admit, I'm a bit lost on the necessity of the &#34;Any prefix P that is appropriate for...&#34; 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"?

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

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

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


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

-- %BUBBLESIG{ErnstChristen - 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&#39;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.

-- %BUBBLESIG{PatrickLehmann - 2017-03-14}%


&#39;low and &#39;high are derived values from left and right and the direction.  Seems the Kind of these two should also be &#34;Pure function&#34;.

-- %BUBBLESIG{KarlEisenhofer - 2017-03-23}%
</sticky>
</noautolink>
Topic revision: r1 - 2017-04-02 - 12:20:04 - PatrickLehmann
P1076