perhaps

[ajb at spamcop.net]

G'day all.

John Meacham wrote:

> > does anyone else think this would be useful to provide?

Not me.

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
in usability:

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

Oh, and one more thing: Everything I've said about Bool goes triply for
Either.

Cheers,
Andrew Bromage