I would certainly hope that a type "checker" returns a more detailed representation of a program than a parse tree - one in which all expressions are typed and ill-typed expressions cannot be represented. So the premise is fundamentally wrong.
Are there non-type ways to improve program safety? Maybe. But since we all understand types and types can cover all the cases we've managed to find so far, I'd stick to types unless and until we can demonstrate a need for something else. Yes, handing out fundamentally unsafe APIs like array-access-by-index is a bad idea - but trying to put types on those APIs is the easiest way to see that they're the wrong abstraction. If you insist that your APIs be type-safe, you'll naturally be guided away from APIs like get-at-index and towards APIs like map / fold / find.
> I would certainly hope that a type "checker" returns a more detailed representation of a program than a parse tree - one in which all expressions are typed and ill-typed expressions cannot be represented.
Do you have an example of this? It is not my experience of compiler intermediate representations or ASTs that they have this property.
> But since we all understand types and types can cover all the cases we've managed to find so far, I'd stick to types unless and until we can demonstrate a need for something else.
This doesn’t really argue with anything I wrote in the article. (Although I’d argue that nobody strictly “sticks to types” as their sole way to enforce correctness).
> trying to put types on those APIs is the easiest way to see that they're the wrong abstraction
I’m not sure I’d say it’s the easiest, but it certainly helps. I love Haskell as a language, primarily because it has a lovely set of well-designed abstractions. It’s clear the design of those abstractions were guided by types and benefit from that. Many of them remain good abstractions when translated to untyped languages.
> Typed intermediate language. GHC has always used a statically typed intermediate language, one of very few production compilers to do so. (Maybe even the only one.) Let's keep that property. Richard's thesis makes it clear that doing so is not straightforward.
So it looks like it's rare to even have a typed intermediate language, let alone one whose structure forces it to be well typed. The latter would require some sort of dependent types.
Are there non-type ways to improve program safety? Maybe. But since we all understand types and types can cover all the cases we've managed to find so far, I'd stick to types unless and until we can demonstrate a need for something else. Yes, handing out fundamentally unsafe APIs like array-access-by-index is a bad idea - but trying to put types on those APIs is the easiest way to see that they're the wrong abstraction. If you insist that your APIs be type-safe, you'll naturally be guided away from APIs like get-at-index and towards APIs like map / fold / find.