The last SRFI 144 issue: flround John Cowan (16 Jul 2017 00:06 UTC)
Re: The last SRFI 144 issue: flround Arthur A. Gleckler (16 Jul 2017 03:41 UTC)
Re: The last SRFI 144 issue: flround William D Clinger (18 Jul 2017 09:48 UTC)
Re: The last SRFI 144 issue: flround John Cowan (18 Jul 2017 15:11 UTC)
Re: The last SRFI 144 issue: flround William D Clinger (18 Jul 2017 17:27 UTC)
Re: The last SRFI 144 issue: flround Marc Nieper-Wi├čkirchen (18 Jul 2017 20:42 UTC)
Re: The last SRFI 144 issue: flround Bradley Lucier (21 Jul 2017 00:07 UTC)
Re: The last SRFI 144 issue: flround John Cowan (21 Jul 2017 01:23 UTC)
Re: The last SRFI 144 issue: flround Arthur A. Gleckler (21 Jul 2017 02:38 UTC)
Re: The last SRFI 144 issue: flround Arthur A. Gleckler (21 Jul 2017 03:37 UTC)

Re: The last SRFI 144 issue: flround William D Clinger 18 Jul 2017 17:27 UTC

John Cowan wrote:

> The notion that a mere difference in marshaling conventions is in any way
> equivalent to the flround discrepancy is absurd.  The C procedures in
> question *do* return two values, using the regular C convention for doing
> so.

That convention is available in Scheme also, by passing a
bytevector of length 8 as the second argument and extracting
the result via bytevector-ieee-double-native-ref or similar.

> You can think what you like, say what you like, and do what you like on
> this point, but your implementation is tested against the behavior of
> libraries that conform to Posix/C99. and therefore amounts to a concession
> that (with the exception of flround), Posix/C99 is the prevailing standard.

If you insist upon this point, I will correct the sample
implementation and Larceny's implementation of SRFI 144 so they
require programmers to pass an 8-element bytevector as second
argument to the

    flinteger-fraction
    flnormalized-fraction-exponent
    flloggamma

procedures and as a third argument to the flremquo procedure.

Will