Anton van Straaten schrieb: > Marshall wrote: >> Can you be more explicit about what "latent types" means? > > Sorry, that was a huge omission. (What I get for posting at 3:30am.) > > The short answer is that I'm most directly referring to "the types in > the programmer's head".
Ah, finally that terminology starts to make sense to me. I have been wondering whether there's any useful difference between "latent" and "run-time" typing. (I tend to avoid the term "dynamic typing" because it's overloaded with too many vague ideas.) > there are usually many possible static > type schemes that can be assigned to a given program. This seems to apply to latent types as well. Actually the set of latent types seems to be the set of possible static type schemes. Um, well, a superset of these - static type schemes tend to be slightly less expressive than what the programmer in his head. (Most type schemes cannot really express things like "the range of this index variable is such-and-so", and the boundary to general assertions about the code is quite blurry anyway.) > There's a close connection between latent types in the sense I've > described, and the "tagged values" present at runtime. However, as type > theorists will tell you, the tags used to tag values at runtime, as e.g. > a number or a string or a FooBar object, are not the same thing as the > sort of types which statically-typed languages have. Would that be a profound difference, or is it just that annotating a value with a full type expression would cause just too much runtime overhead? In your terminology: > So, where do tagged values fit into this? Tags help to check types at > runtime, but that doesn't mean that there's a 1:1 correspondence between > tags and types. Would it be possible to establish such a correspondence, would it be common consensus that such a system should be called "tags" anymore, or are there other, even more profound differences? Regards, Jo -- http://mail.python.org/mailman/listinfo/python-list
