VHDL Issue Number:      0070
Classification:         Language Definition Problem
Language Version:       VHDL-87
Summary:                Should type-conversion fns. match direction of data flow?
Related Issues:         None.
Relevant LRM Sections:  4.3.3.2
Key Words and Phrases:  Association list, type-conversion function
Current Status:         Submitted
1076-1993 Disposition:  Closed (All Issues Completely Addressed)
Disposition Rationale:  LRM was updated.
Superseded By:          N/A
-----------------------
Date Submitted:         1991/01/15
Author of Submission:   Doug Dunlop
Author's Affiliation:   Intermetrics, Inc.
Author's Post Address:  4733 Bethesda Ave #415
                        Bethesda, MD  20814
Author's Phone Number:  (301) 657-3775
Author's Fax Number:    
Author's Net Address:   dunlop@inmet.inmet.com
-----------------------
Date Analyzed:          TBD
Author of Analysis:     TBD
Revision Number:        $Revision: 1.9 $
Date Last Revised:      $Date: 1995/08/03 16:28:14 $


Description of Problem
----------------------
Consider the following example:

   package p is
      procedure p1(variable x : in  integer);
      procedure p2(variable x : out integer);
   end p;
   package body p is
      procedure example is
         variable v : integer := 0;
         function f(y : integer) return integer is
         begin
            ...
         end f;
      begin
         p1(x => f(v)); -- Call 1
         p2(f(x) => v); -- Call 2
         p1(f(x) => v); -- Call 3
         p2(x => f(v)); -- Call 4
      end example;
      ...
   end p;

It seems clear the use of the type-conversion function is meaningful for
the call marked Call 1.  Function f in this case is used to transform the
input v prior to invoking p1.  Similarly, Call 2 is meaningful since f
is used to transform the result returned in parameter x when the call
completes.  The same however, cannot be said for the use of the type-conversion
functions in Call 3 and Call 4.

It is unfortunate that the language allows type-conversion functions to
appear in positions which suggest data flow that is contrary to that
implied by the mode of the formal.  Consideration should be given to making
Call 3 and Call 4 illegal since this is likely a user error and in any
event an unnecessary source of confusion.

Proposed Resolution
-------------------
Consider requiring the presense of type-conversion functions in an association
element to match the direction of data flow implied by the mode of the formal.


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


VASG-ISAC Recommendation for IEEE Std 1076-1987
-----------------------------------------------
TBD


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