RE: [sv-bc] Re: [sv-ec] $typename follow-up

One rational for requiring an IEEE 1800 compliant tool to have a method
for producing a textual representation of the type of an object is so
the poor user can get a clue of what they need to change to make two
types the same, as in:

	...
   if (type(foo) != type(integer)) {
	$display (" foo is not type integer, instead it is type %s",
$typename(foo));
   }

which in many strictly typed complex languages, when using the run of
the mill processing tools this is a very difficult to determine:

% process foo.cxy
Error line 46: type of foo and bar do not match, assignment is illegal

Note that fulfilling this need does not require mandating each tool
emits the same string for a given input source.

And having $typename take a type_id as input would be fine for this
purpose.



Michael McNamara
mcnamara@cadence.com
408-914-6808 work
408-348-7025 cell


-----Original Message-----
From: owner-sv-bc@eda-stds.org [mailto:owner-sv-bc@eda-stds.org] On
Behalf Of Gordon Vreugdenhil
Sent: Thursday, June 22, 2006 3:45 PM
To: Michael Burns
Cc: sv-bc@verilog.org; SV_EC List
Subject: [sv-bc] Re: [sv-ec] $typename follow-up



Michael Burns wrote:

> 
> Hi Gordon,
> 
> Yeah, exact portability is a dream. Isn't it a nice one, though?
> 
> Anyways, the case I was concerned about was the one Brad raised, where

> useing $typename was the only way to distinguish between a packed
array 
> and an integer. I'm thinking about code like this:
> 
> if ($typename(foo) == "integer")
>   // do something
> else if ($typename(foo) == "packed array")
>   // do something else
> 
> What I'm now having trouble doing is thinking of what foo might be; 
> could it refer to a type parameter of a class:
> 
> class Foo #(type T = int);
>  T foo;
> ...
>  if ($typename(foo) == "integer")


Wouldn't this more safe (and likely more efficient) if you did:
    if (type(foo) == type(integer))
This is "true" for any matching type of integer.  The only
case in which $typename would differ is if "foo" was an
equivalent type rather than matching (in which case "typename"
is actually weaker which is an odd reversal in the spec).


There aren't many realistic situations that I can think of in which
one would need to distinguish between two types and where
the matching aspect of type() comparison wouldn't be sufficient.
It seems to me that such comparisons are much less error prone.

General uses of $typename in the manner that you have above
would require a *very* tight definition of $typename.  As
one example, what if I did:
     Foo #(Foo #( integer ))
The names of the inner type would have to be completely defined
in the spec (down to spacing, etc).

I can see a possible scenario in which one wanted a associative
array (or similar) mapping from type -> class (or value).  Since
the result of "type" isn't a value that you can capture,
$typename could be useful there.  But if that is the kind of
use model, I would rather have a "type_id" that generates
a unique integral value for a type rather than relying on
a string match.  If we really want to make all of this robust,
we probably should have a family of type operations:
    type_to_id(t)          // yields a unique integral type id
    id_to_type(t)          // yields the type (so that the following
work)
    type_match(t1,t2)
    type_equivalent(t1,t2)
    type_assignable(t1,t2)

This would at least explicitly expose the type calculus rather
than having ad hoc pieces be exposed as is the case now.

Gord
-- 
--------------------------------------------------------------------
Gordon Vreugdenhil                                503-685-0808
Model Technology (Mentor Graphics)                gordonv@model.com