Thank you for your reply.

In what follows, I will use "floating-point representation" to refer to
the low-level representation used internally for certain inexact numbers
and "flonum" to mean the subset of inexacts supported by the
flonum-specific parts of SRFI 77.

William D Clinger wrote:
> Referring to John Cowan's interpretation, Alan Watson wrote:
>
>> Yes, that is a possible solution, but does anyone think it is a
>> satisfactory one?
>
>
> I do.  I expect most implementations will designate their preferred
> or default precision of inexact reals as their set of flonums.

I agree that most implementations will continue to use a single
floating-point representation and so will have no problems implementing
SRFI 77.

> SRFI 77 does not insist upon giving privileged status to any
> particular representation of inexact reals, but it does allow
> implementations to bestow privileged status upon a particular
> precision.

If an implementation uses more than one floating point representation,
when implementing SRFI 77, the implementor must choose between defining
flonum to refer to only one representation (and thus prejudicing the
others) or to all representations (and thus being less efficient). Thus,
if you have more than one representation, it is difficult to obtain
efficiency without prejudicing certain representations.

The only motivation for the flonum-specific part of SRFI 77 seems to be
efficiency. Thus, in implementations that have more than one
floating-point representation, one either has to sacrifice efficiency or
priviledge one representation. Thus, the motivation of SRFI 77 would in
this case encourage an implementor to bestow priviledged status on a
particular representation.

> You may not have realized it, but R5RS 6.2.4 had already given
> privileged status to some precision by saying "the exponent marker
> `e' specifies the default precision for the implementation.  The
> default precision has at least as much precision as double, but
> implementations may wish to allow this default to be set by the
> user."

I know, but I do not regard this as an especially important form of
prejudice. When you use "e", you mean "d" or "l" and you don't care
which. (And I think I can guess the historical basis for this.)

>> One solution that would avoid giving priviledged status to one of
>> the flonum representations would be to mandate modules for
>> short[*], single, double, and extended flonums. [...]
>
>
> Yes, but we should first take a look at current practice. A quick
> check of the eight implementations of Scheme that are installed on my
> primary machine shows that all eight implement just one precision of
> inexact real, and three of them are not even R5RS-conformant.
> (Contrary to R5RS 6.2.4, they fail to recognize the `s', `f', `d',
> and `l' exponents and to map those precisions onto the available
> precisions.)

Forgive me if I put words into your mouth, but you seem to be saying
that existing implementations use only one floating-point
representation, therefore it is okay to standardize interfaces that are
well-adapted to such implementations but ill-adapted to implementations
that might use more than one floating-point representation.

This seems to be an argument for eliminating s, f, d, l, and forcing all
future Schemes to use only one floating-point representation.
Furthermore, it also seems to be an argument for forcing all future
Schemes to use only floating-point representations for inexacts.

> There is little to be gained by requiring implementations to provide
> modules for every precision when most systems provide only one
> precision.

Perhaps, but there also seems to be little cost: simply make the short,
single, double, and long floating-point modules aliases for the default
module.

>> One of the arguments for the flonum-specific procedures is
>> efficiency. real->flonum is generic, and undersome circumstances
>> will not be as efficient as as hypothetical
>> double-precision-flonum->single-precision-flonum procedure.
>
>
> Before we mandate some procedure on grounds of efficiency, we should
> measure the efficiency to be gained in some real implementation.

If you are going to promote interfaces on the basis of efficiency (and
there seems to be no other justification for the flonum-specific part of
SRFI 77), you should expect people to use the same arguments against you.

Regards,

Alan
--
Dr Alan Watson
Centro de Radioastronomía y Astrofísica
Universidad Astronómico Nacional de México