ajb at spamcop.net
ajb at spamcop.net
Sun Aug 13 23:52:47 EDT 2006
John Meacham wrote:
> > does anyone else think this would be useful to provide?
Quoting Ashley Yakeley <ashley at semantic.org>:
> I think "Maybe Bool" is better for this.
I don't. I also think that 80% of the uses of Bool are wrong.
Any time that you see this:
doSomething :: Bool -> Stuff -> MoreStuff
Not only is it not obvious what Bool means, it's not obvious what
the sense of it should be. In fact, almost every time I see an
argument in a function that I haven't used for a while, I find
myself reaching for the documentation, because I can never remember
what it means.
The only exceptions to this rule that I can think of are functions
of the form:
possiblyDoSomething :: Bool -> Whatever
In that case, it's obvious that the Bool controls the "possibly"
aspect. True means do it, False means don't do it. A good example
of this is showParen.
As for return values, you can almost forgive property tests:
isSilly :: PossiblySillyThing -> Bool
though later, you find yourself also needing:
isNotSilly :: PossiblySillyThing -> Bool
However, there's now a robustness issue. A client of this library
can easily fall into the trap that a PossiblySillyThing has precisely
two states: silly or not silly. That may even be true in version 1.
In Haskell, it takes one line to declare a new enumerated type with
just a few elements. For very little effort, you get a huge payoff
data Silliness = Silly | Sensible
silliness :: PossiblySillyThing -> Silliness
-- Now I don't have to remember what the first argument means or
-- which way around it's supposed to be. It's obvious from the type.
doSomething :: Silliness -> Stuff -> MoreStuff
I'm sorry to go through this in detail, but this stuff is easy to
Oh, and one more thing: Everything I've said about Bool goes triply for
More information about the Libraries