python improvements (Was: Re: New Language)

[Martijn Faassen]

Neel Krishnaswami <neelk at brick.cswv.com> wrote:
> 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. 

Perhaps so, but..

> 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.

What about classes and methods though? If you want to optimize some of
the dispatching it may be pretty helpful to have static typing.

Similarly, in a dynamic system you'd *lose* your nice declarations
as soon as you pass them into some function that doesn't have them
(barring type inferencing, which is about as non-easy as static typing,
if not more :).

> 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.)

Definitely agreed. (method caching may not always be that easy, though,
given __getattr__ and friends..)

> 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.

Yes, as noted on the types-SIG, too.

> 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.

Not all people agree on this. I think some interface conformance 
checking at compile-time would for instance be nice.

But I definitely agree that the ERR component of static type checking is
overrated.

>> 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.

The idea of these notations is that everybody gets to pick their
favorites. :)

Regards,

Martijn
-- 
History of the 20th Century: WW1, WW2, WW3?
No, WWW -- Could we be going in the right direction?