Re: [sv-ec] Sideways casts (Mantis 1356)

The additional clause in (2) makes that sentence rather difficult to
read which is why I suggested a separate bullet. We haven't really
carefully defined a bunch of the terminology related to your
question on (1). I'll need to find some time to look that over more
carefully in terms of the 1356 text. Perhaps someone else on
the committee can help out a bit on some of this too.

Gord.

On 6/7/2011 1:37 PM, Tipp, Brandon P wrote:
> This might be splitting hairs, but case (2) explicitly states "This type of assignment requires a run-time check as provided by $cast." But, given the existence of interface classes, the phrase "the type of the source expression is a superclass..." is overly restrictive and would theoretically not succeed for a run-time check. Since this is only a problem in the context of interface classes, I think that it would be appropriate to make the amendment from 1356 referring to 3293. Change the text of case (2) to this:
>
> 2. The type of the source expression is cast-compatible with the destination type, that is, the type of the source expression is a superclass of the destination type *or is an interface class type *and the source is an object that is assignment compatible with the destination type. This type of assignment requires a run-time check as provided by $cast.
>
> Looking at case (1), Is it implied that an implemented interface class is a superclass of the implementing class? Does that require clarification as well?
>
> -Brandon
>
>
> -----Original Message-----
> From: owner-sv-ec@eda.org [mailto:owner-sv-ec@eda.org] On Behalf Of Gordon Vreugdenhil
> Sent: Tuesday, June 07, 2011 10:50 AM
> To: Tipp, Brandon P
> Cc: SV_EC List
> Subject: Re: [sv-ec] Sideways casts (Mantis 1356)
>
> In 3293, see case (2):
> ...the type of the source expression is a superclass of the
> destination type...
>
> The "type" here is the *expression* type, not the type of the actual
> handle. That
> is the dynamic part of the check later in the sentence. All expressions
> have
> static types (other than the literal null which has a polymorphic type
> and is
> thus covered separately in case 3).
>
> So 3293 makes the sideways cast illegal.
>
> In general, statements about "illegal" types, etc. are expected (if not
> required)
> to be determined at elaboration time. The only cases which aren't are the
> explicit run-time checks specified as such. This is important in real
> code as
> users get rather annoyed by "static" type errors after 2 days of
> simulation.
> It can result in errors from "dead" code that contains static type
> errors but
> that is the tradeoff for not getting late "static" errors and is why we need
> to be clear about the rules for interface classes.
>
> The simplest fix would be in fact to ignore any static type relationship
> involved
> with interface classes in a $cast -- basically just to say as an
> additional bullet
> that the cast requires a run time check if the source is an interface
> class. That
> means that you would not get errors for code involving "infeasible" type
> relationships until run time. If you'd want such errors at elab rather
> than sim
> time for infeasible interface class casts, we'd have to define the rules for
> that differently than the current 3293 text.
>
> Gord.
>
> On 6/7/2011 10:35 AM, Tipp, Brandon P wrote:
>> Is it clear in 3293 if "source is a subtype of dest" or "dest is a subtype of source" are referring to the class types of the variable that are passed to $cast, or the class types of the handles that are passed to $cast? Since $cast is explicitly a dynamic cast I had assumed the latter. I'd hate to have to make further modifications to 3293 to clarify this, but making sideways casts would be a significant hole for 1356 in the spec. For example:
>>
>> function void loop_back(GetImp#(int) in);
>> PutImp#(int) out;
>> int item;
>> assert($cast(out, in));
>> in.get(item);
>> out.put(item);
>> endfunction
>>
>> In the above function, I expect that the handle to "in" implements both GetImp#(int) and PutImp#(int), but I don't necessarily have a common derived class type that I can cast "in" to in order to access the "put" method.
>>
>> I know that one of the motivations 3293 was to add a static check to $cast, but I don't see anything that requires the errors conditions to be static vs. dynamic in the proposal. If an implementation chooses to perform a static check, that implementation would have to ensure that it doesn't incorrectly report illegal type casts for sideways casts. I'd rather not put any restrictions to say that there must only be a run-time check, nor any requirements that there must be a complex static check, for any call to $cast.
>>
>> By the way, 8.25.4 is one section of 1356 that I touched the least and I think needs a good deal of cleanup, especially in the language of the text surrounding the examples. The examples show what we want to do, but the text doesn't do a very good job of describing it.
>>
>> -Brandon
>>
>> -----Original Message-----
>> From: owner-sv-ec@eda.org [mailto:owner-sv-ec@eda.org] On Behalf Of Gordon Vreugdenhil
>> Sent: Tuesday, June 07, 2011 9:07 AM
>> To: SV_EC List
>> Subject: [sv-ec] Sideways casts (Mantis 1356)
>>
>> I raised this earlier as part of my long list of editorial and other
>> questions.
>>
>> In 8.25.4, there is the following:
>>
>> GetImp #() get_ref;
>> Fifo#() fifo_obj = new;
>> PutImp#() put_ref = fifo_obj;
>> ...
>> $cast(get_ref, put_ref);
>>
>> This violates the previous requirement that either "source is a subtype
>> of dest"
>> or "dest is a subtype of source" in order for the cast to be legal. Here
>> the get_ref and put_ref have unrelated types, other than the fact that they
>> each could feasibly contain a handle to a class that implements both
>> interface
>> classes.
>>
>> In general, if we allow such casts, do we want to say anything about the
>> (static) legality of such casts or just have a run-time check
>> requirement in all
>> cases involving interface classes?
>>
>> A static statement about legality would have to involve a more interesting
>> explanation of "feasible implementation paths" involving the types of
>> the expressions in the cast. Defining this as run-time only would
>> potentially result in very late error reporting. In any case, the rules
>> for this
>> will need to be explicitly aligned with the new rules we just passed in
>> 3293.
>>
>> Gord.
>>
>> --
>> --------------------------------------------------------------------
>> Gordon Vreugdenhil 503-685-0808
>> Model Technology (Mentor Graphics) gordonv@model.com
>>
>>
>> --
>> This message has been scanned for viruses and
>> dangerous content by MailScanner, and is
>> believed to be clean.
>>
> --
> --------------------------------------------------------------------
> Gordon Vreugdenhil 503-685-0808
> Model Technology (Mentor Graphics) gordonv@model.com
>
>
> --
> This message has been scanned for viruses and
> dangerous content by MailScanner, and is
> believed to be clean.
>

-- 
--------------------------------------------------------------------
Gordon Vreugdenhil                                503-685-0808
Model Technology (Mentor Graphics)                gordonv@model.com
-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.