Am Sa., 29. Aug. 2020 um 16:35 Uhr schrieb Göran Weinholt <xxxxxx@weinholt.se>:

> > Is this for NaN tagging
>
> I can't answer for the authors' intentions, but I suspect that this SRFI
> conflicts with NaN tagging. In such an implementation both +nan.0 and
> something like a pair could be tagged as a NaN, but no object must
> satisfy both pair? and number?, so some NaN payloads cannot be available
> to the user.

That's a very important point you raise here. An implementation that,
for example, targets the amd64 architecture and wants to handle
inexact real numbers as immediate values (and not on the heap) will
have to resort to NaN-boxing and implementing this SRFI for such an
implementation wouldn't make sense.

For those who have heard about NaN-boxing before and want to read a
bit, here is some input:

[1] http://wingolog.org/archives/2011/05/18/value-representation-in-javascript-implementations
[2] https://anniecherkaev.com/the-secret-life-of-nan