On Tue, May 17, 2016 at 12:38 PM, Greg Ewing <greg.ewing@canterbury.ac.nz> wrote: [...]
A realisation of algebraic types in Python (or any other language, for that matter) would require carrying information at run time about which kind of box is present. This is in contrast to a union type, which is purely a compile-time concept and has no run-time implications.
The point about tagged unions was that Python *always* has the type information available at runtime. This type information corresponds to the "tag" in "tagged union". For a tagged union at runtime, a language does not need to carry around the information of what kind of box you have, but what kind of beast you have in that box. Unless of course you want a different kind of box type corresponding to each type, which would just be stupid. (Maybe there would be a separate box type for wrapping each of the boxes too ;-) Indeed I, on the other hand, was referring to the ambiguity of compile-time or static-type-checking unions, where the "tag" of a Union can only be known when a non-union/unambiguous type is explicitly passed to something that expects a union. But if the type hints do not "match the tags" [1], then the ambiguity of ("untagged") unions can "spread" in the static type-checking phase, while the runtime types are of course always well-defined. If a language simulates tagged unions by putting things in a box as you describe, and then comes up with a way to automatically release the bird out of a "Box" at runtime when you try to make it .quack(), then they would seem to be reinventing duck typing. - Koos [1] The way TypeVars or @overloads do, or my hypothetical TagMatcher sum example.