Python from Wise Guy's Viewpoint

[Joe Marshall]

> Don Geddis <don at geddis.org> wrote:
>
>> For example:
>>        (defun foo (x)
>>          (check-type x (integer 0 10))
>>          (+ 1 x) )
>>        (defun fib (n)
>>          (check-type n (integer 0 *))
>>          (if (< n 2)
>>              1
>>              (+ (fib (- n 1)) (fib (- n 2))) ))
>>        (print (foo (fib 5)))
>
>> This program prints "9", and causes no run-time type errors.  Will
>> it be successfully type-checked at compile time by a static system?
>> Almost certainly the answer is no.

Dirk Thierbach <dthierbach at gmx.de> writes:
> It will be successfully type checked, because the static type system
> does not allow you to express assumptions about value ranges of types.

I was working on the assumption that the type language *would* allow
one to express arbitrary types.  Certainly one can create a
sufficiently weak static type system that terminates under all
conditions and produces correct answers within the system.  Lisp has
one:  everything is a subtype of type t and all programs pass.  The
inference is trivial.

But I surely wouldn't be impressed by a type checker that allowed this
to pass:

(defun byte-increment (x)
  (check-type x (integer 0 (256)))
  (+ x 1))

(defun fib (n)
  (if (< n 2)
      1
      (+ (fib (- n 1)) (fib (- n 2))))) 

(print (byte-increment (fib 13)))

> On the other hand, if there is no static type mismatch, that doesn't
> mean that the program will not crash because of runtime errors
> (division by zero, or dynamically checked restrictions).

I think most people here were assuming that passing an integer greater
than 255 to a routine expecting a single 8-bit byte is a type error,
and something that could cause a crash.