LCS2016_099_History < P1076

P1076 Web>VHDL_2017>LCS2016_099>LCS2016_099_History (2017-04-02, PatrickLehmann) (raw view)EditAttach
---+ LCS History for Extended Ranges / Operations on Ranges
<noautolink>
<sticky>
---++ 

| <sticky><b>LCS Number:</b></sticky> | [[LCS2016_099][LCS-2016-099]] |
| <sticky><b>Version:</b>   </sticky> | 7 |
| <sticky><b>Date:</b>      </sticky> | 21-Mar-2017  |
| <sticky><b>Status:</b>    </sticky> | Approved |

%TOC%


---++ Voting Results:
Yes:
   1 %USERSIG{LievenLemiengre - 2017-03-09}% - ver 5
   1 %USERSIG{PatrickLehmann - 2017-03-21}% - ver 7
   1 %USERSIG{RobGaddi - 2017-03-23}% - ver 7
   1 %USERSIG{JimLewis - 2017-03-23}% - ver 7

No:
   1 

Abstain:
   1 %USERSIG{MartinZabel - 2017-02-25}% - ver 4 - Can't tell whether the removal of item e) in clause 9.4.2 is okay or not.
   1 %USERSIG{MartinThompson - 2017-03-08}% - abstain, insufficient time to review properly


---++ Revisions
*Version 1:* 20-Feb-2017
   * Implement ranges as an implicitly pre-defined record type
   * Make that record type and it's instances available through attributes
   * Allow range records to be used where ranges can be used.

*Version 2:* 21-Feb-2017
   * Changes LowerBound/UpperBound to LeftBound/RightBound
   * Found a place for the simple range and range expression evaluation
   * Strike out a staticness restriction:
      * Currently only pre-defined operators and operators defined in STD.* and IEEE.* are static, whereas operators in defined in user code
        are not static.

*Version 3:* 21-Feb-2017
   * Fixed EBNF
  
*Version 4:* 22-Feb-2017
   * Adjusted this LCS to the Reflection API => TopLCS2016_041 %BR%
     Renamed the bounds again to Left and Right as used by the reflection API's mirror types.

*Version 5:* 07-Mar-2017
   * Made attributes secondary attributes. %BR%
     "P'RANGE_RECORD" becomes "P'RANGE'RECORD" and %BR%
     "P'RANGE_VALUE" becomes "P'RANGE'VALUE".
   * Decreased the number of needed attributes, because secondary attributes allow a higher
     degree of reuse.

*Version 6:* 14-Mar-2017
   * Fixed my misunderstanding of 9.4.3. These sentence must exist, but the list of packages shouldn't be restricted. %BR%
     This sentence also excluded operators define e.g. in an architecture or process to be locally static.

*Version 7:* 21-Mar-2017
   * Moved type check from elaboration to analysis
   * Moved 9.4.3.2 to a separate LCS


---++ Comments
---+++ Draft
What is the actual utility as compared to using ='low=, ='high=, and ='ascending=? Why would you want to wrap this information into an
extra record? Are use cases so widespread that we should ask tool vendors to provide such records for you?

-- %BUBBLESIG{ThomasPreusser - 2017-02-10}%

*I know, this is still a draft. Thus take the following as hints for further updates.*

1) I have fixed the modifications for clause 5.2.2.2 to make clear that DIRECTION is a new predefined enumeration type. 

2) The type DIRECTION is not needed, BOOLEAN can be used instead. Also the attribute ASCENDING of array objects and types returns a boolean.
   Thus the record should have a field =Ascending : BOOLEAN= instead of =Direction=.

3) _The type of an expression depends only upon the types of its operands and on the operators applied_, see clause 9.1, bottom of page 117.
   Thus, please remove the blue words &#34;result&#34; in the modifications for 8.5.

4) If you store 'LOW and 'HIGH in the record, then the direction will be always ascending. I think what you want instead is 'LEFT in LeftBound
   and 'RIGHT in RightBound.

5) Within 8.5, this sentence is wrong: _The slice is a null slice if the discrete range is a null range %RED%or if the distance between
   LowerBound and UpperBound (based on position numbers) is less or equal zero.%ENDCOLOR%_

   If LowerBounds / LeftBound equals UpperBound / RightBound then the slice has a length of 1. The definition should be also more explicit
   and maybe written as a bulleted list:

   The slice is a null slice:
      * if the discrete range is a null range%RED%, or%ENDCOLOR% 
      * %RED% if Ascending is true and LeftBound is greater than RightBound, or%ENDCOLOR%
      * %RED% if Ascending is false and LeftBound is less than RightBound.%ENDCOLOR%

   This definition is based on the fixes from points 2) and 4) above. See also definition of null range on bottom of page 36.

6) _A slice name denotes a one-dimensional array composed of a sequence of consecutive elements of another one-dimensional array_, see clause 8.5.
   So what is the purpose of the additional attributes defined in 16.2.2?

7) A slice has always a discrete range because an _index constraint shall provide a discrete range for each index of the array type_, see 5.3.2.2.
   That's why only discrete ranges are allowed for slice names, see 8.5. Thus, range records for real and universal_real have no use.

-- %BUBBLESIG{MartinZabel - 2017-02-17}%


