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

Gord,

As soon as I reviewed the text in the LRM for $typename() I envisioned
a whole series of issues. Your bugnote for mantis 1511 does a good job
of listing several of them. Unfortunately I suspect that there are quite
a few more that have yet to be enumerated. As the language evolves there
will also be new corner cases to be addressed.

I do think that the whole concept of having a $typename() function is a
useful one (e.g. for debugging purposes). I have already jotted down a note to
make sure that we have a coding guideline informing our users to not expect the
strings returned by $typename() to be consistent across implementations. This
may be useful in some rare situation, but I have to believe that it is way too
problematic to get all cases defined in sufficient detail to accomplish this. I
would rather see other issues be addressed than to see that much energy plowed
into this. Where there are true issues to resolve, such as item 3) in your
bugnote, they should be defined.

>>3) "22.2 f)" says that types are prefixed with their scope name. Is that the
>>    full hierarchical path or the lexical path (ie. like %m)

I agree with your comments about using type() in place of $typename() when
comparing types.

Neil



Gordon Vreugdenhil wrote On 06/22/06 15:45,:
> 
> 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

-- 
---------------------------------------------------------------------
Neil Korpusik                                     Tel: 408-720-4852
Senior Staff Engineer                             Fax: 408-720-4850
Frontend Technologies - ASICs & Processors (FTAP)
Sun Microsystems
email: neil.korpusik@sun.com
---------------------------------------------------------------------