Thank you, Marc, for your comments and for your correction
to the specification of flexpt.  When such corrections are
reported, I have been making the changes and committing them
to the R6RS version control system.

Marc Feeley wrote:
> 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.

Another reason for returning a meaningless result (usually
a NaN) is that this is standard practice in most languages
that use IEEE floating point.  If you identify some of the
fl operations with the corresponding operations of IEEE-754,
then the IEEE standard could be interpreted (in some cases)
as requiring the procedure to return a NaN without raising
an exception.

The problem with saying "it is an error" is that this
phrase has often been misinterpreted to mean that an
error *should* be signalled.  As you may recall, the R6RS
editors once considered the possibility of requiring all
"is an error" situations of the R5RS to signal an error,
which would have been a huge mistake IMO.  I agree that
the fl procedures should be allowed to raise an exception
whenever they are allowed to return a NaN or meaningless
value, but they should not be required to raise an exception
in those cases.

> What is the rationale for flodd? and fleven? . I don't
> see a need for these operations.

One rationale is to simplify construction of generic
arithmetic and the full numeric tower from the fixnum
and fl procedures.  This is not a compelling rationale,
because flodd? and fleven? can be written pretty easily
using the other fl procedures.

A more compelling rationale is that parallelism between
the fl and generic primitives simplifies the porting
process you described.

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

Good point.

> Either the specification for fl+ and fl* in this case
> should be changed to return exact 0 and 1,

That would change the type of these procedures in a way
that interferes with flow analysis, so I would oppose
this change.

> or these operations should require at least one argument

That wouldn't break their closure property, but it would
break the porting process you described: changing (+) to
(fl+) would not be allowed.  In my opinion, using (+) in
an inexact computation is probably a performance bug
anyway.  Changing (fl+) to (+) when porting from R6RS to
R5RS would introduce that performance bug.  In either
direction, the code would probably continue to work.
I think it might be better to allow that performance
bug than to complicate the porting process.

Will