feedback Jim Rees (04 May 2026 17:40 UTC)
Re: feedback Peter McGoron (05 May 2026 21:49 UTC)
(missing)
Re: SRFI 270 Peter McGoron (11 May 2026 17:08 UTC)
Re: SRFI 270 Sergei Egorov (11 May 2026 17:26 UTC)
Re: feedback John Cowan (05 May 2026 22:23 UTC)

Re: feedback Peter McGoron 05 May 2026 21:48 UTC

Thank you for the feedback.

 > To avoid any confusion, all the values on the rhs should have a
decimal point, so nobody accidentally interprets the lack of one as an
exact value.

The RHS is meant to be the mathematical numbers that the numbers on the
left read as, because the approximation comes later.

 > Should this be 9.0+32.0i ?

Yes, will fix.

 > * write-hexadecimal-float: it does not say whether the "#x" prefix is
written.  Should it be consistent with number->string which does not
emit the radix?

Yes, I will make that explicit.

 > * Also write-hexadecimal-float: your canonical form for binary IEE754
values is ambiguous for the sub-normal case.

I will reword it to remove references to "canonical." I was intending
the first output you listed (shortest fractional component), but since
that's not universal I don't think the SRFI should require it.

 > * You do not address the output of non-finite values in
write-hexadecimal-float.   Presumably, you mean to output "+inf.0",
"-inf.0", "+nan.0".

I will specify that in the next revision. (The description also fails to
cover `+0.0` and `-0.0`.)

 > * In the non-R6RS case, R7RS permits optional s,f,d,l precision
indicators.   This standard should also permit such characters after the
p.   Fortunately, this does not create a conflict with parsing of the
exponent which is always in decimal.

I will specify that as an allowable extension.

-- Peter McGoron