Am Fr., 11. Dez. 2020 um 19:11 Uhr schrieb Wolfgang Corcoran-Mathe
<xxxxxx@sigwinch.xyz>:

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

I am referring to the latest draft of the latest version of the
standard, C17: https://files.lhmouse.com/standards/ISO%20C%20N2176.pdf.

In Annex J.1 it says that the following is unspecified: The values of
bytes that correspond to union members other than the one last stored
into. Moreover, in Section 6.2.6 the representation of floating-point
types is left unspecified. Annex F doesn't add something to it.

So, type punning does not trigger undefined behavior but the result is
nevertheless unspecified.

I don't see how you have come to your interpretation so if you believe
I'm wrong, please point out to me where you think the behavior is
specified in the ISO C standard.

Now, on the positive side, by Annex J.3, every conforming
implementation has to specify the number, order, and encoding of bytes
in any object. For example, GCC specifies that this is specified by
the ABI (https://gcc.gnu.org/onlinedocs/gcc/Architecture-implementation.html#Architecture-implementation).
So given GCC and a suitable architecture (e.g. AMD64), one can make
the conversion, at least through memcpy.

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

I have these kinds of claims in mind. The claim that `(nan-payload
(make-nan b c p)) => p)` for example is certainly not true without
limits. I doubt it will work when `p => (expt 10 10000)`. While any
floating-point representation will have some limit, an implementation
that uses nan-boxing may only have a *very* limited set of nan values.
This SRFI doesn't say yet what behavior is to be expected.

Another thing that isn't specified: What does it mean for a nan value
or a payload to be converted to at least the precision of the other
value?

The specification uses the word "mantissa" twice. What does it mean in
a general floating-point context with NaNs?

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

Yes, that would be good. The implementation is necessarily specific to
the compiler. (In the case of GCC, just specific to the architecture).

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

My general problem with SRFI 208 is that it leaves too much
unspecified. It seems I cannot make good use of it in a portable
program unless I know how it is implemented on the Scheme system(s) I
want to target.