nan-payload endianness Lassi Kortela (29 Aug 2020 08:21 UTC)
Re: nan-payload endianness Göran Weinholt (29 Aug 2020 14:35 UTC)
Re: nan-payload endianness Marc Nieper-Wißkirchen (29 Aug 2020 14:58 UTC)
Re: nan-payload endianness Wolfgang Corcoran-Mathe (31 Aug 2020 16:02 UTC)
Re: nan-payload endianness John Cowan (30 Aug 2020 01:00 UTC)
Re: nan-payload endianness Marc Nieper-Wißkirchen (30 Aug 2020 08:41 UTC)
Re: nan-payload endianness John Cowan (30 Aug 2020 14:34 UTC)
Re: nan-payload endianness Marc Nieper-Wißkirchen (30 Aug 2020 15:28 UTC)

Re: nan-payload endianness Marc Nieper-Wißkirchen 30 Aug 2020 15:28 UTC

Am So., 30. Aug. 2020 um 16:34 Uhr schrieb John Cowan <xxxxxx@ccil.org>:
>
>
>
> On Sun, Aug 30, 2020 at 4:41 AM Marc Nieper-Wißkirchen <xxxxxx@nieper-wisskirchen.de> wrote:
>
>>
>> All that's fine if the following implementation is also possible:
>
>
> No such fallback is necessary, because the procedures of this SRFI are only applicable to objects that satisfy `nan?` and, as you point out, `real?`.  I have added a paragraph in the Specification section emphasizing that these procedures are only to be called on objects satisfying those predicates.  (I have also added calls to `assume` to catch complex numbers.)
>
> If the implementation treats only some of the objects whose representation uses the bit-patterns of IEEE NaNs as satisfying `nan?`, so be it: they will satisfy `character?` or `fixnum?` or `eof-object?` or `pair?' or whatever, but not `nan?`.  If the implementation is running on a Vax or an IBM mainframe (as is possible for Schemes that compile to C), then nothing will satisfy `nan?`, in which case the procedures should never be called at all.
>
> Does that satisfy your concerns?

Yes, thanks. What you write makes perfect sense!

Marc