Is there any documented information on how the decision to use consistency instead of subclassing was made? Naively it seems very similar to say c# or java with Any instead of Object at the root - except that Any is consistent with all types.
That seems odd and I'm not sure I understand the benefits of it. I get that it only applies to things typed as Any (and presumably like with Object, typing as Any is quite rare to want to do - especially with support for union types) but is there an example where you'd want this and the c#/java subclassing would be limiting?
The "documented information" you want is mentioned in the article. Guido links to a blog post by Jeremy Siek and a paper by Vitousek, Siek and Baker. Read the blog post, section "Why subtyping does not work".
The key is that we're talking about _Gradual_ Typing: it's not that "you never want to type things as Any" (if you always used a dynamically typed language like Python you probably never cared too much), or "subclassing is too limiting" (if anything, imho is not limiting enough).
The point is offering a tool to people who might benefit from some static checks, to avoid stumbling into problems at runtime. Those people have a HUGE codebase with dynamic types (basically, everything is already Any) and you need to _Gradual_ly specify and move over parts of the code to be correctly typed.
as keosak writes, if you want a proper explanation of theory behind it, just read Jsiek's blog posts
It reminds me of TypeScript, where everything defaults to type `any`, so it can interoperate with normal JS. This essentially makes static type checking an "opt-in" feature of the language.
Thanks - this is exactly what I was missing. I was trying to figure out the benefit of allowing it in the language, when of course the answer is supporting existing programs.
(Of course, the "functional languages" bit isn't critical here --- the paper defines gradual typing for a lambda calculus, which is the usual vehicle for explaining type systems.)
Basically, you want to partition the program into parts with and without known types.
If you know the types, they must be equal. If a type is unknown, it is "equal" (consistent) with anything. The conclusion of the paper is that you need a different, symmetric notion of consistency, that is different from subtyping.
Making Any the root of the type hierarchy doesn't work. You explicitly want to allow things like implicitly passing an Any as an argument where, say, an Int is expected, which would be a down-cast. You don't want to allow implicit down-casts all over the place, because that causes the type hierarchy to collapse --- if you allow implicit down casts, you can always up cast to Any, and then immediately down cast to any other type.
That seems odd and I'm not sure I understand the benefits of it. I get that it only applies to things typed as Any (and presumably like with Object, typing as Any is quite rare to want to do - especially with support for union types) but is there an example where you'd want this and the c#/java subclassing would be limiting?