> > 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), 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. 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. DIez -- http://mail.python.org/mailman/listinfo/python-list
