On 2020-10-24 17:04 -0400, John Cowan wrote:
> True.  But it's more than just a non-portable implementation, it's that the
> *results* are non-portable if (say) the implementation maps all quiet NaNs
> that bubble up from C into a single one.  This would be sensible when
> NaN-boxing.  So it is useless.

I don't fully understand why this invalidates SRFI 208 as an interface
to NaN values.  Couldn't we include a note strongly suggesting that
Schemes implementing SRFI 208 provide quiet, signaling, and negative
NaNs?  Isn't this, in a sense, a "quality of implementation" question?

That being said, I agree that there seems to be no way to implement
this portably.  I've determined that the current sample implementation
is completely incorrect.  It relies on the portable (scheme bytevector)
implementation to convert between bytevectors and NaNs.  Unfortunately,
this implementation treats all NaNs as equivalent, and doesn't
actually provide access the bits of a NaN.  We could, however, give a
non-portable implementation for a Scheme with a "real"
bytevector-ieee-double-set!, or something equivalent.

--
Wolfgang Corcoran-Mathe  <xxxxxx@sigwinch.xyz>

"I started out as a BASIC programmer.  Some people would say that I'm
permanently damaged.  Some people are undoubtedly right." --Larry Wall