Do you argue that overloading logical operations like this in Haskell sacrifices type safety? Could programs "go wrong" [1] that use such abstractions?
If I understand your point correctly, you are suggesting that such programs are still type safe. I agree with the claim that such features are detrimental in practice though. Instead of lumping it with type safety, then what do we call it? I think I've heard of languages that do such conversions as "weakly" typed. Really the issue is with implicit conversions, right?
Isn't it merely a matter of balance? In order for typed programs not to go "wrong", one has to define "right" and "wrong", and devise a type system that rules out anything that might go "wrong", usually at the expense of some programs that might go "right". Advanced type system features like overloading take that unused space and devise ways to redirect code that would go "wrong" (in simpler systems) to go "right" in useful new ways (eg: adding two functions or matrices or .. does not have to be "wrong", there are interpretations in which all of these make perfect sense, and Haskell can express many of them). What is happening then is that more and more of the previously "wrong" space is filled up with meaningful ways of going "right", until nearly every syntactically valid program goes somewhere. That can make for an extremely expressive and powerful language, but it renders the naive notion of going "wrong" or "right" rather meaningless: "wrong" just means we haven't figured out a meaningful way to interpret it, and going "right" can easily be a far cry from where you wanted it to go. Claus PS. this problem can be made worse if the implicit conversions aren't consistent, if small "twitches" in source code can lead to grossly different behaviour. There is a fine line between advanced and uncontrollable, and opinions on what side of the line any given definition is on can differ.