[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