ExtendedUserDefinedAttributes < P1076

P1076 Web>Vhdl2019CollectedRequirements>ExtendedUserDefinedAttributes (2020-02-17, JimLewis) (raw view)EditAttach
---+ Extended User-Defined Attributes

<br />%TOC%

---++ Proposal Editing Information
   * Who Updates: Main.PatrickLehmann, &lt;Add YourName &gt;, ...
   * Date Proposed: 2016-07-19
   * Date Last Updated: 2016-07-19
   * Priority:
   * Complexity:
   * Focus: Testbench and Synthesis

---++ Requirement Summary

Meeting 2016-09-07: accepted as enhancement conditionally with Patrick required to get relevant motivating example otherwise downgrade to some day maybe

VHDL knows the concept of attributes. It has attributes pre-defined by the LRM and allows user to define own attributes (user-defined attributes). The underlying "object" of a (LRM-defined) attribute is not restricted. For example it can be a function, constant or signal. User-defined attributes are restricted to constant values. So a) user-defined attributes are not as powerful as LRM attributes and b) users cannot use the smart syntax to map attributes to user-defined utility functions.

This proposal requests more powerful user-defined attributes, which can also serve as a utility so solve other proposed language enhancements, which might be solved in pure (attribute based) VHDL code instead of heavy LRM changes.

---++ Related and/or Competing Issues:
   * None

---++ Proposal

TODO: text

---++ General Comments

-- Main.JonasBaggett - 2016-08-01 I have made a possible implementation for user defined attribute getters/setters here : [[%PUBURL%/P1076/EnhancedIntegers/bits_attribute.vhd][bits_attribute.vhd]]

-- Main.ThomasPreusser - 2016-09-10 This implementation sketch goes beyond the stated goal of making user-defined attributes similarly powerful as native LRM ones. It rather proposes a new concept of properties that uses attribute syntax. There is much magic going on in inferring the assignment syntax from the procedure prototypes. Since this is not explicit as it is, e.g., for C++ operator overloading, the formulation of a general rule set defining what syntax is actually inferred appears to be challenging. I would encourage to wrap this implementation proposal into its own requirement request specifically targeting the introduction of properties.

-- Main.ThomasPreusser - 2016-09-10 LRM attributes stick out by also having functions among them, e.g., for the generation of a string representation through the ='image= attribute as in <span>integer'image(i)</span>. This capability appears to be achievable through a very modest language extension allowing user-defined function attributes:

<literal>&nbsp; attribute image : function;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; -- Declaration of a function attribute<br />function to_string(x : T) return string;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; -- User-defined function<br />attribute image of T : type is to_string [T, return string]; -- Association of the specified function with the attribute<br /></literal>

In the end, the function attribute can still be considered a constant, namely something like a function pointer. Thus, I would not expect any serious implications for the implementation of tools. The benefit would be a more orthogonal language that allows to integrate user-defined types smoothly into standard concepts. The adoption of this extension would also allow to attach functions intuitively to the objects they refer to. For instance, entities might provide functions this way that only make sense in their immediate context because they derive properties in dependence of a generic parameter set. In the end, such an extension may be viewed as merely cosmetic since it essentially creates only an alias for the function name. The extremely intuitive result, however, appears to me to justify the supposedly small effort.
---++ Supporters

-- Main.PatrickLehmann - 2016-07-19

-- Main.JonasBaggett - 2016-08-01

-- Main.ThomasPreusser - 2016-09-10

_Add your signature here to indicate your support for the proposal_
Topic revision: r5 - 2020-02-17 - 15:34:30 - JimLewis
P1076