4 ms·

I'm not sure 0 being falsy is ever a good idea, it's just an assembly-ism that became a C-ism and spread from there. Zero is not a "special enough" value in the

I'm not sure 0 being falsy is ever a good idea, it's just an assembly-ism that became a C-ism and spread from there. Zero is not a "special enough" value in the ring of integers. In general, these days I prefer as few implicit coercions as possible. In many Lisps, nil is the empty list literal, but interestingly not in Clojure, where it just maps to JVM null, and vectors are the most commonly used data type anyway. However, it is idiomatic for APIs to accept (but not return!) nil as if it were an empty sequence or collection, unlike in most non-Lisp languages.

celticmusic 7y ago
0 is the value integral types get default initialized too, it's the equivalent of default initializing a boolean to false.
- Sharlin 7y ago
  But the fact that some types have a reasonable default value doesn’t make the values intrinsically equivalent to Boolean false. Plus, implicit default initialization is itself not necessarily a desirable feature. Especially not the kind that just default initializes to an all-zeroes bit pattern.
  - celticmusic 7y ago
    default initialization is a desirable feature in most circumstances, and I would argue most languages should be opt-out rather than opt-in. There are really only two reasons I can think of for not wanting default initialization. 1. performance 2. to catch mistakes on the edges of your system. A good example of the second is converting incoming data to enumerations. If you're not explicitly checking for it, you can accidentally default initialize to a valid enumeration. This is why I always set the first enumeration to 1 for any language that allows me to. If someone makes that mistake, the missing data causes an error rather than silently doing the wrong thing. But I can't really think of any reason outside of those two cases where you wouldn't want default initialization. And my point was that one of the reasons 0 is chosen as false because it's consistent with respect to default initialization of booleans. I realize that isn't the original reason, but today it's a good reason for having the behavior.
c3534l 7y ago
It's not just an assemblyism, the near equivalence between 0 and false, and 1 and true is the thing that Boole wrote about for which Boolean values are named. I would argue that it's a math thing, not an assembly thing.
- Sharlin 7y ago
  That’s true enough, but in programming languages it’s usually zero=false and any non-zero=true, at least in argument position. That’s more difficult to justify mathematically.
  - uryga 7y ago
    i haven't checked it thoroughly, but it looks like all the desired properties of boolean arithmetic are preserved when false = 0 true = [1] (i.e. the equivalence class of all n > 0) && = + || = * spelling it out: || / + (or): 0+0 = 0 0+[1] = [1]+0 = [1] [1]+[1] = [1] && / * (and): 0*0 = 0 0*[1] = [1]*0 = 0 [1]*[1] = [1] where [1] stands for "any nonzero number". (please let me know if i missed anything!) so natural numbers (quotiented by an equivalence relation) seem to work as a model for boolean arithmetic. and idk if we need more mathematical justification than "it works fine" EDIT: changed "integers" to "natural numbers", because 5 + -5 = 0 so the `[1]+[1] = [1]` property doesn't hold
    - bhaak 7y ago
      `[1]+[1] = [1]` also doesn't hold for natural numbers if you are programming in a language with integer overflow. Neither does the multiplication `[1]*[1] = [1]`
      - uryga 7y ago
        true! i wondered if i should include that but decided to stick with the "mathematical" naturals since we were talking from a math standpoint
    - uryga 7y ago
a1369209993 7y ago
It's a good idea in languages that are both a: statically typed (so a variable that can contain 0 is not also able to contain False) and b: weakly typed (so integers can be implicitly treated as boolean at all). Whether it's a good idea for a language to have both those properties is debatable, but if "if(statically_a_int)" is valid at all, "is zero" is one of the only sensible interpretations ("is negative" being the other, but that doesn't generalize to unsigned types well).

celticmusic 7y ago

0 is the value integral types get default initialized too, it's the equivalent of default initializing a boolean to false.

Sharlin 7y ago
But the fact that some types have a reasonable default value doesn’t make the values intrinsically equivalent to Boolean false. Plus, implicit default initialization is itself not necessarily a desirable feature. Especially not the kind that just default initializes to an all-zeroes bit pattern.
- celticmusic 7y ago
  default initialization is a desirable feature in most circumstances, and I would argue most languages should be opt-out rather than opt-in. There are really only two reasons I can think of for not wanting default initialization. 1. performance 2. to catch mistakes on the edges of your system. A good example of the second is converting incoming data to enumerations. If you're not explicitly checking for it, you can accidentally default initialize to a valid enumeration. This is why I always set the first enumeration to 1 for any language that allows me to. If someone makes that mistake, the missing data causes an error rather than silently doing the wrong thing. But I can't really think of any reason outside of those two cases where you wouldn't want default initialization. And my point was that one of the reasons 0 is chosen as false because it's consistent with respect to default initialization of booleans. I realize that isn't the original reason, but today it's a good reason for having the behavior.

c3534l 7y ago

It's not just an assemblyism, the near equivalence between 0 and false, and 1 and true is the thing that Boole wrote about for which Boolean values are named. I would argue that it's a math thing, not an assembly thing.

Sharlin 7y ago
That’s true enough, but in programming languages it’s usually zero=false and any non-zero=true, at least in argument position. That’s more difficult to justify mathematically.
- uryga 7y ago
  i haven't checked it thoroughly, but it looks like all the desired properties of boolean arithmetic are preserved when false = 0 true = [1] (i.e. the equivalence class of all n > 0) && = + || = * spelling it out: || / + (or): 0+0 = 0 0+[1] = [1]+0 = [1] [1]+[1] = [1] && / * (and): 0*0 = 0 0*[1] = [1]*0 = 0 [1]*[1] = [1] where [1] stands for "any nonzero number". (please let me know if i missed anything!) so natural numbers (quotiented by an equivalence relation) seem to work as a model for boolean arithmetic. and idk if we need more mathematical justification than "it works fine" EDIT: changed "integers" to "natural numbers", because 5 + -5 = 0 so the `[1]+[1] = [1]` property doesn't hold
  - bhaak 7y ago
    `[1]+[1] = [1]` also doesn't hold for natural numbers if you are programming in a language with integer overflow. Neither does the multiplication `[1]*[1] = [1]`
    - uryga 7y ago
      true! i wondered if i should include that but decided to stick with the "mathematical" naturals since we were talking from a math standpoint
  - uryga 7y ago

a1369209993 7y ago

It's a good idea in languages that are both a: statically typed (so a variable that can contain 0 is not also able to contain False) and b: weakly typed (so integers can be implicitly treated as boolean at all). Whether it's a good idea for a language to have both those properties is debatable, but if "if(statically_a_int)" is valid at all, "is zero" is one of the only sensible interpretations ("is negative" being the other, but that doesn't generalize to unsigned types well).