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.
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
