I thought about that, but I like undefined better. Part of the reason is NaN is of type number[0], and I think a number makes less as a return value for a condi

I thought about that, but I like undefined better. Part of the reason is NaN is of type number[0], and I think a number makes less as a return value for a conditional statement than a general non-value (e.g. undefined or null). Also, if someone asked me to evaluate the equality of karamozov's equations at 0, I'd literally say "that's undefined." So the JS undefined value seemed perfect to me (perfect as in the most elegant, not necessarily the most practical). For some reason I hadn't thought about it till you mentioned it, but I do like the idea of throwing an exception when a nonsensical comparison of NaNs happen. Of course that would be inimical to the way JS normally operates. I don't think what you're getting at is exactly Maybe. You're able to easily programmatically determine whether a Maybe has a value, whereas the equality of NaNs is basically unknowable. 0 - Talking in JS again, although it's similar for Java and other languages.