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.