The specification for flexpt is strange:

> procedure: flexpt fl1 fl2
> Returns fl1 raised to the power fl2. For nonzero fl1
>
> fl1 ^ fl2 = e ^ (z2 log z1)
>
> 0 ^ fl is 1 if z = 0, and 0 if fl is positive. Otherwise, the
> result may be a NaN, or may be some meaningless flonum.
I assume the specification really is

    fl1 ^ fl2 = e ^ (fl2 log fl1)

and

    0 ^ fl is 1 if fl = 0 ...

This specification is not closed on flonums, i.e. (flexpt -1.0 0.5)
=> +1.0i .  The specification should restrict fl1 to be non-negative.

I have noticed that the specification of flexpt, flsqrt, flatan and
many other procedures may return a meaningless result for certain
ranges of arguments.  It would be better to say "it is an error", so
that Scheme systems that wish to do so can signal an error in these
cases to improve debugging.  Scheme implementations would still be
allowed to return a meaningless result, if that simplifies
implementation or improves performance.

The same treatment should apply to:

> procedure: flfloor fl
> procedure: flceiling fl
> procedure: fltruncate fl
> procedure: flround fl
> These procedures return integral flonums for flonum arguments that
> are not infinities or NaNs. ...
> Although infinities and NaNs are not integers, these procedures
> return an infinity when given an infinity as an argument, and a NaN
> when given a NaN:
that is, "it is an error" for fl to not be finite.

What is the rationale for flodd? and fleven? .  I don't see a need
for these operations.  In any case, they should also be restricted to
finite arguments (i.e. "it is an error" for the argument to not be a
finite flonum).

These changes would allow a Scheme implementation to treat the flonum-
specific operations as pure specializations of the generic
operations.  That is, if the flonum-specific operations are given
arguments that do not lead to "an error", then the result is the same
as the corresponding generic operation applied to those arguments.
This is a desirable property because a program developed with flonum-
specific operations in a R6RS Scheme system can be ported to an R5RS
Scheme system which supports inexact numbers by simply removing the
"fl" prefixes.  Moreover, the changes I propose would simplify the
porting of "scientific" R5RS programs to an R6RS system.  The
procedure would be:

1) replace the generic operators by their corresponding flonum-
specific operator,
2) run the program on several tests,
3) for any error reported for a flonum-specific operation, find why
invalid arguments where passed to that operation, fix the code, and
return to step 2,
4) when the developer is confident that the code is correct, they can
compile it in unsafe mode to get maximum performance.

Note that a small specification change for fl+ and fl* would be
required because when applied to no arguments they return inexact 0
and 1 respectively, whereas + and * return exact 0 and 1
respectively.  Either the specification for fl+ and fl* in this case
should be changed to return exact 0 and 1, or these operations should
require at least one argument (this would mean that to compute the
flonum sum of a list of flonums, this code would work even if the
list is empty: (apply fl+ 0.0 list-of-flonums)).

Marc