Am So., 25. Okt. 2020 um 02:53 Uhr schrieb Wolfgang Corcoran-Mathe
<xxxxxx@sigwinch.xyz>:
>
> 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?

This won't be possible for implementations that use nanboxing and use
all possible bits, I think.

I think this SRFI only makes sense for implementations that don't use
nanboxing at all, in which case it could be fully supported (in the
sense that the behavior of the underlying platform is preserved).