Thanks for asking. I still would like to make the following points:

(1) The C implementation is not portable even on systems that have
IEEE doubles and a modern CPU. The C code uses type-punning, which is
implementation-defined, so the meaning of the type-punning really
depends on how the compiler interprets it. Of course, it is expected
that the code works for a reasonable compiler but it is far from being
portable. Integrating his code into any Scheme implementation will
automatically produce a dependency on certain implementation-defined
behavior, which may not at all be desirable by the Scheme
implementation. It should be remarked for which systems (CPU, ABI,
compiler) the sample implementation works.

(2) Can we get a full semantics for the procedures in this SRFI 208?
SRFI 208 uses a lot of terms that are not found in section 6.2 of the
R7RS. What are the relationships between the various procedures?

(3) Note that the C language offers a much more conservative interface
to NaN values so any implementation of SRFI 208 cannot be implemented
in portable C.

(4) The last, optional argument to `make-nan` named `float` has to be
what kind of Scheme object? An inexact real? What is the behavior of
`make-nan` if the requested type of float cannot store the payload as
given?

Marc

Am Mi., 9. Dez. 2020 um 21:34 Uhr schrieb Wolfgang Corcoran-Mathe
<xxxxxx@sigwinch.xyz>:
>
> Hi all,
>
> Since the last-call period has been over for a while, and as there
> hasn't been any recent traffic on this list, I'd like to ask if anyone
> has issues with the SRFI which they believe haven't been addressed
> adequately.  Apologies for asking reviewers to "re-raise" their
> points; since so many threads seem to have trailed off into long
> discussions, I'm having a hard time finding issues by thread-combing
> alone.  Please let us know.
>
> Best regards,
>
> --
> Wolfgang Corcoran-Mathe  <xxxxxx@sigwinch.xyz>
>
> "All this currying's just a phase, though it seldom hinders."
> --Fritz Ruehr