For the benefit of anyone who might still be reading this August 2024
resurrection of the SRFI 77 discussion thread, let me summarize.

Marc Nieper-Wißkirchen has made several claims, and it looks to me
as though two of his claims contradict each other.

On 27 August 2024, in his remarks that resurrected this thread, Marc
made a claim to the effect that (in my words):

    Claim 1.  The R6RS requires the x|p notation to be read as (1) the best
    possible binary floating-point approximation to x that uses p bits of
    significand (which is mathematically well-defined), and then, in systems
    that use binary floating-point representations for inexact reals, (2) that
    best possible p-bit binary floating-point approximation is converted
    to the best possible floating-point approximation that uses p bits "if
    practical, or by the largest available precision if p or more bits of
    significand are not practical within the implementation."

I believe there is general agreement that the "if...practical" loopholes
are there to accommodate the fact that implementations usually
support only a small finite number of floating-point precisions for
inexact reals.  To simplify the following discussion, I will assume the
implementation supports IEEE double precision (53 bits of significand)
as its only representation for inexact reals.

Hence the external notation

    99999999999999983222784|54

would first convert 99999999999999983222784 to the best possible
54-bit floating point approximation to 99999999999999983222784,
which is 99999999999999983222784.0, and would then convert that
number to its best possible approximation using IEEE double precision
arithmetic, which is 99999999999999991611392.0, which most
implementations of Scheme would print as 1.0e23.

For x = 99999999999999983222784, in an implementation that
represents all inexact reals using IEEE double precision floating point,
x|53 and x|54 would be read as the same inexact real.

Marc claimed that, in such an implementation, x|53 and x|54 would
always be read as the same inexact real, regardless of x:

Claim 2.
> ...in the case of inexact numbers, [...] the
> explicitly given mantissa width can be truncated at the maximum number
> of significant bits (which is 53 in the case of IEEE doubles).

But Marc's Claim 2 contradicts my interpretation of his Claim 1.  Consider
the external notation

    99999999999999983222783|54

The best 54-bit fp approximation to 99999999999999983222783 is
99999999999999983222784.0, and (as seen above), the best IEEE
double precision approximation to 99999999999999983222784.0 is
99999999999999991611392.0, which should print as 1.0e23.

Marc's Claim 2 says 99999999999999983222783|54 should be read as
the same inexact real as 99999999999999983222783|53.  But the best
IEEE double precision approximation to 99999999999999983222783 is
99999999999999974834176.0, which most implementations of Scheme
would print as 9.999999999999997e22.

When representing inexact reals using IEEE double precision (53 bits),
9.999999999999997e22 is not the same inexact real as 1.0e23.

Marc must therefore retract one of his two claims (or explain how I have
been misinterpreting his claims).  What I say next will depend upon which
claim Marc decides to retract.

(Spoiler alert:  The numerical examples above illustrate the "double rounding"
problem, which is the main reason converting decimal scientific notation to
binary floating-point is non-trivial.  Marc's Claim 1, as I interpret it, creates a
double rounding problem.)

Will Clinger