"no variable or argument declarations are necessary."

Antoon Pardon apardon at forel.vub.ac.be
Thu Oct 6 15:59:35 CEST 2005

Op 2005-10-06, Diez B. Roggisch schreef <deets at nospam.web.de>:
>> I can't help but feel that a lot of people have specific typechecking
>> systems in mind and then conclude that the limits of such a symtem
>> are inherent in typechecking itself.
> I've been writing a type-checker for my diploma thesis for a functionnal 
> programmming language. And it _is_ limited. The very subject of my work 
> was to explore extended type-checking methods (so called 
> multi-level-specifications),, which can be shwon to be NP-hard problems. 
> Which naturally limits the domains they can be used to.
>> IMO a good type system doesn't need to limit python in any way.
> It has to. certainly. Take alone the list implementation - while 
> typesystems as ML allow for generics (with much less typing overhead 
> than JAVA), the list is always homogenous. Which python's aren't - and 
> that a great thing(tm),

Suppose we have a typesystem which has the type ANY, which would mean
such an object could be any type. You could then have homogenous lists
in the sense that all elements should be of the same declared type and
at the same time mix all kind of type in a particular list, just
as python does.

So how would this limit python.

> even though ususally the contents of a list 
> share some common behaviour. And that exactly is the key point here: in 
> a statically typed world, that common behaviour must have been extracted 
> and made explicit.

Would my suggestion be classified as a statically typed world?

> Which is the cause for that notorious java io API. 
> And, to extend the argument to ML-type type-checking, there you need a 
> disjoint union of the possible types - _beforehand_, and the code 
> dealing with it has to be aware of it.
> In python OTH, I just pass objects I like into the list - if they 
> behave, fine.

But now we are no longer talking about how typechecking would limit
the language but about convenience for the user.

Antoon Pardon

More information about the Python-list mailing list