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.
My asking was really meant as a question to find out what Henning
meant when he talked about type safety.
I agree with the claim that such features are detrimental in
practice though.
I also feel uncomfortable about such features, but the problem seems
to be different from type safety. Maybe it is more about
predictability. For example, if '1 + 23 = 24' and '1 + "23" = "123"'
this can lead to confusion although using overloading this could be
done in Haskell.
That the compiler is able to figure out a correct instantiation of an
overloaded operation does not mean that it is easy for the programmer
too. And if it is not, programs are hard to understand.
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".
I had in mind "causes a run-time error" as definition of "goes wrong".
But this simple view may well be inaccurate.
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.
I (think I) agree with you. Overloading could give a meaning to almost
everything. Not necessarily a sensible one, and judgements about what
is sensible seem to differ among different people.
Regardless of whether a specific overloading is *sensible*, wanting it
to be *predictable* seems like a reasonable requirement which may be
easier to agree on.
Cheers,
Sebastian
--
Underestimating the novelty of the future is a time-honored tradition.
(D.G.)
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
