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