RE: {Spam?} Re: [vhdl-200x] Image attribute for array types

I like taking the conservative view when it comes to language design.  But not too conservative. :-)  I'll discuss your arguments in order.

* Yes, I can define my own function here.  I could define my own "image" and "value" functions to convert back and forth for scalars, too.  Since it's built-in for scalars, I would like to build it in for composite types.

* There is a perfectly natural format, including for records: the VHDL aggregate syntax.  I suggested the positional syntax for brevity.  If we want the named association syntax, I suggest we extend to_string and add an argument to control formatting.

* Well, I think that's a good example of the format I suggested; everyone knows std_logic_vector.  But I agree it doesn't strongly motivate the enhancement.  

** One good use case is a record-of-records-of-records-of-... defined across 10+ packages.  Currently, to get a string representation of one of these values I have to either (a) write a big, hairy, fragile function at the top-level and hope none of the record types change, or (b) go back and change a bunch of old code to define "to_string" for each type -- and anyone who modifies the packages has to keep this function in-sync.  Both options are bad.  But this case is harder to express in an email.

** More good use cases include real_vector and integer_vector and time_vector and boolean_vector and ....  

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. :-)

'Image already exists for scalars.  Why leave out composite types?  And that's the real question I'm trying to ask -- it's not rhetorical.  And I take your formatting objection seriously -- if we can't find a natural format for the result, it may be better not to define it at all.  I think the VHDL aggregate syntax is easy to produce, easy to parse (for 'value), and natural to any designer who uses these types.

What do you think?

- Ryan

-----Original Message-----
From: owner-vhdl-200x@eda.org [mailto:owner-vhdl-200x@eda.org] On Behalf Of tgingold@free.fr
Sent: Monday, July 21, 2014 1:45 PM
To: vhdl-200x@eda.org
Subject: {Spam?} Re: [vhdl-200x] Image attribute for array types

> Is there any reason not to create a 'image attribute for composite 
> types (arrays and records)?  Right now it only exists for scalar types 
> like integer, real, etc.  One possible definition is a paren-enclosed, 
> comma-delimited sequence of the element images from left to right 
> (array) or first-to-last defined (record).  I believe this would make 
> X'image a valid VHDL aggregate expression representing the current 
> value of X.  It's easy to define, unambiguous, and quite general.

Arguments against (conservative view):

* You can easily write your own image/to_string function, given that
  it is defined for scalar types (but access).
* There is no natural format (particular for records)

> Example:
> 
> 
> process images is
>   variable ary : std_logic_vector(0 to 3) := b"011";
>   variable ln  : LINE;
> begin
>   write(ln, ary'image);
>   writeline(OUTPUT, ln);
> end process;
> -- Will print "('0','1','1')" according to my suggestion.

Not the best example as there is already hwrite or to_hstring for std_logic_vector.

Regards,
Tristan.

--
This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.



-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.