Language Change Specification for String representation of values of composite types

Summary

Voting Results: Cast your votes here

Yes:

1. Ryan Hinton - 2016-12-22 ver 2
2. Martin Zabel - 2017-02-13 ver 2
3. Rob Gaddi - 2017-03-19 ver 3
4. Jim Lewis - 2017-03-06 ver 2
5. Farrell Ostler - 2017-03-21 ver 3

No:

Abstain:

1. Hendrik Eeckhaut - 2017-01-27
2. Lieven Lemiengre - 2017-01-27
3. Brent Hayhoe - 2017-02-16 Version 2 - Abstain due to lack of personal time for review.
4. Martin Thompson- 2017-02-17 Version 2 - Abstain due to lack of personal time for review.

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'.

-- Kevin Jennings - 2016-10-14

1. Does it make sense to specially handle one dimensional array of a character type, so that Bit_Vector'Image ("010101") = "010101" ?
2. 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:

  consider: type Rec is record A, B : Character; end record
  constant c1 : rec := (',', CR);

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

-- Tristan Gingold - 2016-12-23

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?"

-- Rob Gaddi - 2016-12-27

@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 the original proposal to illustrate. Here's a simple example of a non-unique 'IMAGE using the version 1 text.

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

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.

-- Ryan Hinton - 2016-12-27

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.

-- Rob Gaddi - 2017-01-26

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.

('B','o','b',' ','s','a','y','s',' ',cr,'H','i','!',bel)

-- Ryan Hinton - 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.

-- Rob Gaddi - 2017-02-23

to_string for bit_vector is already defined on page 265

-- Jim Lewis - 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.

-- Jim Lewis - 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.

-- Ryan Hinton - 2017-03-16