(r1) LCS2016_012_History < P1076

P1076 Web>VHDL2017>LCS2016_012>LCS2016_012_History (revision 1) (raw view)~~EditAttach~~
---+ Language Change Specification for String representation of values of composite types

---++ Summary

| <sticky><b>LCS Number:</b></sticky> | LCS-2016-012 History |
| <sticky><b>Version:</b></sticky>  | 3 |
| <sticky><b>Date:</b></sticky>  | 22-Dec-2016 (v1), 28 Dec 2016 (v2), 16 Mar 2017 (v3) |
| <sticky><b>Status:</b></sticky>  | Voting |
| <sticky><b>Author:</b></sticky>  | Ryan Hinton |
| <sticky><b>Email:</b></sticky>  | [[Main.RyanHinton]] |
| <sticky><b>Source Doc:</b></sticky> | [[CompositeValueString][String representation of values of composite types]] |
| <sticky><b>Summary:</b></sticky>  | Provide simple built-in facility for converting the value of a composite type to/from a string. |

---+++ Voting Results: Cast your votes here

Yes:

   1 <span data-mce-mark="1">%USERSIG{RyanHinton - 2016-12-22}%</span> ver 2
   1 %USERSIG{MartinZabel - 2017-02-13}% ver 2
   1 %USERSIG{RobGaddi - 2017-03-19}% ver 3
   1 <span data-mce-mark="1">%USERSIG{JimLewis - 2017-03-06}%</span> ver 2
   1 %USERSIG{FarrellOstler - 2017-03-21}% ver 3

No:

Abstain:

   1 %USERSIG{HendrikEeckhaut - 2017-01-27}%
   1 %USERSIG{LievenLemiengre - 2017-01-27}%
   1 %USERSIG{BrentHahoe - 2017-02-16}% Version 2 - Abstain due to lack of personal time for review.
   1 %USERSIG{MartinThompson- 2017-02-17}% Version 2 - Abstain due to lack of personal time for review.


---++ <span data-mce-mark="1"><a name="Comments"></span><span data-mce-mark="1"></a></span>Comments

(Copy of comment that was in the row with this proposal on the Vhdl2019CollectedRequirements page:)

Proposal is not clear on what direction to go. Discussed at 8/21/2014 meeting, no mention of whether to go ahead or not. Suggest moving this to 'Someday, maybe'.

-- <span data-mce-mark="1">%BUBBLESIG{KevinJennings - 2016-10-14}%</span>

   1 Does it make sense to specially handle one dimensional array of a character type, so that Bit_Vector'Image ("010101") = "010101" ?
   1 There are differences between To_String and 'Image for some scalar types, but not for scalar types within a composite type. I think that doesn't work:
<verbatim>
  consider: type Rec is record A, B : Character; end record
  constant c1 : rec := (',', CR);</verbatim>

=Rec'Image(C1)= is ="(,," & CR & ")"=   which is difficult to read.

-- <span data-mce-mark="1">%BUBBLESIG{TristanGingold - 2016-12-23}%</span>

I think Tristan has it right; composite type 'values where the composite contains ',' or ')' characters are going to cause grief to flip back the other way.  Putting arrays of character types inside of double quotes would resolve this.  It would mean that quotation mark characters have to be doubled inside of these string representations.  This would also mean that the string representation of string is NOT in fact the string, it's the quoted and escaped version of the string.  So string'image("Bob") is the 5 character sequence "Bob", not the 3 character sequence Bob.

Likewise, for the same reasons, subelements of composite types should follow the same 'image rules as the elements would out in the world on their own.  This will effectively make the 'image of a composite type equal to "What would I have to type to write this composite directly into my VHDL code?"

-- <span data-mce-mark="1">%BUBBLESIG{RobGaddi - 2016-12-27}%</span>

@Tristan and @Rob: You're right, of course.  The format I had defined for ='IMAGE= is not invertible.  I hadn't appreciated the differences bewteen the ='IMAGE= representation and the "string representation" defined in 5.7.  I've added a lovely table and example to [[CompositeValueString][the original proposal]] to illustrate.  Here's a simple example of a non-unique ='IMAGE= using the version 1 text.

<verbatim> type Rec is record a,b : string; end record;
 constant c1 : Rec := Rec'value("(,,,,)")</verbatim>

One of those commas is to separate fields =a= and =b=.  The other three commas are in =a= and =b= in any arrangement of length zero to three for each as long as the sum comes out right.

@Tristan: Just to be clear, I don't anticipate that these formats will be easy to read for all cases.  I want them to be simple to define and understand -- especially for ='value= or a Python script or whatever.  I want them to *exist* as a baseline, and =to_string= can be overridden for types where a human knows they want to see it differently.

I have reworked the change spec to keep and extend the peculiarities of ='image= for composites.  Some types have more than one representation, but each valid representation should map uniquely back to a single value (via ='value=).  The result is version 2.

-- <span data-mce-mark="1">%BUBBLESIG{RyanHinton - 2016-12-27}%</span>

I disagree with Note 3.  STRING is a one-dimensional array of CHARACTER, which is an enumeration type of only character literals, and so will follow the special case given in the 'IMAGE definition.  STRING'IMAGE("Bob says " & '"' & "Hi!" & '"') yields the 18 character sequence "Bob says ""Hi!""" with no ambiguity.  Which is good, and preferable to the result being ambiguous.

-- <span data-mce-mark="1">%BUBBLESIG{RobGaddi - 2017-01-26}%</span>

Good observation.  =STRING= is a one-dimensional array of =CHARACTER=.  However, its element type contains more than just character literals.  From 15.6, "A character literal is formed by enclosing one of the 191 graphic characters (including the space and nonbreaking space characters) between two apostrophe characters."  In particular, the first 32 values in the =CHARACTER= enumeration are not character literals, e.g. =cr= and =lf= and my favorite =bel=.  That's why I added the special-case text in the =T'IMAGE= description to allow the tool to spit out ="two"= as users will expect when a particular string is composed of only character literals.

For example, what would you expect =STRING'IMAGE("Bob says "& cr &"Hi!" & bel)= to return?  As defined, it will (unambiguously) return a 55-character string with the following contents.

<pre>('B','o','b',' ','s','a','y','s',' ',cr,'H','i','!',bel)
</pre>

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

After reviewing 15.2 I agree with you, =CHARACTER= consists of more than just graphic characters, so this LCS is correct.  Changed my vote to yes.

-- %BUBBLESIG{RobGaddi - 2017-02-23}%

to_string for bit_vector is already defined on page 265

-- %BUBBLESIG{JimLewis - 2017-03-06}%

Also per  5.3.2.4 and  5.3.3.1, for composites, the implicit to_string is defined immediately following the type declaration, so these need to be moved to appropriate places.   

The interesting question is that why does 5.2.6 on page 42 make the implicit to_string for scalars in std.standard occur at the end of the package, but immediately following the type for all other cases?   It also implicitly defines maximum and minimum and makes them immediately after the type declaration.   

-- %BUBBLESIG{JimLewis - 2017-03-06}%

Fixed, removed =bit_vector= from the list.  I hadn't noticed that 5.3.2.4 lacked the exception given for scalars in 5.2.6.

I assume the scalars in =std.standard= come at the end of the package because =STRING= isn't defined until halfway through the package.  You have to define =CHARACTER= then =STRING= before you can define the =to_string= function for =CHARACTER=.

-- %BUBBLESIG{RyanHinton - 2017-03-16}%

%COMMENT%
Topic revision: r1 - 2020-02-17 - 15:34:35 - TWikiGuest
P1076