Luke Palmer wrote:
Okay, now we're starting to talk past each other. I /think/ Thomas orignially suggested that we use type inference to determine whether to lvalue cast an argument or not, which is what I got all worked up about.
Actually I was returning to the subject of co- or contravariance of parametric types but trying to avoid these terms. I gave an example how to get a Str into an Array of Int when you assume in general that Array of Int <: Array of Any. Which is reasonable only for reading because the reader doesn't care of the type and Int is compatible with such a reading. For writing you need the reverse relation because the writer expects an array that accepts Ints and and Array of Any does this. For a read-write Array both cases must hold, thus only type equality is sound. So when the compiler knows about a 'is rw' trait on a parameter and the type of an array---and it does so the latest when the call is attempted, but that is not the compiler then---it should reject the call!
I'm saying that you can't determine that kind of thing in general at compile time.
Of course not, but the question is than just shifted to: "do you want a runtime exception when sub foo( @a is rw ) is called with an Array of Int?" If you answer no, than you take the consequence that this Array of Int might contain other things than Ints. That's all.
There is no type inference per se in my argument. It just might help the compiler to gather the necessary type information to ask the above question at compile time.
Larry takes the point of view that the Str goes in but the Array knows that it should be an Int and nicely converts that for you. And actually Any might just be a glb (greatest upper bound) of Int and Str, written Int|Str in Perl6, so the type checker knows that *this* case is OK. But it will complain if Any isn't a glb of SomeOtherType and you call foo with Array of SomeOtherType. Note that Int|Str <: Str && Str <: Int|Str && Int|Str <: Int && Int <: Int|Str holds. Given an even more complex Any type that encompasses the general purpose types of Perl6---namely Str, Int, Num, Bool and Refs thereof--- the lazy Perl6 programmer gets what Perl5 did all the time. This is what is called "Render the Illusion of Simplicity".
This illusion fades when you get the compile time warning "no glb for Any and SomeOtherType" and you have to go figure what to do about it ;) But once again these might hit a strong programmer and the not so strong ones a kept in the illusion: "look I just use SomeOtherType and it works".
I'm all for an optional strong type system, as long as it
remains optional and mixable (so static things and dynamic things can
play nicely together, whether the module is static and the user dynamic
or vice-versa).
Optional in what sense? -- TSa (Thomas SandlaÃ)
