Alan Watson wrote:
> 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.

As you have pointed out, the implementors would also have the
option of providing multiple versions of the flonum-specific
library, one for each precision.

> The only motivation for the flonum-specific part of SRFI 77 seems to be
> efficiency.

I see a lot of value in portability, even where you may see
nothing but efficiency.  Portable efficiency is better than
implementation-dependent efficiency.

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

Yes, it is an argument for both of those things.  I still see
value in the multiple exponent markers, mainly because they
are less verbose than the precision marker of SRFI 77 and
follow a convention that is common in other languages, but
I could still sleep at night if they were to disappear.  As
for the other, it wouldn't bother me much if the R7RS were
to mandate floating point.

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

That's true.  On the other hand, a set of libraries that can
be implemented as aliases to an R6RS library sounds like a
simple SRFI.  Those libraries needn't be mandated by the R6RS.

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

Are you suggesting that the efficiency to be gained from
using flonum-specific operations has not been measured in
real implementations?

Will