4 ms·

> I didn't just fall off the turnip truck Don't get me wrong - I don't know who you are but your username is in my mental bucket of "people worth paying attent

> I didn't just fall off the turnip truck Don't get me wrong - I don't know who you are but your username is in my mental bucket of "people worth paying attention to" just from past comments. I ask because the idea of a three-valued boolean seems rather more "magical" than whatever sins JS already commits by defining comparisons such that (a<=b || b<=a) can be false, and so on. I mean, isn't it a contradiction in terms to begin with, to call such a beast a boolean?

lisper 9y ago
It doesn't matter what you call it. What matters is that you somehow distinguish between situations that are clearly true or false and situations that are not clearly one or the other. The exact mechanism by which you do this doesn't really matter (and what you call it really doesn't matter). What matters is that you don't discard the potentially valuable information that you just tried to do an operation that doesn't make sense. Making null>=0 return TRUE is like making 0/0 return 1.
- ng12 9y ago
  Can you provide an example of when this would be useful? For example: if (foo.bar.length >= baz.buz) { ... } otherwise { // what am I supposed to do here? } How do I disambiguate if the "broken" type coercion was actually what I wanted? How do I tell what circumstances conspired to make this statement not-clearly-true?
  - lisper 9y ago
    You'll have to provide some more details. Why would you want this broken type coercion? What are you actually trying to do here? But in the absence of this information, my first guess would be: if (foo.bar.length >= baz.buz) { ... } otherwise { alert("Something unexpected happened. Either foo.bar.length or baz.buz is not a number.") }
    - ng12 9y ago
      I'm trying to compare two completely arbitrary variables: the point is there's a dozen different ways where that comparison could involve type coercion. The "third boolean" value is useless unless you completely redesign the language.
      - lisper 9y ago
        > I'm trying to compare two completely arbitrary variables But WHY are you trying to compare them? The fact that one of these variables is a field called LENGTH is highly suggestive of some particular semantics that you intend these variables to have. > there's a dozen different ways where that comparison could involve type coercion That's right, which is the reason I can't answer your question as you posed it. I predict that if you try to fill in the details what you will find is that you will be unable to do so in any way that does not reveal the presence of something badly wrong in your design. > The "third boolean" value is useless unless you completely redesign the language. You have to add an OTHERWISE clause to the IF statement and change the semantics of some operators. That's not a "complete redesign."
        nitrogen 9y ago
        It sounds like OTHERWISE is vaguely analogous to a catch on Java's ClassCastException (assuming it would be thrown for any nonsensical comparison). Traditonal if/else maps IF to true and ELSE to false|undefined; OTHERWISE simply extracts the undefined case to a separate clause. Interesting way of expressing the result of an ill-defined operation. Or am I off base?
        lisper 9y ago
        No, you're exactly right. If you think about it, both of these things are (almost) exactly equivalent. In both cases you are separating out a third control branch. The only difference is the syntax you use to specify what happens on that third branch, and whether or not that branch is taken immediately when the non-true-non-false value is generated. It is exactly the difference between (say)dividing by zero throwing an exception or returning an infinity or a NaN.

lisper 9y ago

It doesn't matter what you call it. What matters is that you somehow distinguish between situations that are clearly true or false and situations that are not clearly one or the other. The exact mechanism by which you do this doesn't really matter (and what you call it really doesn't matter). What matters is that you don't discard the potentially valuable information that you just tried to do an operation that doesn't make sense. Making null>=0 return TRUE is like making 0/0 return 1.

ng12 9y ago
Can you provide an example of when this would be useful? For example: if (foo.bar.length >= baz.buz) { ... } otherwise { // what am I supposed to do here? } How do I disambiguate if the "broken" type coercion was actually what I wanted? How do I tell what circumstances conspired to make this statement not-clearly-true?
- lisper 9y ago
  You'll have to provide some more details. Why would you want this broken type coercion? What are you actually trying to do here? But in the absence of this information, my first guess would be: if (foo.bar.length >= baz.buz) { ... } otherwise { alert("Something unexpected happened. Either foo.bar.length or baz.buz is not a number.") }
  - ng12 9y ago
    I'm trying to compare two completely arbitrary variables: the point is there's a dozen different ways where that comparison could involve type coercion. The "third boolean" value is useless unless you completely redesign the language.
    - lisper 9y ago
      > I'm trying to compare two completely arbitrary variables But WHY are you trying to compare them? The fact that one of these variables is a field called LENGTH is highly suggestive of some particular semantics that you intend these variables to have. > there's a dozen different ways where that comparison could involve type coercion That's right, which is the reason I can't answer your question as you posed it. I predict that if you try to fill in the details what you will find is that you will be unable to do so in any way that does not reveal the presence of something badly wrong in your design. > The "third boolean" value is useless unless you completely redesign the language. You have to add an OTHERWISE clause to the IF statement and change the semantics of some operators. That's not a "complete redesign."
      - nitrogen 9y ago
        It sounds like OTHERWISE is vaguely analogous to a catch on Java's ClassCastException (assuming it would be thrown for any nonsensical comparison). Traditonal if/else maps IF to true and ELSE to false|undefined; OTHERWISE simply extracts the undefined case to a separate clause. Interesting way of expressing the result of an ill-defined operation. Or am I off base?
        lisper 9y ago
        No, you're exactly right. If you think about it, both of these things are (almost) exactly equivalent. In both cases you are separating out a third control branch. The only difference is the syntax you use to specify what happens on that third branch, and whether or not that branch is taken immediately when the non-true-non-false value is generated. It is exactly the difference between (say)dividing by zero throwing an exception or returning an infinity or a NaN.