LCS2016_041_History < P1076

P1076 Web>VHDL2017>LCS2016_041>LCS2016_041_History (2017-04-02, PatrickLehmann) (raw view)EditAttach
---+ Language Change Specification History for Reflection API
<sticky>
<noautolink>
---++ 

| <sticky><b>LCS Number:</b></sticky> | [[LCS2016_041][LCS-2016-041]] |
| <sticky><b>Version:</b>   </sticky> | 3 |
| <sticky><b>Date:</b>      </sticky> | 21-Mar-2017 |
| <sticky><b>Status:</b>    </sticky> | Approved |

%TOC%


---++ Voting Results:
Yes:
   1 %USERSIG{LievenLemiengre - 2017-03-09}% - Version 1
   1 %USERSIG{PatrickLehmann - 2017-03-21}% - Version 3
   1 %USERSIG{KevinJennings - 2017-3-17}% Ver 2
   1 %USERSIG{RobGaddi - 2017-03-23}% ver 3

No:
   1 

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


---++ Revisions
*Version 4:* 21-Mar-2017
   * Fixed range of enumeration indices (positive -&gt; natural)

*Version 3:* xx-Mar-2017
   * =type INDEX is range INTEGER'range;= isn't valid VHDL, changed to =type INDEX is range INTEGER'low to INTEGER'high;=

*Version 2:* 13-Mar-2017
   * Added error conditions.
   * Clarified the copy of values. A mirror is frozen (read only).

*Version 1:* 09-Mar-2017
   * Initial LCS


---++ LCS Comments
---+++ Version 2
The first two sentences in paragraph 4 of 16.12.1 - General appear to me to contradict each other.

1) A value mirror contains a consistent copy of the mirrored object's value. -- KJ:  I'm not sure what the definition of 'consistent copy' is supposed to mean in this context, but my guess would be that the mirror value is the same as the actual object value.  In other words, like a physical mirror it reflects the real thing.

2) This means, if the object's value changes, the stored value in the mirror instance does not change -- KJ:  But here it says that the value in the mirror does 'not' change.  So I guess my guess was incorrect.

Assuming that my guess from #1 is not correct, then I think the two sentences should be reworded a bit.  Based on the example (mirror : VALUE_MIRROR := test'reflect;), it looks like the value mirror is updated at the point when the mirror is assigned.  Would suggest only one sentence, something along the following:

A value mirror is updated from the mirrored object's value when used as the target of an assignment.

Still reviewing, but I like the concept.

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


Should this package be able to compile using 2008 syntax?  When I try to compile with brand 'M', I get a &#34;Range must be range_attribute_name or simple_expression direction simple_expression.&#34; error on the very first line:  type    INDEX           is       range INTEGER; There were a total of 102 errors reported, likely due to a much smaller number of root cause things.

If this LCS needs changes that are proposed for 2017 LRM, then those LCS should be listed as dependencies on this package somewhere.  But it would be helpful if the package did compile simply with 2008 syntax.

-- %BUBBLESIG{KevinJennings - 2017-03-15}%


Consistent means e.g. for a record it's copied in one atomic operation. Even if the concept is called mirroring, the copied data is a snapshot. The protected type implements a frozen data structure (it's read only).

The API requires pointers to PT and is improved by garbage collection.

For line 2: Can you add a 'RANGE after integer? It should somehow work :).

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


What's the rationale behind creating an INDEX that isn't a subtype of INTEGER, as opposed to just using INTEGER, POSITIVE, NATURAL, and INTEGER_VECTOR?

In LRM 5.2.2.1, the position number of the first element in an enumeration is zero. I think that means ENUMERATION_SUBTYPE_MIRROR_PT.enumeration_literal needs to be a NATURAL_INDEX rather than a POSITIVE_INDEX.  Also, ENUMERATION_VALUE_MIRROR_PT.pos should return NATURAL_INDEX rather than INTEGER. 

-- %BUBBLESIG{RobGaddi - 2017-03-21}%

---+++ Version 4
The =INDEX= has a separate type, which is required in a future revision, if we add object creation support. Currently, we stripped that feature out. It's planed that a subtype mirror can also create value mirrors (instances of a type) and that a user can assign such a value mirror to an object.

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


@Rob: About the index type:

The =INDEX= type isn&#39;t strictly required. Honestly I never thought this proposal would make it this far. I was experimenting with making the API more type-safe and found an interesting way is to separate calculations on indices & values. Since I don&#39;t have a working implementation, only a type checker, this helped me find some bugs in the examples.

@Kevin: About the copying behavior:

If you want use reflection to observe changes to an object you need to reflect over an access type value.

-- %BUBBLESIG{LievenLemiengre - 2017-03-22}%
</sticky>
</noautolink>
Topic revision: r1 - 2017-04-02 - 12:03:51 - PatrickLehmann
P1076