> I think the payload should be constrained to be an exact
> non-negative integer interpreted as a sequence of bits. In IEEE
> formats, the sign bit is part of the payload, and should be
> extractable separately from the payload using nan-negative? or some
> such predicate. In addition, the sense of the signaling/quiet bit is
> implementation-dependent (it is always the highest-order bit of the
> mantissa, but whether 1 is signaling or quiet depends on the
> hardware), and so nan-signaling? should also be added.
IMHO this is restrictive, having payload to be an exact non-negative
integer (or a sequence of bits) precludes using it to store symbols
if one (future) implementation wish to do so.
> In addition, the requirement that read invoke nan seems pointless to
> me. If read returns any old NaN, that should be good enough.
Yes, one implementation may decide to always return the same old
NaN. My point is that (nan) and +nan.0 should have the same behaviour:
if an implementation decides that (nan) returns a new NaN at each
invocation then also should +nan.0. Providing that, I agree to remove the
requirement that the reader have to invoke (nan).
Best,