python improvements (Was: Re: New Language)

[Neel Krishnaswami]

Martijn Faassen <m.faassen at vet.uu.nl> wrote:
> 
> Ooh, lots of us would! Join the types-SIG. :)
> 
> This is not a small project, and has many consequences, though the
> run-time variety would be easier to do than the static-type checking
> variety. (which would report type errors during compile-time).
> 
> We have OPT, ERR and DOC reasons for doing type checking:
> 
> OPT -- the interpreter/compiler uses the type declarations to make our
>        code run faster. The more static the type checking, the better.

I think this is a bit of a myth. 

If you can declare that a variable is a machine integer or float, and
arrays of the same, you have enough information to get about 80% of
the speed benefit that static typing can win you.

Beyond that there isn't much you can do without fairly exotic
techniques, all of which have the common feature that they a) are very
hard to implement correctly, and b) make interfacing with foreign C
code much harder.

Before static typing for speed is tried (with its complicating effects
on implementation), I think it's better to go for the factor of 2
improvement that can be won via easy tricks like method caches,
variable lookup optimization, and reducing function call
overhead. (Look at Squeak Smalltalk for an example.)

Strong typing can also *cost* you speed, if you decide expressiveness
is important and you let your type system include allow parametric
types. For example, accessing and modifying an array with type [Foo]
(meaning a list of instances of Foo) will be slower than accessing a
list of arbitrary objects, because you need to add checks to confirm
that all additions to the list are of class Foo, rather than blindly
adding objects to the list.

Note also that it can be hard to declare 'machine integer' as a type,
if type-class unification becomes reality and you can subclass
Integer.

> ERR -- we get more robust code as the types are checked. It's nice when
>        this happens during compile-time, though run-time can also be
>        helpful.

With an interactive read-eval-print loop, run-time is just as good as
compile-time, IMO, because you can test your system incrementally, as
you build it.
 
> DOC -- we get more readable code as we can see which types go into a 
>        function.

These two are the real reason to go for type declarations, IMO.


Neel