On 24 Jul 2014, at 7:27 am, ryan.w.hinton@L-3com.com wrote: > I'll put the conclusion here at the top for impatient people like me. It all boils down to "long /= wrong". And I'm not asking for the only-right-and-best-possible 'image. Just a good, general, easy-to-describe 'image. And I'll put my opinion out there succinctly. If you can't have a 'image attribute that won't operate error free for valid VHDL expressions it doesn't belong in the language. VHDL has no error recovery mechanisms. Got no problem with you what you want to do. Have a problem putting something in the language that doesn't work for valid VHDL. And like Martin apparently I think you have a better chance of driving a new language standard than changing the relationship between string indexes and integer ranges expressed in package standard. The amount of work you might be inferring for tool vendors is likely prohibitive, particularly from a synthesis vendor point of view supporting something only of use for verification. This functionality seems to imply a predefined attribute, which seems the only way you can apply an anonymous type. You can: Try finding a compelling reason to change the relationships in package standard (and the problem still persists if you just increase integer range, records and arrays can simply be bigger). Try and get everyone to accept a new image attribute for composites that fails gracefully, where no one expects the whole image to be valid if the size is too large for a string (e.g doesn't cause an error, foreshortens the result or even outputs to stdout directly). Propose an image attribute that writes directly to output. You can try to convince those defining the standard it's okay if an extended but otherwise previously defined for scalars only 'image attribute fails gracefully for those composites too large to be contained in a string. You can modify the 'image attribute definition to allow soft failure, potentially based on implementation or user defined limits. > 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. It sounds like you need a proposal. This appears to be an emotional appeal and not a sustainable argument. I don't know of compelling use case for your "221-line record-of-records-of-... " composite report 'image that I'd agree to being of value any more than Tristan. (And beauty is apparently in the eye of the beholder). Martin's comment on the other hand is tempting enough want to go read python's source to understand the how you could not care about string array limits. Ada appears to use the 'Modulus attribute to modify predefine operators it may be possible to do that for the 'image function's type argument. There's always implementation defined behavior. Note you've also had Brian looking to Ada for inspiration. So far all you've stated is what you want without doing any of the heavy lifting describing how to accomplish it. It sounds ripe for a proposal. (And yes I write compilers and software, too, and no it doesn't show up on my LinkedIn account, thanks for visiting.) I don't think what you want is hopeless you simply haven't presented a compelling case. You've already got an audience intellectually engaged in how to accomplish what you want and some of us don't even see it as useful. (Write a proposal!). -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.Received on Wed Jul 23 17:48:40 2014
This archive was generated by hypermail 2.1.8 : Wed Jul 23 2014 - 17:49:18 PDT