On Wed, 8 Jul 2015, Henrik Grubbstr�m (Lysator) @ Pike (-) developers forum wrote:
I believe that the compiler should:
Special case NaN if there's an explicit case-label with NaN.
Map NaN to the default label (if any) otherwise.
We should definitely do the second, the current behavior is just a bug. I am personally not sure about the second, because it would make the switch incompatible with standard equality.
Container types have similar problems with nan. Trivial example:
> ([ Math.nan : 1 ]); (1) Result: ([ /* 1 element */ nan: ** gone ** ])
Of course, this could be fixed, too, by fixing describe_mapping. Similar, but more subtle:
> mapping m = ([ Math.nan : 1 ]); > equal(m, m+([])); (1) Result: 1 > equal(m+([1:2]), m+([1:2])); (2) Result: 0
What about arrays?
> ({ 1, 2, 3, Math.nan }) ^ ({ Math.nan }); (1) Result: ({ /* 3 elements */ 1, 2, 3 }) > ({ 1, 2, 3, Math.nan }) - ({ Math.nan }); (2) Result: ({ /* 4 elements */ 1, 2, 3, nan })
uh??
Of course all this is nothing new. Python afaik tries to treat NaN in containers as if it compared equal to itself. Is that the best one can do?
arne