Yes, sure, MIT license is fine.

Yes, portable base 16 string->number is complicated, but not Dragon algorithm-complicated: it can be done with only fixnums and flonums. I can't swear, the code is quite old, but I believe that my unparse-binary-flonum procedure does it correctly for reals in all power-of-two bases, not just 16. It is indeed a reals-only code, but extending it to the whole tower should be straightforward enough.

On Monday, May 11, 2026 1:07:38 PM (-04:00), Peter McGoron wrote:

> Hello,
>
> Would you be OK with putting that code under the MIT license so I could integrate it into the sample implementation? Then I can bundle an R7RS version of `write-hexadecimal-float`, which currently only has an R6RS implementation.
>
> _________________________________________
>
> > Not for integration with the reader/printer, but extending string->number and number->string, falling back to the original implementations if radix is not 16?
>
> After working on it a little bit:
>
> Adding a string->number implementation is complicated because the hex float syntax is for each ⟨real 16⟩: for instance, #xxxxxx@1.921fb54442d18p0 must read as (approximately) 0.0+9.0i. Implementing the whole syntax even for just radix 16 is pretty complicated.
>
> Many extensions to number->string will print radix 16 numbers in a way that is not described by the SRFI. `write-hexadecimal-float` can be used to write to a string, but with a stricter output format. One could implement a number->string like (modulo error checking)
>
>     (define (number->string z radix)
>       (if (and (= radix 16) (inexact? z))
>           (call-with-string-output-port
>             (lambda (port) (write-hexadecimal-float z port)))
>           (rnrs:number->string z radix)))
>
> -- Peter McGoron
>