[Haskell-cafe] Bool is not...safe?!
jo at durchholz.org
Thu Jul 5 18:48:10 UTC 2018
the criticism is valid but mostly irrelevant.
> There is an opinion that Bool type has problems. It's "dangerous",
> because it's not good to be used as flag for success/fail result.
Actually that's the one good use case.
Also, Boolean-as-a-type means that you do not need a separate language
concept of Condition, Conditions are just those Expressions that happen
to be of type Boolean. And suddenly you can write functions that operate
on Conditions, or define operators for them (if the language allows
operator definitions), etc.
> I read this post:
Well, the first two paragraphs are just overgeneralizations of personal
> and was shocked. How popular is such opinion?
It's a fringe opinion. Most people don't even think about whether
Boolean is an appropriate type.
> 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
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
So you simply use whatever the language offers for making binary
distinctions. In C you use the preprocessor to say PRESENT or ABSENT
instead of true or false (actually 0 or 1); in Java you use an enum, in
Haskell you use a data type.
> 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.
Note that such a loss of context may actually be intentional, if the
goal is to have more abstract code and we don't care anymore whether
that valid=False status relates to files or whether it's a weekday.
Though that's exactly the situation where the blog post's arguments are
irrelevant, too :-)
> *This means that using of False to indicate success - is error!
It can mislead a human reader, so it should be avoided. But I have had
some rare occasions where isFailure: Boolean was the correct declaration
to use (e.g. if isFailure is False by default - actually that's not a
too rare situation now that I think about it).
> no way to miss provenance/knowledge what True or False means.*
Except that if you pass the value to a variable named "isSuccess", you
have a bug.
> (the same: what does Right/False mean?)
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.)
> B) The help from science.
Science is not too relevant here.
The blog post is talking about maintainability, i.e. programmer psychology.
For Booleans, science tells you a lot about what you can do with them,
but it does not tell you what the results of your operations *mean*.
> So, my question is: is this post a april 1st trolling or author was
> serious? :)
The latter, but you missed the point ;-)
BTW the post is pretty rambling, it touches a lot of points but is never
I hope I did better but I'll leave that to better judgement than mine :-)
More information about the Haskell-Cafe