On 2020-12-10 13:35 +0100, Marc Nieper-Wißkirchen wrote:
> (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.

C99 *does* permit type-punning and does specify how objects are to
be converted through type-punning, if I'm interpreting the standard
correctly.  Thus, the sample implementation *should* work across
compilers, although, of course, not across all machines.

> (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?

What terms would you like clarified?  As for the relationships between
procedures, it seems that there are a number of implicit claims, e.g.
that (nan-payload (make-nan b c p)) => p, which could be made explicit,
but maybe that's not what you had in mind?

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

I'd like it if would could reconcile with the fact that a really
portable implementation of SRFI 208 isn't feasible.  This issue came
up early in the discussion on this list, and it was then decided to
press on rather that to "throw the baby out with the bath-water".

Given that we can't have a fully portable sample implementation, what
do you suggest?  A note in the SRFI document's Implementation section,
which currently doesn't mention the portability issues, seems like a
good idea.

> (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?

Good question.  This does need clarification.  It should be an error
if the payload can't be stored, I think.

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

"It was the best of types, it was the worst of types."
--Atsushi Igarashi, et al