[Haskell-cafe] Bool as type class to serve EDSLs.

[Sebastian Fischer]

>>> 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.)