Am Mo., 26. Okt. 2020 um 22:08 Uhr schrieb Emmanuel Medernach
<xxxxxx@gmail.com>:
>
>
> Le 26/10/2020 à 21:47, Emmanuel Medernach a écrit :
> >
> > Le 25/10/2020 à 21:53, Marc Nieper-Wißkirchen a écrit :
> >> If you allow me to comment on this:
> >>
> >> Whether a portable implementation is possible or not is one thing (and
> >> doesn't have to be a show stopper), but it is quite another thing if
> >> the specification cannot make any guarantees in order to allow at
> >> least non-portable implementations on most existing and future Schemes
> >> (which, in this case, has to take nanboxing into account).
> >
> > Then  maybe we  could  propose that  'nan-payload'
> > returns some  marker data that  may or may  not be
> > the  51 bits,  letting  implementations to  decide
> > what is the best choice for them.
> >
> > Conversely to be useful in calculations I think we
> > need to  be able to  add a function to  create NaNs
> > with a given marker.
>
> This is  exactly the NaN functions  interface John
> proposed in his FlonumsCowan,  I think this is the
> Right Thing to do.

In John's repo, there is just a link to SRFI 144. Which NaN procedures
do you exactly mean?

Thanks,

Marc