🚀 go-pugleaf

beihl@ncrcol.ColumbiaSC.NCR.COM (Gary Beihl) writes:

> In article <1993Jan4.225957.26359@viewlogic.com> sunder@viewlogic.com (Sunder Singhani) writes:
> >
> >The above IS ambiguous. Explanation follows -
> 
> IMHO, there is NO ambiguity.  Sufficient information is available.
>  
> >-- 4    FUNCTION To_X01  ( b : BIT_VECTOR        ) RETURN  std_logic_vector;
> >-- 5    FUNCTION To_X01  ( b : BIT_VECTOR        ) RETURN  std_ulogic_vector;
> > 
> >Of these you are choosing 4, 5 explicitly by using type qualification -
> >ie bit_vector'("00"). 5 returns std_logic_vector and 4 returns std_ulogic_vector.
> 
> So far, so good.  Yes, there are two candidates with the same parameter and
> result profile.
> 
> >The first one when indexed gives you an element of std_ulogic, and the latter
> >gives std_logic. Now, std_logic is a subtype of std_ulogic, which implies
> >both have the same base type which is std_ulogic. Hence, you end up
> >with two interpretations, which is erroneous. The final type qualification
> 
> Not so fast.  Just because the parameter/result profiles match doesn't mean
> the declaration is ambiguous.  According to LRM 10.5 (The Context of Overload
> Resolution) there is a list of rules to be considered along with syntax and
> scope/visiblity rules.  The first of these is:
> 
>   "1. Any rule that requires a name or expression to have a certain type,
>       or to have the same type as another name or expression."
> 
> Since this is a constant declaration with a default expression, the following
> rule for interface objects (LRM 4.3.3) seems applicable:
> 
>   "...The type of a default expression must be that of the corresponding
>    interface object."
> 
> This narrows the search down to a single choice.  Unless I've missed 
> something, Model Technologies appears to be doing the right thing here.

You didn't include the declaration containing the reference, so I have to infer
things from some of your statements:

* I assume that the type mark of the constant is std_logic or std_ulogic.

* I assume that the initial-value expression consisted of an indexed name whose
	prefix was a function call.

Then:

I think the reference is ambigious because the overload resolution rules 
don't apply to indexed names.

Section 10.5 begins with "Overloading is defined for subprograms and for
enumeration literals."  The next paragraph reinforces that overload resolution
determines the meaning of occurences of operators and enumeration literals,
but not indexed names, slice names, etc.

The rules about "Any rule that requires a name or expression..." is involved
here, but not enough to resolve the function reference.  The expression must 
be of the same base type as the constant, but that only constrains the result 
type of the indexed name.  A known indexed name result type does not constrain
the indexed name prefix type (many array types could have the same element 
type).

Also, you said, "This narrows the search down to a single choice."  Again, I 
can't see the original code, but even if resolution address indexed names, 
would it make a difference?  Aren't Sunder's comments correct:

	"The first one when indexed gives you an element of std_ulogic, and 
	the latter gives std_logic. Now, std_logic is a subtype of std_ulogic,
	which implies both have the same base type which is std_ulogic."

What seemed to "narrow the search to a single choice"?

(By the way, in VHDL 1992, overload resolution applies to the "basic 
operations" of indexing, slicing, aggregation, assignment, etc., so an
analyzer will be able to resolve more cases.)
--
------------------------------------------------------------------------------
Daniel S. Barclay                    --who's still searching for a good 
CAD Language Systems, Inc.           signature, not liking any of his recent
Suite 101, 5457 Twin Knolls Rd.      feeble attempts to improve on the whiny:
Columbia, MD  21045  USA             Why can't _I_ think of a good signature?