[Types-sig] Implementability
Tim Peters
tim_one@email.msn.com
Fri, 17 Dec 1999 04:28:12 -0500
[Tim]
> declared_int = unknown
>
> is an error, but
[Martijn Faassen]
> Or, if you're interfacing with untyped python, this could raise a
> run-time exception if unknown doesn't turn out to be an integer. Or do
> you disagree with this?
Yes and no <wink>. I think "type-checked Python" needs at least three
different compile modes, because nobody is claiming we *can* check the
entire language in a bulletproof way -- and when we can't, different people
will want different behaviors at different times for legitimate reasons.
1. Anything that can't be proven safe at compile-time is a compile-time
error (that's where I disagree with you above).
2. Anything that can't be proven safe at compile-time is checked
at runtime (that's where I agree with you above).
3. Anything that can't be proven safe at compile-time emits a
compile-time warning, and there's no guarantees one way or the
other about what happens at runtime (where I don't even agree
with myself).
If someone doesn't want any of those behaviors, fine, don't enable
type-checking.
>> unknown1 = unknown2
>>
>> is not. Whether
>>
>> unknown = declared_int
>>
>> should be an error is a policy issue. Many will claim it should
>> be an error, but the correct answer <wink> is that it should not.
> This would seem to be the natural way to do it; I'm not sure why many
> would claim it should be an error. Could you explain?
This is what I call a "self-denying prophecy". That is, by implicitly
ridiculing the position before anyone took it, I graciously saved everyone
from suggesting it <wink>.
> I agree.
I'm going to save that sentence and paste it into other replies as needed.
thanks!-ly y'rs - tim