Lassi Kortela <xxxxxx@lassi.io> writes:

> "(nan-payload nan) -- Returns the remaining 51 bits of nan as an
> positive exact integer."

Should it actually say 51 bits, since that seems to imply binary64 is
required?

It also uses "nan" in the prototype without properly defining what kind
of object it is. I assume it has to satisfy number? at least.

The reference implementation uses nan?, but there's a funny
complication: nan? in R7RS is also #t for complex numbers if one part is
NaN. The check should be stricter.

> 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.

>, and can you use those bits without knowing
> the float byte order? I presume if you store and retrieve the payload
> in the same OS process the byte order stays constant so you don't need
> to care about it.

There are old machines with mixed endianness for doubles (one endianness
for storing the four bytes in each 32-bit word, and the opposite
endianness for those two words). But it's just a curiosity.

> But the SRFI doesn't have a procedure to store a
> payload.

Indeed, where are the NaNs expected to come from?

> The sample implementation uses `(bytevector-ieee-double-set! bvec 0 n
> (endianness big))` from R6RS.
>
> Does toggling the byte order on bi-endian architectures affect the
> float byte order as well, or does the FPU have its own byte order?

This doesn't matter because this is Scheme and not C. :) Whatever is
required for the bytevector-ieee-double-set! procedure to do the right
thing is handled by that procedure.

And it is also just a reference implementation. If some implementation
can't use bytevector-ieee-double-set! then it's free to do the right
thing to implement the API in the SRFI.

--
Göran Weinholt   | https://weinholt.se/
Debian Developer | 73 de SA6CJK