fix handling of NaN in Number$prototype$lte to guarantee totality

[davidchambers]

Currently, Z.lte(NaN, 0) and Z.lte(0, NaN) both evaluate false, violating the totality law.

I arbitrarily decided to make NaN the “smallest” Number value.

/cc @CrossEye

[Avaq]

Why do we consider NaN to be a number, but null to be its own special "Null" type?

> typeof NaN
'number'
> typeof null
'object'

> type(NaN)
'Number'
> type(null)
'Null'

[Avaq]

Ah I found the answer:

> Object.prototype.toString.call(NaN)
'[object Number]'
> Object.prototype.toString.call(null)
'[object Null]'

[Avaq]

I'm looking for a reason to exclude NaN from having Number privileges.

[davidchambers]

I'm looking for a reason to exclude NaN from having Number privileges.

I think this library should remain unopinionated, so should support all Number values. Libraries which depend on sanctuary-type-classes are free to be opinionated by excluding problematic values where appropriate. Sanctuary is certainly opinionated (it disallows Number objects, for example).

[Avaq]

We might end up being forced to form an opinion either way, because of Symbol.toStringTag and how we rely on Object.prototype.toString to provide reliably information about built-ins.

[davidchambers]

I'll give people a day or two to comment on this pull request before I merge it.

[CrossEye]

Well, now that it's committed, I finally manage to look at it.

But it certainly seems fine to me. Somehow you need to deal with this case, and the native behavior is incoherent. The decision is arbitrary, but at least it's coherent.