Op 2005-10-06, Diez B. Roggisch schreef <[EMAIL PROTECTED]>: >> >> 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 -- http://mail.python.org/mailman/listinfo/python-list
