VHDL Issue Number:        2057      

Language_Version          VHDL-2002
Classification            Language Definition Problem
Summary                   Access-typed parameters to predefined "=" and "/="
Relevant_LRM_Sections     4.3.2, 7.2.2, 14.3
Related_Issues            
Key_Words_and_Phrases     function parameters, access types, operators
Authors_Name              Peter Ashenden
Authors_Phone_Number      +61 (8) 8339 7532
Authors_Fax_Number        +61 (8) 8339 2616
Authors_Email_Address     peter@ashenden.com.au
Authors_Affiliation       Ashenden Designs
Authors_Address1          PO Box 640
Authors_Address2          Stirling, SA 5152
Authors_Address3          Australia

Current Status:           VASG-Approved

Superseded By:

------------------------
Date Submitted:           21 January 2005
Date Analyzed:            04 February 2005
Author of Analysis:       Chuck Swart
Revision Number:          3
Date Last Revised:        09 May 2005

Description of Problem
----------------------

The LRM prohibits function parameters of access type, yet defines "="
and "/=" as functions on access types.

4.3.2 states "For an interface constant declaration or an interface
signal declaration, the subtype indication must define a subtype that
is neither a file type, an access type, nor a protected type."

7.2.2 states "The equality and inequality operators (= and /=) are
defined for all types other than file types and protected types."
Thus, the operators are defined for access types.  7.2 also states
that "Every predefined operator is a pure function."  So the "=" and
"/=" operators defined for access types are pure functions that have
parameters that are of access types.  This contradicts 4.3.2.

14.3 defines the following in package STD.TEXTIO:

  type LINE is access STRING; -- A LINE is a pointer to a STRING value.

  -- The predefined operators for this type are as follows:

  -- function "=" (anonymous, anonymous: LINE) return BOOLEAN;
  -- function "/=" (anonymous, anonymous: LINE) return BOOLEAN;

Type LINE is an access type, so this also contradicts 4.3.2.

Note: I checked previous IRs, and could not find mention of this issue.


Proposed Resolution
-------------------

Remove the prohibition on access types in constant parameters (but not
in generic constants), and specify that a description is erroneous if
a pure function, or a subprogram of which the pure function is a
parent, updates a variable designated by an access value.  However,
the restriction on parameters and return types of methods of protected
types not being or containing access types should be kept.


VASG-ISAC Analysis & Rationale
------------------------------

The intent behind a pure function is that multiple calls to
the function with the same parameters will produce the same result.

From this perspective variables of access type are inherently impure,
because on multiple calls to a function the access values could be the
same, but the designated values could be different.

Possible solutions are:

1. Special case predefined "=" and "/=" operators for access types to
allow access types as parameters. This would imply that these operators
could not be overloaded and that these predefined operators cannot be
written in VHDL. Note that there are already implicit declarations in package
STD.STANDARD which cannot be written in VHDL, notable the declaration for
universal_integer.

2. Allow access types as constant parameters to pure functions.Add the
restrictions suggested by the submitter. In addition, prohibit reading
the variable designated by the access value parameter. This would
imply that one could only compare access values for equality, which
would severely limit their usefulness.

A partial solution taken from Ada, which might prove useful is the following:

    Ada 95 has an extended notation which is as follows (simplified
    for VHDL semantics):

    access_type_definition 
                 ::= ACCESS [general_access_modifier] subtype_indication

    general_access_modifier ::= ALL | CONSTANT

    Declarations with ALL or no general_access_modifier then the
    access is an access to variable and can be updated. Ir the
    general_access_modifier is CONSTANT the a designated object cannot
    be updated through a value of such a type.

3. Allow predefined operators to be IMPURE. This change would alter the
basic notion of staticness.

In the short term, solution 1 is the most straightforward.

In the long term, if VHDL adds abstract data types, then a more
general solution to the problem of allowed parameters to pure
functions will be needed.

VASG-ISAC Recommendation for IEEE Std 1076-2002
-----------------------------------------------

Interpret the LRM as if the Recommendation for Future Revisions had
been adopted.

VASG-ISAC Recommendation for Future Revisions
---------------------------------------------

Change 4.3.2 as follows:

The sentence reading:

"For an interface constant declaration or an interface signal
declaration, the subtype indication must define a subtype that is
neither a file type, an access type, nor a protected type."

should be changed to:

"For an interface constant declaration or an interface signal
declaration, the subtype indication must define a subtype that is
neither a file type, an access type, nor a protected type, except for
the predefined operators "=" and "/=" for access types."



-------------END OF IR----------------