[Haskell-cafe] Bool as type class to serve EDSLs.
sebf at informatik.uni-kiel.de
Mon Jun 1 20:14:08 EDT 2009
>>> Do you argue that overloading logical operations like this in
>>> sacrifices type safety? Could programs "go wrong"  that use such
>> If I understand your point correctly, you are suggesting that such
>> 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
>> 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
> 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.
Underestimating the novelty of the future is a time-honored tradition.
More information about the Haskell-Cafe