String representation of values of composite types

Proposal Details

• Who Updates: Ryan Hinton, David Koontz, Jim Lewis, Martin Thompson, Tristan Gingold
• Date Proposed: 21 Jul 2014
• Date Last Updated: 7 Aug 2014
• Priority:
• Complexity:
• Focus:

Language Change Specification link

LCS-2016-012

Current Situation

The IMAGE attribute is defined for scalar types, but not for array or record types. The VALUE attribute is defined/not defined for the same cases. The TO_STRING function is defined for CHARACTER, enumeration types, integer, physical, floating-point (real) and one-dimensional arrays whose element is a character type. It is not defined for record types and general array types.

Requirement

We should have built-in facilities to convert values of general types to/from strings. This is invaluable for report strings, log messages, and text file I/O. The alternative is for each user to manually create the strings in the expression or manually write functions to convert values to/from strings. Building in this facility saves time and headache for the designer.

Current language

The current language has an interesting mix of rules to generate 'IMAGE (5.7, 16.2).

• Extended identifier has leading and trailing backslash. Interior backslashes are doubled.
• Character has leading and trailing apostrophe.
• Basic identifiers are lowercase. <<|

  Enumeration other than CHARACTER	One-element string for character literal, otherwise the identifier for the value as a string. No leading or trailing backslash for extended identifiers.	Basic identifiers are in lowercase.	^
  Integer type	Abstract literal, may have a sign, no point, no space or format effector.	Decimal literal, no exponent. No leading sign for positive values.	Decimal literal, no underlines or insignificant zeros. Exponent may be present as "e".
  Physical type	Physical literal notation, may have a sign, no space or format effector.	Decimal integer literal, no exponent, single SPACE character between the abstract literal and unit name. For TIME, the unit name is the simple name of the resolution limit; otherwise, the unit name is the simple name of the primary unit of the physical type. No leading sign for positive values.	Expressed in primary units except for TIME which uses resolution limit. Lowercase units.
  Floating-point type	Abstract literal notation, includes a point, may have a sign, no space or format effector.	Decimal literal, normalized mantissa, exponent with sign and lower-case "e". (More text for WRITE procedure.) No leading sign for positive values.	Number of digits to right of decimal point is "standard form" for TEXTIO.WRITE for type REAL.
  1-D array of enumeration containing only character literals	String with character values in matching positions.

  This gives some interesting results for corner cases. The following process, compiled into an entity, gives the following results.

    process is
    begin
      report "Image of comma: ["&character'image(',')&"]" severity NOTE;
      report "TO_STRING of comma: ["&to_string(',')&"]" severity NOTE;
      report "Image of carriage return: ["&character'image(cr)&"]" severity NOTE;
      report "TO_STRING of carriage return: ["&to_string(cr)&"]" severity NOTE;
      wait;
    end process;
  

  Results on one particular simulator:

  # ** Note: Image of comma: [',']
  # ** Note: TO_STRING of comma: [,]
  # ** Note: Image of carriage return: [cr]
  # ** Note: TO_STRING of carriage return: [
  # ]
  

  Implementation details

  Two approaches are possible, detailed below. The two approaches are not mutually exclusive. RyanHinton thinks we should implement both.

  Format

  Proposed format is paren-enclosed, comma-delimited sequence of the element strings from left to right (array) or first to last defined (record). The resulting string should be a valid VHDL aggregate expression for the given value. (Actually, the result is only a valid aggregate for an array or record value with at least two elements. -- tgingold)

  (JimLewis, 21 Jul 2014) Now that we have protected types, we could create global configurations for this sort of thing. The global configuration could define a default composite left brace, composite separator, and composite right brace. Each of these can be strings which would allow them to be either the left parenthesis as you suggest or allow them to be simply separated by spaces. The issue I run into is that procedures in a package do not currently have a way to see the context of the calling code.

  (Response, RyanHinton, 21 Jul 2014) For 'IMAGE I prefer a static definition, particularly for easy 'VALUE implementation. I also like keeping TO_STRING simple and let the designer override as desired.

  Arrays of CHARACTER

  (DavidKoontz, JimLewis, 22 Jul 2014) The proposed format will give a string three times the length of the original vector. Would it be horrible to have character'image('A') return a string containing A without the single quotes?

  Response (RyanHinton, 7 Aug 2014) The proposed formatting simply calls 'IMAGE or TO_STRING on each of the elements. If you want to change the format of CHARACTER'IMAGE, that's a new proposal. I recommend against special-casing 'IMAGE for CHARACTER elements. Instead, I recommend using TO_STRING if you want to control the resulting format.

  Option 1: Pre-defined IMAGE and VALUE attributes

  Type T is a "normal" array or record (sub)type (no protected types, access, file, etc.). Calling T'IMAGE(X) returns the value of object X in a string, formatted as described above. Calling T'VALUE(X) on such a string returns the value of the (sub)type T represented by the given string.

  Option 2: Implicit TO_STRING function

  Type T is a "normal" array or record (sub)type (no protected types, access, file, etc.). Immediately after its declaration, an implicit function TO_STRING is declared as follows:

  function TO_STRING (VALUE: T) return STRING;

  This matches exactly the current definition of the implicit TO_STRING function except for the extension that T can be any (normal) array or record type.

  -- DavidKoontz - 2014-08-07 This appears to require TO_STRING be a predefined function for anonymous type arguments.

  -- RyanHinton - 2014-08-13 I see this as distinct from the AnonymousTypes. TO_STRING in the current LRM is setup as an implicit function declaration following a type declaration. I tried to copy the language as closely as possible in the language of this option. In other words, it's not a single function of an anonymous type; it's an implicitly-declared function for each type. They're essentially the same in spirit, though.

  Discussion

  Normal types

  Do we need to restrict the record/array element types to be "normal"? For example, is there a good reason to exclude an access element type? As described, this proposal only supports element types for which 'IMAGE or TO_STRING are already defined, which excludes access types. In particular, a circular linked list could easily produce an infinite-length string.

  To_string vs image

  (JimLewis, 21 Jul 2014) I prefer to_string since it is overloadable ( 'image is not) and simple to use.

    report std_logic_vector'image(ary) severity note;  -- 'image, verbose
    report to_string(ary) severity note;               -- to_string, cleaner

  (RyanHinton, 7 Aug 2014) I agree that TO_STRING is more concise and more flexible because it can be overloaded. I am proposing both because 'IMAGE has an inverse, 'VALUE.

  DavidKoontz - 2014-08-07 You're also proposing 'VALUE support composite types. There's this built in assumption the string representation is valid or there's another whole can of worms for error reporting.

  RyanHinton - 2014-08-13 Of course the string passed to 'VALUE must be valid, just like it must be for the scalar types it's currently defined for. What do you expect integer'value("NaN") to do? The LRM simply says "it is an error" if it's not valid. This restriction handles the expanded scope without modification.

  Code Examples

  Example one: std_logic_vector

  TO_STRING is already implicitly defined for std_logic_vector. But 'IMAGE is not.

  process is
    variable ary : std_logic_vector(0 to 3) := b"011";
  begin
    report std_logic_vector'image(ary) severity note;
    -- will print a note with message "('0','1','1')"
    wait;
  end process;

  Comment (tgingold, 21 Jul 2014) This not the best example since we already have to_hstring anad related functions for std_logic_vector.

  Response (RyanHinton, 21 Jul 2014) Yes, it's not the most compelling example. But it's a good example of the formatting since everyone knows std_logic_vector.

  Comment (-- DavidKoontz - 2015-02-13) Note that per 5.3.2.4 and 5.7 to_string would produce "011" which for compatibility purposes with 'VALUE for multidimensional array or record types would be an aggregate value of "("011")". It also raises the question of whether or formal association should be supported as well. It would seem valuable for record types.

  Example: integer_vector

  process is
    constant ary : integer_vector := (1, 2, 3)
  begin
    report integer_vector'image(ary) severity note;
    report to_string(ary) severity note;
    -- prints two notes with message "(1,2,3)"
  
    if ary = integer_vector'value(integer_vector'image(ary))
      report "VALUE is inverse of IMAGE" severity note;
    end if;
    -- prints a note with message "VALUE is inverse of IMAGE"
    wait;
  end process;

  RyanHinton and JimLewis would love to have to_string defined for integer_vector, real_vector, and all the other built-in vector types. (We also should define vectors of other built-in and IEEE types, e.g. complex_vector and sfixed_vector.) We can either define to_string for each of these cases in the LRM (make LRM 5.2.6 longer and longer), or we can define it once for the general case, and then define any overloads we want e.g. to control formatting for real_vector. In particular, defining IMAGE and VALUE attributes can vastly simplify text parsing. (Yes, simpler for designers because the compiler people wrote the code instead. But I'm sure they can write it once to handle all arrays, right?)

  Example: records

  process is   
    type INNER_T is record
      a : real;
      b : integer;
    end record;
    type MIDDLE_T is record
      c : time;
      d : INNER_T;
    end record;
    type OUTER_T is record
      e : boolean;
      f : MIDDLE_T;
    end record;
  
    variable val : OUTER_T; 
  begin 
    val := (true, (3 ns, (0.5, 1))); 
    report "Nice when it's built in: "&to_string(val) severity note; 
    -- prints note with message "Nice when it's built in: (TRUE, (3 NS, (0.5, 1)))"
    wait; 
  end process;

  Arguments FOR

  'IMAGE already exists for scalars. Why leave out composite types? The enhancement can be used for report strings, log messages and text file I/O. Defining it in the language makes me more productive by removing busywork (see also #Write_your_own response). In other words, this is arguably a hole in the language.

  Also, this enhancement is useful. It can be used for report strings, log messages, and text file I/O. Defining it in the language makes designers more productive by removing busywork.

  -- DavidKoontz - 2014-08-07 I'd point out that efficient authoring may be better served in the domain of authoring tools where in general productivity is already addressed.

  Arguments AGAINST

  Many (all?) of these are summarized from newsgroup posts beginning 21 Jul 2014.

  Write your own

  (tgingold, 21 Jul 2014) You can easily write your own TO_STRING function.

  Response (Ryan Hinton, 21 Jul 2014) Sure, I can do it myself. I could even write to_string functions for every scalar type I define. And I can maintain process sensitivity statements (and use lint checking to find when I forgot). But process(all) makes my life easier. It makes my life easier to not have to write minimum and maximum functions for every type. I could write a "&" function for every array type I create. But we build these things into the language to make everyone's life easier. (OK, maybe not the compiler people. That's why we pay them the big bucks. ) (Smiley indicates that I realize this isn't a trivial addition; it will take real work to implement. But it doesn't feel like "lots" of work. It's certainly less more work than implementing to_string manually for the potentially unbounded set of user-defined types.)

  Said another way, there is an easy way for the computer/compiler to generate these strings for all data types. Or I can write code for each and every type I define to translate it to a string. I vote for the computer doing the work. Said another way, I vote for the compiler writer to do it well once so it works in every case.

  I am hoping the "easy to do it myself" translates into "easy for the compiler implementers to add."

  -- DavidKoontz - 2014-08-07 The set of cases "easy to do it myself" is a small subset of what you are proposing be done by including all composite types in 'VALUE, 'IMAGE or their predefined functions equivalents.

  -- RyanHinton - 2014-08-13 You probably see some cases that I don't. I don't see any cases where it's "hard to do it myself" assuming that correctly authoring lots of tedious, obvious code is included in "easy". Can you show a concrete example that is hard?

  No natural format

  (tgingold, 21 Jul 2014) There is no natural format (particularly for records).

  Response (Ryan Hinton, 21 Jul 2014) The proposed format matches the VHDL aggregate syntax. It is easy to produce, easy to parse (for 'value), and natural to any designer who uses these types. It is not the most concise or most obvious/natural in all cases, e.g. for arrays of STD_LOGIC where to_string is already defined. We could special-case the format for 'image, but I would rather just allow the designer to overload to_string if they want a different format.

  Ugly format

  Several newsgroup posts complained about the formatting: ugly, verbose, unreadable, etc.

  Response (RyanHinton, 23 Jul 2014) I don't need 'image to produce beautiful output for every situation. I agree that's impossible. But if it provides consistent output for every situation, it's a good starting point for any situation. And I can spend more time making beautiful output when I need it by overloading to_string.

  I'm not asking for the only-right-and-best-possible 'image. Just a good, general, easy-to-describe 'image.

  -- DavidKoontz - 2014-08-07 You're also asking that 'VALUE works.

  -- RyanHinton - 2014-08-13 Yes. 'VALUE is much easier to implement when the 'IMAGE definition is simple and consistent. Making the 'IMAGE definition more sophisticated to get prettier output will make 'VALUE harder to implement as well.

  Ada doesn't have it

  (DavidKoontz, 22 Jul 2014) Ada doesn't generate image strings for values of non-scalar types. Also, the C programming language doesn't have printf type string conversion formats for entire structures or unions.

  (MartinThompson, 23 Jul 2014) On the other hand, Python does have this functionality: https://docs.python.org/3/library/pprint.html. Python also has a standard way for objects to define a string representation of themselves. In VHDL this would be like overriding the IMAGE attributes. This would be potentially useful to the more complex protected types.

  (BrianDrummond, 23 Jul 2014, summarized by RyanHinton) Ada does allow overloading attributes with user-written functions. It's typically used with the stream I/O attributes 'read and 'write allowing you to stream arbitrary objects to/from file. It can be a little tricky to set up but works really well. I haven't studied the details for 'image and 'value.

  (RyanHinton, 23 Jul 2014) Ruby and Java also have built-in facilities for building a string representation of an arbitrary type.

  Long result

  (DavidKoontz and tgingold, summarized by RyanHinton) The resulting string may be long. It may be really long for arbitrarily complex records of arrays of records of .... So it will be slow. And it will be impossible to read. In fact, the result may even exceed the bounds of INTEGER'HIGH. The LRM doesn't provide facilities for problem reporting, so we shouldn't add a feature that can cause run-time errors.

  Response (RyanHinton, 7 Aug 2014) Yes, the resulting string may be long. So will the following, valid VHDL-2008 code.

    variable methuselah : std_logic_vector(0 to integer'high);
    ...
    report "Here is a really long value: "&to_string(methuselah) severity FAILURE;

  I have easy access to two simulators. One fails compile reporting "Total array memory limit exceeded." The other compiles successfully. (I would try to simulate, but unfortunately my license is expired.)

  Implementors choose limits for their tools. Interacting with the designer and these limits is outside the scope of the LRM. So I claim that we're not introducing any new problems, and the LRM shouldn't do anything about the current problem.

  Regarding slowness: Yes, spitting out lots of text to a transcript/log/file is slow. I promise only to do it if I really need to. But please don't reject a language feature because someone might (eventually almost certinaly will) use it in a way you don't like. (See also the C++ FAQ explanation of "evil" language features and its distinction between "legality" versus "morality" in a programming language.)

  Regarding readability/usability: Long doesn't mean impossible to read or useless. Long strings like this are very likely difficult for a human to use without reformatting. But I regularly throw long, complex strings like this into my text editor, reformat them with a few macros, and find the result extremely useful. For example, I have a 221-line record-of-records-of-... aggregate in a file I was working with yesterday. It has one field per line and uses named association. I think it's rather easy to read given the type definition. And it's long.

  Rebuttal -- DavidKoontz - 2014-08-07

  I don't believe VHDL has any predefined attributes nor operators that will cause simulation failure when presented with validly constructed expressions. Noting that division by zero is limited by it's normal mathematical meaning and is not valid. Also error reporting is not standardized and not guaranteed to accurately report what failed.

  A predefined attribute is attractive, a predefined to_string as the other way to deal with anonymous types also suffering from the same limitations. You could contemplate that to_string has been defined in several packages swept into the language definition without error checking, otherwise used as a circular argument in support of doing so for the 'IMAGE attribute. I'd hold that existing to_string implementations should be fixed as well, supplied by two packages swept up into the standard.

  My position is that a valid expression referencing no variable other than the name of a type and consisting of an attribute with an argument that is a validly declared object of that type should not be able to cause an error. Further predefined or language definition enclosed functions having arguments with the same parameters should not cause an error.

  Response -- RyanHinton - 2014-08-13

  Before nit-picking your position, what do you think are the chances of this ever happening? My estimate is less than EPS (essentially zero). I agree that we want VHDL to continue to be robust and well-defined, so I'll nit-pick your position.

  In short, my position is that this extension does not introduce any new restrictions in the LRM. If you take a look at my last example, I show that the 'IMAGE attribute already has this potential problem for scalar types. Perhaps we should add a restriction to the 'IMAGE attribute such as, "It is an error if the result exceeds the maximum string length." Perhaps we should also add this restriction to 'instance_name and 'path_name (see those examples below). Perhaps we should also do something for the 'pos example below.

  As I understand it, your position requires the following predefined attributes to be removed from the language. (See 1076-2008 16.2.2.) For the following example, assume the following definitions.

    constant NAT        : natural := 0;
    constant STR_MINUS1 : string  := "-1";
    constant STR_NAN    : string  := "NaN";
    constant BIT_ONE    : bit     := '1';
    constant INT_THREE  : integer := 3;
    constant INT_HIGH   : integer := integer'high;

  • T'VALUE(X). "It is an error if the parameter is not a valid string representation of a literal of type T or if the result does not belong to the subtype implied by T." For example, natural'value(STR_MINUS1) or integer'image(STR_NAN).
  • T'POS(X). For example, integer'image(INT_HIGH) is outside the guaranteed range of integer.
  • T'VAL(X). "It is an error if the result does not belong to the range T'LOW to T'HIGH." For example, boolean'val(INT_THREE).
  • T'SUCC(X). "An error occurs if X equals T'HIGH or if X does not belong to the range T'LOW to T'HIGH." For example, bit'succ(BIT_ONE).
  • T'PRED(X). "An error occurs if X equals T'LOW or if X does not belong to the range T'LOW to T'HIGH."
  • E'INSTANCE_NAME and E'PATH_NAME. For example:

  entity lotsa_blocks is
  end entity lotsa_blocks;
  architecture ellipsis of lotsa_blocks is 
  begin
    block1 : block is 
    block2 : block is 
    block3 : block is 
    ...
    block2000000000 : block is 
      signal bool : boolean := false;
    begin
      assert bool report bool'instance_name&" is false." severity note;
      bool <= true;
      assert not bool report bool'path_name&" is true." severity note;
    end block 2000000000; 
    ...
    end block block3;
    end block block2;
    end block block1;
  end architecture ellipsis;

  If we extend your position slightly to accept expressions of the proper type (which are allowed in the definition of these attributes), then 'IMAGE must also be removed from the language.

  Maybe I'm not sufficiently restricting my examples to your concept of "valid". Here's another example of perfectly valid (VHDL-2008 if not earlier) code that exceeds the guaranteed STRING index range.

  COMMENT (-- DavidKoontz - 2015-02-13) The preceding would all be presumably covered by "validly constructed expressions". Nitpicking is fine, straw man arguments are nothing more than propaganda techniques. I get you didn't like "validly" added in there.

    type my_scalar is (
      A, -- length 1
      AA, -- length 2
      AAAA, -- length 4
      AAAAAAAA, -- length 8
      ...       -- continue defining enumerated type values up to length 2**32
      );
    constant str : string := my_scalar'image(my_scalar'pos(32));

  I don't see anything in the LRM that restricts the length of an identifier. (It may be there, but I couldn't find it easily.)

  COMMENT (-- DavidKoontz - 2015-02-13) And this appears to be an identifier that doesn't produce a 'valid' string in all cases, it's not portable. This runs up against length of type STRING imposed by the POSITIVE RANGE of the implementation defined INTEGER range.

  Because each declaration is unique the length of an identifier is not relevant other than for recognition purposes (direct comparison or by hash). The supported length of identifiers is a matter of liars poker.

  A description is considered portable if it compiles, elaborates and simulates to termination of the simulation cycle on all conformant implementations. There is no sponsored validation suite testing identifier length nor is a length specified in the standard as you note.

  The first analyzer I wrote had a simple name length limit of 64 although easy to change, C having null terminated strings and the name part of a symbol structure with a fixed maximum array size. You could note that in the following decade we'd see code obsfucators supporting 128. It's also possible to write a lexical analyzer and parser that support arbitrary length identifiers. The supported length is implementation dependent.

  It seems likely you could write a description containing an indentifier that wouldn't fit in a string representation from 'SIMPLE_NAME, and I'd throw in 'valid' again. However it seems more likely you'll run into operating system or editor imposed limits based on line length. I once tested a bunch of editors and they all became unwieldy with a line length between 3000 and 6000 noting format effectors other than horizontal tab are interpreted as end of line and and end of line is a separator.

  This is all implementation stuff and not a concern of the standard other than by consensus as to what conforming implementation means. Without a sponsored validation suite that at least likely means staying inside any host operating system's imposed line length limits, incidentally safe for 'SIMPLE_NAME.

  As a complaint the contrived example shouldn't be taken seriously, it's not portable to begin with and not practical otherwise. Trying writing it up as a complaint on either identifier length or string length and see what kind of reaction you get from a tool vendor. This qualifies as a straw man argument as well.

  General Comments

  (tgingold, 23 Jul 2014) I am not opposed to extending to_string to one-dimensional arrays of scalar types.

  -- DavidKoontz - 2014-08-07

  Implementation without the posibility of errors

  I'm trying to steer this toward how to perform these functions without causing an error although like Tristan I don't see these as particular compact things to implement nor do I subscribe to their value.

  (RyanHinton 2014-08-13) As shown above, 'instance_name', ='path_name, and scalar 'image already create potentially unbounded strings. An extended composite 'image should not have additional restrictions imposed. I'm all in favor of robustness. In this case, I favor properly identifying and handling any error instead of trying to prevent it from ever happening. (end RyanHinton)

  Traversing a composite is closely related to doing so for an equality or inequality operator between two objects of the same composite type. I looked at two VHDL implementations and how equality/inequality done is strongly implementation dependent on object representation, but conversion to string is just extra steps. The present scalar predefined attributes seemed straight forward and simple.

  A hidden any-defined-type implementation isn't necessarily bound by VHDL's string handling implying the it's possible to avoid two passes (a first pass to determine the output string size). Converting from a string to 'IMAGE adds generating an output composite and consuming structures in the string representing composite element or subelements as well as dealing gracefully with end of string issues - e.g. 'IMAGE failed gracefully initially or 'VALUE for a too short or improperly manipulated string.

  (RyanHinton 2014-08-13) Nice insight on the similarity to the equality operator. One pass is sufficient for 'image. Algorithms for dynamic array sizing are well known, e.g. C++ STL vector type. Several other programming languages include a "string buffer" or "string stream" data type that allows arbitrary text to be added to the end. It's easy to define this facility in pure VHDL-93. One pass is sufficient for 'value. Each type's 'value definition simply needs to consume the outer parentheses and comma separation and call 'value for each element. Given the type metadata available to a compiler, this should be straightforward.

  Analysis

  My main concern is how to avoid errors. The two attributes or functions are on the close order of an equality operator in size and complexity. Analysis time size testing is about as complex as an equality operator. Analysis time size testing makes sense because a composite is a fixed size and its string representation will be as well. An 'IMAGE invocation should be analysis time testable. A constant string input to 'VALUE should/could generate an analysis time error. The time analysis requires under those cases provides a useful hint on practicality.

  (RyanHinton 2014-08-13) The prefix if a 'image attribute is a type, possibly unconstrained or not fully constrained. Consequently, the composite is not necessarily a fixed size (e.g. determined by a generic or port actual or access type allocation) and its string representation length cannot always be determined at analysis time.

  Simulation

  'VALUE might want to generate reports like std_logic_vector arithmetic operators for string length underflow or type mismatch during simulation. 'IMAGE could provide a warning and simply abrogate string conversion for string length limits. I'd only expect warning behavior to be useful or available for composite types. An implementation string size limit should likely also be made available for those of us kicking around the idea of doing VHDL on mobile computing platforms or just opposed to natural'range report statement strings.

  (RyanHinton 2014-08-13) 'VALUE already has a defined "it is an error" condition for invalid strings. No new handling or conditions need be defined. The actual behavior for this error is (appropriately) not defined in the standard.

  Synthesis

  There is no implication of structure implied by composite types for synthesis, at best a grouping by name. Further it's unlikely composite type 'IMAGE and 'VALUE attributes would be supported.

  (RyanHinton 2014-08-13) The use case that prompted this proposal is a test bench -- simulation only. But these attributes could see at least restricted implementation by synthesis tools, especially for defining constants. For example, I could use 'image in defining a ROM of error codes for a UART console interface.

  Synopsis

  Checking composites during analysis for 'IMAGE should cause an error. The same for 'VALUE and constant strings.

  The same should hold true for constants supplied by generics at elaboration time.

  Run time errors should not be generated. This implies abrogration by 'IMAGE and left value or default string character values for 'VALUE. Occurrences that would generate errors should generate report warnings. Potentially those warnings could be disabled.

  There should be an implementation defined string length limit. An implementation could allow simulator invocation limit modification. This limit supports preventing unwitting performance degradation and platform performance issues (where morality extends beyond VHDL simulation).

  And as of yet I'm not convince by the arguments for.

  (RyanHinton 2014-08-13) Run-time checks will be necessary in general. No new error conditions or reporting are required assuming the already potentially unbounded 'image and similar are appropriately handled. Implementations do and should define appropriate limits on object sizes. I'm content to amicably disagree on the utility of the feature.

  (-- DavidKoontz - 2015-02-13) In addition to string representations of values of elements of composites there appears to be a need for annotations describing an aggregate structure of a composite for purposes of compatibility with 'VALUE. If you look at 5.7 there is no existing string representation for composites other than for single dimensional arrays with an element type that is a character type and solely comprised of character literals.

  This isn't insurmountable itself, the only use for a string representation of a value applied as a value to an object is through the 'VALUE attribute. It does raises the question of the desirability for of formal element association, particularly for records. Also mindful of any restrictions on string length you could potentially allow comments generated specifying the object and it's elements names (for multidimensional array and record types), although as an implementor I'd be unhappy parsing it.

  There does appear to be a potential semantic restriction associated with the composition of a record type eligible for either to_string or 'IMAGE. Note in 5.7 there is no string representation for access types nor do they seem possible as input to 'VALUE.

  There's also practical limits to the usefulness of a string representation of a composite type. How many pages of a single aggregate representation of a structure are you willing to wade through? Should there be embedded format effectors for readability? This all relates to supported string length.

  To head off the need for needless arguments on errors I'd propose limiting the definition of erroneous for 'IMAGE and TO_STRING to representations of composites to those that can't be assigned to an object of the composite type with 'VALUE. It's likely the string representation for composite types will converge for the two functions. Further you could allow the production of such strings without causing an error, although a warning would be nice although I could see a desire to disable it. This would also support some implementation defined string length limit, potentially user controllable to limit just how big a report could be generated.

  For those cases were applying a string to 'VALUE does not result in an error it would provide another mechanism for formatted I/O.

  All these uses would imply a minimum supported strength length enabling use while enabling portability.

  Supporters

  -- MartinThompson - 2014-08-11

  -- RyanHinton - 2014-08-07

  -- Brent Hayhoe - 2014-08-15

  -- JimLewis - 2014-12-04

  -- MortenZilmer - 2015-01-21

  -- RobGaddi - 2015-02-20

  -- PatrickLehmann - 2016-02-11

  Add your signature here to indicate your support for the proposal

  Opposed

  Add your signature here to indicate your opposition for the proposal

  -- KevinJennings - 2016-10-14 -- Putting this into the language would preclude overloading to_string to produce a readable version. The to_string output would instead be a long single line string, what do I really want to do with that? Most likely not report it to a log file or the transcript window.