I think my main issue with SRFI 208 is whether it promotes writing
portable code. The opposite of that would be just naming a few
procedures while leaving the semantics implementation-specific.

I would think it would be better to make the SRFI 208's semantics
stricter, e.g. by enforcing IEEE-754 semantics. Few systems may be
able to implement SRFI 208, but when they do, a programmer can
reliably use the features.

To illustrate what I mean: Not every C99 system has to implement Annex
F, but those who claim to implement it have to implement it fully.

Marc

Am Mo., 28. Dez. 2020 um 20:15 Uhr schrieb Wolfgang Corcoran-Mathe
<xxxxxx@sigwinch.xyz>:
>
> On 2020-12-12 10:55 +0100, Marc Nieper-Wißkirchen wrote:
> > The question about how to make use of SRFI 208 in a safe and portable
> > fashion, however, remains. Couldn't we add some inspection features?
> > For example, to use `make-nan` safely, I need to know what the largest
> > payload may be.
>
> Since the spec of make-nan states that "it is an error if _payload_ is
> larger than a NaN can hold", wouldn't it be sufficient to handle such
> an error if it is signaled?  The other uses for inspection features
> seem obscure to me, and I believe that we're not in favor of adding
> any.
>
> > How is the behavior of `make-nan` when the underlying floating-point
> > implementation allows for payloads but cannot make free use of the
> > sign or quiet bit? Would this mean that such a Scheme system cannot
> > provide a `make-nan`?
>
> This seems like an extreme edge-case, and one which we're not
> interested in specifying.
>
> Again, we obviously don't and can't have a really portable
> implementation of SRFI 208.  How the SRFI is supposed to work on
> strange systems without IEEE-754 support or without access to some
> NaN components is going to be up to the implementers working with
> those systems.
>
> --
> Wolfgang Corcoran-Mathe  <xxxxxx@sigwinch.xyz>
>
> "Simplicity does not precede complexity, but follows it."
> --Alan J. Perlis