Type errors are whatever your type system defines them to be. It's perfectly reasonable to define a type error as "code that would throw an error if executed".
I think abstract interpretation is more abstract than you are thinking. It essentially means stepping through the code only keeping track of "abstract" properties of the program state. I.e. keeping track of variable types rather than values. This does mean that a function can have a different type based on how it's called, but there's an entire class of "flow sensitive" type systems with that property.
> Type errors are whatever your type system defines them to be. It's perfectly reasonable to define a type error as "code that would throw an error if executed".
Exactly this. One of my frustrations with the erlang vm is that there is not a well-defined meaning to the "anointed" typesystem defined by dialyzer when they should go with "code guaranteed not to throw when executed".
I think abstract interpretation is more abstract than you are thinking. It essentially means stepping through the code only keeping track of "abstract" properties of the program state. I.e. keeping track of variable types rather than values. This does mean that a function can have a different type based on how it's called, but there's an entire class of "flow sensitive" type systems with that property.