That !0 == 1 is not "well-defined" that I've noticed - perhaps someone could point out precisely where this is stated in a way that is not only definitive, but unambivalent (e.g., I don't want to see docs saying "It works this way, but don't trust it.").

I have found referenced in perlsyn that ! $true_value returns something special. But it says nothing about ! $false_value.

As for perl6, that's not part of the current conversation. As in, if they explicitly document that this is how the not operator works, great, it's explicit. Perl 5 doesn't document it, though, as tye pointed out in Re: One out of three ain't bad (order), perl 5 can't change it now.

Even then, what really is a boolean in numeric context? What is a list, multiplied by "true" times? Or by "false" times? These are conceptually wrong. Just as adding "true + true" to try and get "2" (you don't - you get "true"). You may as well be trying to multiply $string x 'banana' - it makes as much sense.

Except that computer programmers seem to think that 0 == false and 1 == true. Which is a horrible habit to be in (especially when someone gets the brilliant idea to compare if ($var == true)). Let's not expand on that disservice by promoting its further abuse. Instead, let's promote using booleans as booleans, numbers as numbers, and strings as strings. Now, before someone chews my head off ("That's not the perl way! We luvs our automatic type-changes!"), I do think that Larry got it right in Perl6. These automatic changes aren't actually so automatic. They use deep amounts of context to figure it out. And, if we continue with the warnings of perl5 (where things are allowed, but you're probably not doing it right - turn off warnings if you are), some automatic changes will continue to get warnings, even though they work. I hope that booleans in numeric context will be one of them. Unless, of course, you manually set something to say you want a specific boolean (or booleans in general) to have certain values in numeric (or even string) context. For example, setting:

  Bool.context(:numeric(true => 1, false => -1));
  Bool.context(:string(true => Locale.gettext("true"), false => Locale
+.gettext("false"));
[download]

Or something like that (my perl6-fu is weak - that was intended to be something approaching a global setting). After all, what is the stringification of a boolean value? Shouldn't that be language-specific? Perhaps one variable should be "true" and "false" - but another variable should be "enabled" and "disabled". Of course, then another could use "male"/"female" (unless you need to keep track of 'other'), or "cowabunga dude!"/"to infinity and beyond!" or ... whatever you want. Of course, that would be more like $bool_var.context(...) or something

Anyway, my point is that booleans != numbers. Anymore than strings are numbers. Using computers, we just have to store them as numbers, because we don't have anything else to store them with. We have boolean operators, numeric operators, and string operators. Use the right operators for the type of data you're using. If you want numbers, convert from boolean to numeric. Make it explicit. The next guy to take care fo the code will thank you.

---

---

• Are you posting in the right place? Check out Where do I post X? to know for sure.
• Posts may use any of the Perl Monks Approved HTML tags. Currently these include the following:

  <code> <a> <b> <big> <blockquote> <br /> <dd> <dl> <dt> <em> <font> <h1> <h2> <h3> <h4> <h5> <h6> <hr /> <i> <li> <nbsp> <ol> <p> <small> <strike> <strong> <sub> <sup> <table> <td> <th> <tr> <tt> <u> <ul>

• Snippets of code should be wrapped in <code> tags not <pre> tags. In fact, <pre> tags should generally be avoided. If they must be used, extreme care should be taken to ensure that their contents do not have long lines (<70 chars), in order to prevent horizontal scrolling (and possible janitor intervention).
• Want more info? How to link or How to display code and escape characters are good places to start.