Signatures Required in Association Lists

Proposal Details

  • Who Updates:main.CliffordWalinsky , main.JimLewis
  • Date Proposed:December 20, 2012
  • Date Last Updated:
  • Priority:
  • Complexity:
  • Focus:General Language


Provide a way to unambiguously associate subprograms or subprogram instances with overloaded interface subprograms within generic association lists.

Current Situation

Like other declarative regions, generic clauses create regions in which newly-declared interface subprograms can be overloaded.

Rules specified in the LRM for positionally associating actuals with formals are sufficient to determine which subprogram is to be associated with an overloaded interface subprogram. However, association by name requires additional rules to determine how a subprogram is associated with one of possibly many overloaded interface subprograms.

As an example consider the following generic clause:

generic( procedure foo(x : integer); procedure foo(x : bit) );

A generic map aspect using this clause, employing named association, could only specify the following ambiguous specification:

generic map( foo => foo_integer, foo => foo_bit )

where foo_integer and foo_bit are names of previously declared procedures visible at the point of the generic map. This generic map aspect violates the following condition of section

"Similarly, for a formal generic type, a formal generic subprogram, or a formal generic package, it is an error if the formal is associated with more than one actual."

Candidate: Signatures in Generic Map Aspects

We propose to resolve the ambiguity of associating subprograms with overloaded interface subprograms by expanding the grammar of generic_association_list to permit an optional signature to be present following a generic name that designates an interface subprogram. The signature will describe the parameter and return-type profile of the designated interface subprogram.

In the prior example, the following generic map aspect will be specified:

generic map( foo [integer] => foo_integer, foo [bit] => foo_bit )

Use Cases

Consider creating a generic matrix package. The matrix elements can be specified when the package is instantiated, as long as the element type supports basic arithmetic.

package matrix_pkg is
  generic (
    type ELEM;
    function "+" (l, r : ELEM) return ELEM is <>;
    function "-" (l, r : ELEM) return ELEM is <>;
    function "-" (arg : ELEM) return ELEM is <>  -- unary minus, returns arithmetic inverse
    function "*" (l, r : ELEM) return ELEM is <>;
end package matrix_pkg;

My reading of the LRM (RyanHinton - 2013-04-11) suggests that this will work fine with positional or default associations, but overriding the unary and binary "-" operators via named association won't work. An example where one might want to overload these is interpreting


as finite field elements over GF(2).

function noop (arg : std_logic) return std_logic is begin 
  return arg;
end function noop;

package gf2_matrix_pkg is new matrix_pkg
  generic map (
    ELEM => std_logic,
    "+" => "xor", 
    "-" [ELEM, ELEM return ELEM] => "xor", -- is the signature required on the actual as well? seems like it shouldn't be...
    "-" [ELEM return ELEM] => noop, 
    "*" [ELEM, ELEM return ELEM] => "and");

Arguments FOR

If we don't include this change, package generic maps will be limited. It should have been included in VHDL-2008.

Arguments AGAINST

Named association isn't strictly necessary. Many programming languages don't allow it at all. Also, it appears that defaults of "<>" will still work without this upgrade. (RyanHinton - 2013-04-11: I wrote this argument, but I don't think it's a good one. Rebutting myself, named association is allowed in every other association list context. It would be ludicrous to not allow it in this case.)

General Comments


-- Brent Hayhoe - 2012-12-17

-- RyanHinton - 2013-04-11

Add your signature here to indicate your support for the proposal

Edit | Attach | Print version | History: r5 < r4 < r3 < r2 < r1 | Backlinks | Raw View | Raw edit | More topic actions...
Topic revision: r3 - 2013-04-11 - 19:43:56 - RyanHinton
Copyright © 2008-2022 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback