[Haskell-cafe] Bool is not...safe?!

[PY]

Hello Joachim!

Very nice answer and explanations! So:

05.07.2018 21:48, Joachim Durchholz wrote:
> > Is it true, that bool is "bad" type?
>>
>> As I understand arguments of the post, Bool is bad because: 1) you
>> don't know what does True/False mean  2) after comparison you get bit
>> (!) only but then you may need to  "recover" the comparing value
>> which was "shrink" to bit already.
>
> Sure. That's a valid point the post is making.
> So you shouldn't move the creation of a Boolean too far away from its 
> consumption.
>
> The same argument holds for any numeric data type; if you pass around 
> Floats, you quickly lose knowledge whether it's yards or meters (that 
> kind of problem actually made an interplanetary probe miss its 
> destination planet).

Yes! And I can not imagine Bool which is not bound to some meaningful 
named variable (flag) like "enabled", "isClosed", etc. Bool is always 
flag or a result of predicate.

>> Really, what does True/False mean? How to find semantic of True? It's
>>  very simple, because there is A) contract/interface which interprets
>>  True/False and also B) there is a help from science.
>
> This works as long as the contract is easily deducible from the 
> context in the program.
> I.e. if you have a file-is-open function, then the contract of that 
> function says that the result is True or False, and as long as the 
> value from the function is kept in contexts where it's clear that we 
> are talking about a file-open status, that's good enough.
> Things can get nasty when you start moving a file-is-open Boolean into 
> a "valid" attribute. You (as a human reader) lose the information that 
> the value is related to a file-open status.

Yes, makes sense. What is difficult to me, to imagine true/false itself, 
without predicate or flag. So, it's difficult to me to imagine bool 
which looses its original sense. It's the same as to forget the sense of 
Right or Left. Actually, what does Left mean? Success result? Or 
something else? Totally depends on context, on semantic. You can encode 
good result as "Left Smth" and failure as "Right smth". And only 
implementation of ">>=" will be problem in such inversion. But ML (in 
the original article) has not ">>=", so no way to force you to keep in 
mind success-result == "Right Smth". This was the reason why I made 
accent to monadic operations.

> Personally, I avoid the True/False terminology; it (mis)applies the 
> concept of "desirable" or "truth", and boolean values aren't about 
> desirability or truth.
>
> Just assume the values are "Yes" and "No"; actually this is exactly 
> the issue the blog post is really talking about: "Yes" and "No" are 
> answers, but answers are useful only as long as you know the question.
> (Reminds me of "42" in the Douglas Adams fiction: the supercomputer 
> gave that as the ultimate answer, now they are building a larger 
> supercomputer to find out what the question to that answer is.)
Yes, you are absolutely right here too. So I was talking about 
contract/interface: in Bash the value of "truth" is 0, the value of 
"false" is multiple values. In Haskell: only True and False. But with 
BoolValue and Boolean instances we can map Bash case to Haskell case.

>> B) The help from science.
>
> Science is not too relevant here.
> The blog post is talking about maintainability, i.e. programmer 
> psychology.
Yes, I see now that it's more relevant to psychology :)  When I talked 
about science, I mean that I think not "file-open -> {True|False}"  but 
"openedFile -> {achieved|not achieved}". For me, action is already 
predicate. So when we map functional style to declarative style we must 
treat Bool in this way. In Prolog is don't need to separate predicate 
and its result (Boolean - is some variable) but I'm using predicate 
instead of Bool. May be problem here is that FP is imperative and not 
declarative.