Re: [vhdl-200x] Image attribute for array types

First, a humble request.  I have a great deal of respect for you, Tristan, for writing a VHDL compiler.  So I'm sad when I can't understand your newsgroup posts.  I would love it if you would spend a little more time and text teaching me about the complexities, background, your experience, and why you hold a particular opinion.  

Next, if the visibility rules are wrong, please write up a proposal and/or bring it up on the list!  I work on the (few) aspects of VHDL that I know with no implication that other aspects aren't as important or more important.

Now I'll try to share my opinion without being too verbose.  

Long /= impossible to read.

Long = possibly difficult for a human to use without reformatting.

Computers are good a dealing with long strings.  It's easy to imagine a little GUI that could read in positional aggregates (array or record) and display them nicely.  Usually I'll take this kind of string, throw it in an Emacs buffer, and define a quick keyboard macro to reformat it to make it easy for this human to read.

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 I know what it means.  And it's long.

Long /= we shouldn't put it in the language because nobody can possibly get any utility out of it.

I think a simple rule to generate all cases is easier for compiler writers *and* LRM writers than trying to carve out which uses are holy and which are evil.  For example, David Koontz's case "std_logic_vector(0 to natural'high/4)" fits in your suggested framework and is much longer (bytes) than my record-of-records... aggregate.  

I'm currently using this syntax in assertion reports -- assertions that I don't *want* to see.  It would be great to just call 'image and go ahead writing my test bench.  Then if/when I hit one of these assertions, if I have trouble reading the result and my Emacs tricks aren't working, I can overload to_string to provide whatever formatting is more readable for the situation at hand.

I want to fill what appears to me as a hole in the language.  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.

- Ryan

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

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

I think there is no natural and usable output format.  A soon as the type is too complex (record of records), the output would be very long and therefore unreadable.

Pragmatic, I am not opposed to extend to_string to one-dimensional array of scalar types, using string representation if the element type is an enumerated type only of characters (so that the output would be nice for bit vectors and std_logic vectors - but note that to_string for a string won't be the identity) and positional aggregate like format for other element types ('like' because there is no positional aggregate for less than two elements).

[ I also think the priority must be fixing issues in the current LRM.
 (For example I am not sure visibility rules are correct)].

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.