3 ms·

I hope it is obvious that Python values are members of a single static-type, this massive sum-type that combines a type-tag with a value, summing together all o

by jholman 10y ago

I hope it is obvious that Python values are members of a single static-type, this massive sum-type that combines a type-tag with a value, summing together all of the possible types-in-the-python-sense. That is to say, from the perspective of static typing, dynamic languages are uni-typed. In languages with explicit static types and explicit Tagged Unions, it's not unreasonable to iterate across a homogeneous sequence of tagged unions, all of the same type. For example, Option<Int>. This is just a particular instance of the general pattern of iterating across a heterogeneous sequence, introspecting on whether a given value is of type Int or of type NoneType. Unless you want to allege that Null is a member of Integer (in a sane and healthy type system). The point of this is that I'm skeptical that these are "invariably code smells". For example, our Option<Int> values might come from a SQL field that is a nullable integer. It seems entirely fair to iterate across them.

colanderman 10y ago
Maybe it is not clear from my other comments but we are in violent agreement :) Tagged unions (and even more general RTTI) have a common interface and therefore are homogeneous: a well-written iteration always accesses such elements first through the tagged-union (or RTTI) interface. To me, code which acted on such elements without first consulting the common interface would be "smelly". e.g. code which assumes every other item is a string, or code which uses a list as an ad-hoc structure. There's almost always a better way to write such code. (As an aside, I find the explicit use of RTTI a smell in and of itself, but one unrelated to containers. Code which today does two different things to some input, based on whether it's an integer or string, likely tomorrow will need to do three different things, two of which involve an integer. Tagged unions are almost always preferable.)
- jholman 10y ago
  We are mostly in violent agreement, yes. :) The nuance where I disagree with you was the point of my comment. I claim that there's no principled distinction between tagged unions and RTTI. (Except that of course usually implementations that refer to themselves with the phrase "tagged union" are a little more, uh, sophisticated, in exactly the kind of way that your comment about "likely tomorrow will need to do three different things.." alludes to eventually having a need for.) Unless you can draw a principled distinction, then you can't on the one hand say "sequences of tagged unions are homogeneous" and on the other say "python sequences are potentially heterogeneous, and if you have a tuple of heterogeneous data and you iterate on it, that's invariably a code smell". Can you? I mean, unless by "code smell" you mean "thing that's worth a double-look, because although it might be good code, it's easy for it to be evil code". In which case, we're in total agreement.

by jholman 10y ago

colanderman 10y ago

Maybe it is not clear from my other comments but we are in violent agreement :) Tagged unions (and even more general RTTI) have a common interface and therefore are homogeneous: a well-written iteration always accesses such elements first through the tagged-union (or RTTI) interface. To me, code which acted on such elements without first consulting the common interface would be "smelly". e.g. code which assumes every other item is a string, or code which uses a list as an ad-hoc structure. There's almost always a better way to write such code. (As an aside, I find the explicit use of RTTI a smell in and of itself, but one unrelated to containers. Code which today does two different things to some input, based on whether it's an integer or string, likely tomorrow will need to do three different things, two of which involve an integer. Tagged unions are almost always preferable.)

jholman 10y ago
We are mostly in violent agreement, yes. :) The nuance where I disagree with you was the point of my comment. I claim that there's no principled distinction between tagged unions and RTTI. (Except that of course usually implementations that refer to themselves with the phrase "tagged union" are a little more, uh, sophisticated, in exactly the kind of way that your comment about "likely tomorrow will need to do three different things.." alludes to eventually having a need for.) Unless you can draw a principled distinction, then you can't on the one hand say "sequences of tagged unions are homogeneous" and on the other say "python sequences are potentially heterogeneous, and if you have a tuple of heterogeneous data and you iterate on it, that's invariably a code smell". Can you? I mean, unless by "code smell" you mean "thing that's worth a double-look, because although it might be good code, it's easy for it to be evil code". In which case, we're in total agreement.