*TBP:* Are use cases so widespread that we should ask tool vendors to provide such records for you?

*PL:* This feature is not for *me*. But yes, I developed major ideas behind it, I implemented a range arithmetic package and I fully support the
proposal. The proposal was ranked and not moved to "Some day maybe". The first ideas to support an arithmetic on ranges is from Stewart Cobb planned
for VHDL-93. Use cases are linked in the LCS header as in any other LCS.

-- %BUBBLESIG{PatrickLehmann - 2017-02-20}%

*MZ:* 1) %BR%
*PL:* Thanks.

*MZ:* 2) The type DIRECTION is not needed, BOOLEAN can be used instead.%BR%
*PL:* The using a =BOOLEAN= is against the ideas of VHDL/Ada and also against strong typing. We have the ability to define 2 distinct integer types
so both cannot be mixed up. The LRM does it itself e.g. for =SIDE=. Even =BOOLEAN= itself could be represented by =BIT=. Both are predefined enumerations
of just two values. So I prefer a =DIRECTION= enumeration matching the corresponding EBNF rule.

*MZ:* 3) %BR%
*PL:* Doesn't apply anymore.

*MZ:* 4) If you store 'LOW and 'HIGH in the record, then the direction will be always ascending.%BR%
*PL:* That's not true. ='LEFT=/='RIGHT= and ='LOW=/='HIGH= are orthogonal values, convertible by ='ASCENDING=. (See 16.2.2 - Note 1). %BR%
But the main reason is that arithmetic with =LowerBound= and =UpperBound= requires less conditions based on =Direction=.

*MZ:* 5) %BR%
*PL:* Doesn't apply anymore.

*MZ:* 6) So what is the purpose of the additional attributes defined in 16.2.2?%BR%
*PL:* The user needs an API to access the internal representation of a range of a scalar subtype. The result is a _range record_.

*MZ:* 7) %BR%
*PL:* First part doesn't apply anymore. %BR%
*MZ:* Thus, range records for real and universal_real have no use.%BR%
*PL:* Ranges can be used in more places than only in places where _discrete_range_ is allowed. Ranges can be passed via generic or parameter maps. Timespans
can now be described as:

<pre>
alias TIME_SPAN is TIME'RANGE_RECORD;

constant MyTimeSpan : TIME_SPAN := (5 ns, 10 ns, ASCENDING);
</pre>

A future version could allow this:

<pre>
constant MyTimeSpan : TIME_SPAN := TIME'(5 ns to 10 ns);
</pre>

-- %BUBBLESIG{PatrickLehmann - 2017-02-20}%
---+++ Version 1
I prefer left & right over lowerbound & upperbond. A library can make these records easier to use, the record-model of the range should closely resemble how the language defines the range.

-- %BUBBLESIG{LievenLemiengre - 2017-02-20}%


*PL*: Use cases are linked in the LCS header as in any other LCS.

*TBP*: I am sorry but although the proposal _Extended Ranges_ is linked, I would not at all read it as a use case for this LCS. The proposal is asking for operations on
ranges. However, the central invention of this LCS is this range record, which is, indeed, used by the proposal for illustrating the backing =<i>implementation-specific</i> data structure=
but is not actually asked for in an implementation. Such a range record could be helpful for implementing a library workaround for a missing language feature but this is
all it is. And by itself, it really is just a shorthand for querying three attributes in a single step. It does not provide any of the desired range operations. I do not
think that it would be a good idea to establish this workaround in the standard because this will block the future thorough adoption of the proposal by the virtue of
compatibility issues.

-- %BUBBLESIG{ThomasPreusser - 2017-02-20}%


*TBP:* And by itself, it really is just a shorthand for querying three attributes in a single step. %BR%
*PL:* Yes and no. Yes you could query all three members by hand, what gives you a lot of code. Then you could implement arithmetic on user defined records, but no comes the missing part:
You can't use such a user define record in e.g. a generate statement as a locally static discrete range.

*TBP:* It does not provide any of the desired range operations. %BR%
*PL:* VHDL is going away from the out-dated principle that a languages should define the complete language library. That is thinking of the 80s. We are now providing a basic functionality
that allows user to develop further features based on such basic functionality like range records.

*TBP:* ... because this will block the future thorough adoption of the proposal ...%BR%
*PL:* We had long discussions in meetings and on the IEEE reflector as we discussed how to incorporate ranges as a first class objects as required by the original proposal. That was also
my own first thought of how to implement it. But the analysis showed that subtypes and ranges can not be divided into two VHDL constructs. You would endup in defining operators and expressions
for subtypes. I think we shouldn't go that route.

So feel free to do the same basic analysis of ranges as a first class object and how to meet all the design goals or see our long discussions on the reflector.

-- %BUBBLESIG{PatrickLehmann - 2017-02-20}%
---+++ Version 4

*MZ:* Can't tell whether the removal of item e) in clause 9.4.2 is okay or not. %BR%
*PL:* According to Tristan, locally static expressions are needed in choices (e.g. case statements).
He further states that GHDL doesn't enforce that rule.

-- %BUBBLESIG{PatrickLehmann - 2017-03-07}%
---+++ Version 7


</sticky>
</noautolink>
Topic revision: r1 - 2017-04-02 - 12:07:06 - PatrickLehmann
P1076