This is what comes from allowing conditionals on undefined values. The result of the relational operators isn't allowed to be "undefined". Nor is it an error to apply "if" to "undefined".
A similar problem comes up at the CPU level with IEEE 754 floating point arithmetic. There's a set of reasonable rules obeyed by FPUs about how results can yield a NaN. NaN values propagate through the math operations; if any operand of +, -, *, / is NaN, the result is NaN. That was well thought out.
But it breaks down at comparisons. Comparisons always return True or False.
All comparisons with NaN return False. There's no such thing as "not a Boolean". Logically, there should be "not a Boolean" in compare condition bits, and attempts to use it to control a branch should cause an exception.
For historical reasons, FPUs were designed as add-ons to the main CPU. They were once separate "coprocessor" chips, back when one chip couldn't contain enough transistors to do both jobs. Early microprocessor FPUs had an arms-length relationship with the main CPU, and the x86 instruction set still reflects this. So the FPU comparison results and the branch logic aren't tightly integrated.
(There's also the fact that few languages can handle a floating-point exception well. You usually can't just put a try/catch around your number crunching and get an exception if the computation starts crunching meaninglessly on NaNs.)
A similar problem comes up at the CPU level with IEEE 754 floating point arithmetic. There's a set of reasonable rules obeyed by FPUs about how results can yield a NaN. NaN values propagate through the math operations; if any operand of +, -, *, / is NaN, the result is NaN. That was well thought out.
But it breaks down at comparisons. Comparisons always return True or False. All comparisons with NaN return False. There's no such thing as "not a Boolean". Logically, there should be "not a Boolean" in compare condition bits, and attempts to use it to control a branch should cause an exception.
For historical reasons, FPUs were designed as add-ons to the main CPU. They were once separate "coprocessor" chips, back when one chip couldn't contain enough transistors to do both jobs. Early microprocessor FPUs had an arms-length relationship with the main CPU, and the x86 instruction set still reflects this. So the FPU comparison results and the branch logic aren't tightly integrated.
(There's also the fact that few languages can handle a floating-point exception well. You usually can't just put a try/catch around your number crunching and get an exception if the computation starts crunching meaninglessly on NaNs.)