[Python-ideas] "Sum" Type hinting [was: Type hinting for path-related functions]

[Koos Zevenhoven]

On Tue, May 17, 2016 at 12:38 PM, Greg Ewing
<greg.ewing at 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.