G'day all. John Meacham wrote:
does anyone else think this would be useful to provide?
Not me.
Quoting Ashley Yakeley
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