On 2/23/07, Jonathan Lang <[EMAIL PROTECTED]> wrote: '> I'm still debating the boolean context myself. I _think_ it will
work; but I have a tendency to miss intricacies. You might instead want to require someone to explicitly check for definedness or existence instead of merely truth; or you might not.
I should chime in something here. It may not be practical for Perl, given how much we have already relied on its opposite, but it is still worth considering: I have been extremely satisfied with Ruby's boolean truth model: nil and false are false, everything else is true. So the empty string is true, 0 is true, "0" is certainly true. I think it's the same reason that I like Haskell's function call model: that is, function application binds most tightly, everything else has various looser precedence. I think the nice thing about these two is their extreme simplicity. In Haskell, when I read: foo x ! bar I don't need to think for a fraction of a second to associate that correctly in my mind. Likewise, in Ruby, when I write: while line = gets I don't need to think for a fraction of a second about edge cases of gets. Gets returns a string when it reads something, and nil on EOF, that's all I need to know. And the simplicity has a way of propagating to other areas of the language, as in that example, where gets is able to return the most obvious thing for EOF and have it work correctly. So, yeah, simple rules can be a blessing if you find the right ones. In particular, since I use boolean context a lot (i.e. without explicit compare operators), I'm a fan of as much boolean predictability as I can get. Even if we don't get the same simple model of booleans as ruby, I'd like to keep the number of boolean-context overloaded objects reasonably small. This gives functions the freedom to return false or undef as a failure mode, when it is convenient for it to function that way. Luke
