unsafe polymorphic cast turns off typechecking?

[chrisichris]

When explicitly casting a value polymorphic than it can be used as any type even incosistently

ie the following code compiles althoug x is used as number and as string (and than gives of course a runtime error):

> fn x = (x = x as ~Object unsafely_as 'a; _ = x + 1; strLength x)

fn2 is 'a -> number = <code$fn2>

> fn 1

java.lang.ClassCastException: yeti.lang.IntNum cannot be cast to java.lang.String

        at code$fn2.apply(<>:1)

        at code.apply(<>:1)

        at yeti.lang.compiler.eval._1(eval.yeti:98)

        at yeti.lang.compiler.eval.execClass(eval.yeti:76)

        at yeti.lang.compiler.eval$evaluateYetiCode$._0(eval.yeti:485)

        at yeti.lang.compiler.eval$evaluateYetiCode$.apply(eval.yeti:461)

        at yeti.lang.Fun2_.apply(Unknown Source)

        at yeti.lang.compiler.yeti.repl(yeti.yeti:59)

        at yeti.lang.compiler.yeti.main(yeti.yeti:217)

Seems like a nice feature because this way you can make yeti sort of dynmically typed for specific values. 

But is it realy intended, shouldn't x be infered as number (or string) and than the compiler fail on unification with the other type?.

[Madis]

Making Yeti dynamic isn't really intended, but yes, unsafely_as is called
unsafely for a reason - using it breaks the typesystem soundness,
especially when it's not a cast between two Java types.

[chrisichris]

I know but couldn't such 'polymorphic unsafely_as' type be treated like any argument type, so that it is open to any but just one value.

so that the type of 'x' in

>fn _ = (x = 1 as ~Object unsafely_as 'a; _ = x + 1; strLength x);

is the same way treated as the type of x in

>fn x = (x + 1; strLength x);

[Madis]

On Thu, 2 Oct 2014, chrisichris wrote:

> I know but couldn't such 'polymorphic unsafely_as' type be treated like any
> argument type, so that it is open to any but just one value.
> so that the type of 'x' in
>
> >fn _ = (x = 1 as ~Object unsafely_as 'a; _ = x + 1; strLength x);
>
> is the same way treated as the type of x in
>
> >fn x = (x + 1; strLength x);

No, it can't be. All casts (even usual as) disassociate the types, so the
normal inference rules won't work anymore.