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

PY aquagnu at gmail.com
Thu Jul 5 15:04:50 UTC 2018


So, the problem is that test of emptiness does not force you to 
something right. And possible errors are:

    if empty:
       # do if NOT empty - BUG!
    else:
       # do if EMPTY - BUG TOO!

    or

    # do if NOT empty - BUG!
    if NOT empty:
       # now nothing or old "do if NOT EMPTY"


OK, I understand it. But how is it related to Booleans? :) Sure, if you 
use Maybe or Either you are forced with nature of ">>=": it cuts off 
incorrect branches. With if-then - it does not. But it's not related to 
Bool: Bool is result for predicates. Maybe/Either forces you with magic 
operation ">>=" (which is hidden by do-sugar). Bool does not force you - 
right. But it's problem of Haskell implementation. For example, Prolog 
"forces" you:

Haskell forces you in monad "do":
   do
     someInt <- someMaybe
     -- will not be executed if someMaybe is Nothing

Prolog forces you too but on success/fail (Boolean?):
   someGoal, anotherGoal   % anotherGoal will not be executed if 
someGoal is False

Haskell adds only "bool" function which is close to ">>=" in terms of it 
hides semantic of right bool's processing, avoid those possible errors. 
If you will use "bool" anywhere when you use Bool as result - all will 
be fine, or? Sure, you can move "head" usage out of "bool" but you will 
get empty "bool"s argument. So, IMHO examples of problem with booleans 
is not related to Bool type at whole, but related to problem that Bool 
has kind * but not * -> * to be processed in monadic style (and to has 
needed  ">>=" semantic to force you).

OK, but original article was not about Haskell's monads, but about Bool 
in general :)    Also what I can't understand: if we will think in such 
manner does it mean that "if..test" construct is "boring"/"blindness" 
(excuse my English:) at whole? And all predicates must be removed from 
the language? What will happen to `filter` function without predicates? 
And no way to avoid "if..else" construct and predicates functions.

As for me, this question is related to static-types fanaticism and "How 
many angels could dance on the head of a pin". Example with "head" is 
totally incorrect - it can deconstruct list and no need to predicate 
function. But what I should do with isSpace, isLower, etc? How to use 
predicates at whole? :)   To map   a -> Bool   to   a -> Maybe a  ?
What about function which returns IO Bool? Action which can ends with 
non-critical failure (and need optionally logging, for example) ?


05.07.2018 17:27, Stefan Monnier wrote:
>> 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. I read this post:
>> https://existentialtype.wordpress.com/2011/03/15/boolean-blindness/ and was
>> shocked. How popular is such opinion? Is it true, that bool is "bad" type?
> To me the argument boils down to the `head` case mentioned by Alex.
>
> Most programming languages force you to write code like
>
>      if List.empty l then
>          ...
>      else
>          ... x = List.head l ...
>
> where the problem is that the fact that the List.head call will find the
> list non-empty is not obvious (in the sense that it requires reasoning).
>
> In contrast
>
>      case l
>      | nil => ...
>      | cons x xs => ...
>
> makes it trivially obvious that `x` is extracted from a non-empty list
> without any reasoning needed at all.
>
>
>          Stefan
>
> _______________________________________________
> Haskell-Cafe mailing list
> To (un)subscribe, modify options or view archives go to:
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
> Only members subscribed via the mailman list are allowed to post.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20180705/52d5049d/attachment.html>


More information about the Haskell-Cafe mailing list