5 ms·

In my opinion if a language has False/None/Null/Nil as first class values, then the only sane path is for everything else to be True: the number zero, NaN, empt

In my opinion if a language has False/None/Null/Nil as first class values, then the only sane path is for everything else to be True: the number zero, NaN, empty string, empty list, empty set, etc. All of those should evaluate to True.

zasdffaa 4y ago
Yeah... ISWYM and it sounds good, then again it confuses the boolean concept with the list concept, the set concept etc. etc. etc. Doesn't mean it isn't useful, and maybe there's very little risk of mistakes but still.
- mikepurvis 4y ago
  If every list or set or dict evaluates to true, even empty ones, what is there to confuse? Or is the argument that non-bool types shouldn't coerce to a bool at all, so that you're force to always explicitly call a bool-returning method, like "if my_list.empty() then" type of thing? In any case, the next thread down is making the same point, and specifically calling out languages that do exactly this and get it right: Clojure, Lua, Ruby, and others.
  - zasdffaa 4y ago
    It's a theoretical challenge to your idea, that's all. In fact IIRC from the distant past that lambda calculus is where this behaviour comes from so it is in fact theoretically well-founded. I withdraw my doubts.
anamax 4y ago
> if a language has False/None/Null/Nil as first class values, then the only sane path is for everything else to be True I very much disagree. Every type should have a false value. Note that False is a bool while None/Null are pointers/references and Nil is Lisp's empty list. (Python's empty list is [] and it also has empty tuples.) Why should those types and no others have a false?
- sph 4y ago
  Not necessarily every type, but just those that obviously look false: False, 0, null. Empty string iff it's a very high level language. Empty list iff it's a lisp. But better yet, `if` should only accept a boolean expression. Passing a string to `if` should be a type error.
  - Espressosaurus 4y ago
    0 shouldn't be false. 0 compared to something can be false. Null isn't false. Null compared to something can be false. The entire concept of "falsey" makes my teeth ache. Non-boolean expressions in a boolean context is asking for a runtime error.
    - anamax 4y ago
      > Non-boolean expressions in a boolean context is asking for a runtime error. And yet, it doesn't, in strongly-typed languages that define which values are "false" and "true" for types such as strings, sets, dictionaries, and yes, even numbers.
  - anamax 4y ago
    It's unclear why empty strings or lists should be considered false yet it's somehow evil for empty sets to be considered false. The purpose of type checking is to help people write correct programs. It's unclear that requiring "if {string}.isempty() ..." does that better than "if {string} ..." in a strongly-typed language.
- joe-collins 4y ago
  The notion that any non-boolean type has a "false value" is strange to me. There's some convenience in it, certainly, but I don't see it making sense on a more basic level.
  - imtringued 4y ago
    One could define a BooleanConvertible interface with a toBoolean() method.
Someone 4y ago
That opinion rules out many strongly typed languages where booleans are strictly separate from other types, just as, in such languages, floats are separate from doubles, and any assignment of a value of type T1 to a variable of type T2, or passing a variable of type T3 to a function taking an argument of type T4 requires explicit conversion, even if that conversion could be lossless. For example, in Swift let f: Float = 1.0 let d: Double = f is invalid code. You have to write let f: Float = 1.0 let d: Double = Double(f) In such languages, true is true, false is false, and all other values are neither true nor false. I think that, certainly for booleans, that’s the sanest choice.
mlazos 4y ago
I tend to think the only sane path is a type error and anything else is arbitrary. It isn’t that hard to have converters which make sense in a standard library. isNone, isNil ..

zasdffaa 4y ago

Yeah... ISWYM and it sounds good, then again it confuses the boolean concept with the list concept, the set concept etc. etc. etc. Doesn't mean it isn't useful, and maybe there's very little risk of mistakes but still.

mikepurvis 4y ago
If every list or set or dict evaluates to true, even empty ones, what is there to confuse? Or is the argument that non-bool types shouldn't coerce to a bool at all, so that you're force to always explicitly call a bool-returning method, like "if my_list.empty() then" type of thing? In any case, the next thread down is making the same point, and specifically calling out languages that do exactly this and get it right: Clojure, Lua, Ruby, and others.
- zasdffaa 4y ago
  It's a theoretical challenge to your idea, that's all. In fact IIRC from the distant past that lambda calculus is where this behaviour comes from so it is in fact theoretically well-founded. I withdraw my doubts.

anamax 4y ago

> if a language has False/None/Null/Nil as first class values, then the only sane path is for everything else to be True I very much disagree. Every type should have a false value. Note that False is a bool while None/Null are pointers/references and Nil is Lisp's empty list. (Python's empty list is [] and it also has empty tuples.) Why should those types and no others have a false?

sph 4y ago
Not necessarily every type, but just those that obviously look false: False, 0, null. Empty string iff it's a very high level language. Empty list iff it's a lisp. But better yet, `if` should only accept a boolean expression. Passing a string to `if` should be a type error.
- Espressosaurus 4y ago
  0 shouldn't be false. 0 compared to something can be false. Null isn't false. Null compared to something can be false. The entire concept of "falsey" makes my teeth ache. Non-boolean expressions in a boolean context is asking for a runtime error.
  - anamax 4y ago
    > Non-boolean expressions in a boolean context is asking for a runtime error. And yet, it doesn't, in strongly-typed languages that define which values are "false" and "true" for types such as strings, sets, dictionaries, and yes, even numbers.
- anamax 4y ago
  It's unclear why empty strings or lists should be considered false yet it's somehow evil for empty sets to be considered false. The purpose of type checking is to help people write correct programs. It's unclear that requiring "if {string}.isempty() ..." does that better than "if {string} ..." in a strongly-typed language.
joe-collins 4y ago
The notion that any non-boolean type has a "false value" is strange to me. There's some convenience in it, certainly, but I don't see it making sense on a more basic level.
- imtringued 4y ago
  One could define a BooleanConvertible interface with a toBoolean() method.

Someone 4y ago

That opinion rules out many strongly typed languages where booleans are strictly separate from other types, just as, in such languages, floats are separate from doubles, and any assignment of a value of type T1 to a variable of type T2, or passing a variable of type T3 to a function taking an argument of type T4 requires explicit conversion, even if that conversion could be lossless. For example, in Swift let f: Float = 1.0 let d: Double = f is invalid code. You have to write let f: Float = 1.0 let d: Double = Double(f) In such languages, true is true, false is false, and all other values are neither true nor false. I think that, certainly for booleans, that’s the sanest choice.

mlazos 4y ago

I tend to think the only sane path is a type error and anything else is arbitrary. It isn’t that hard to have converters which make sense in a standard library. isNone, isNil ..