[r6rs-discuss] [Formal] floor, ceiling, truncate, and round are unnecessarily over-specified on infinities and NaNs

From: <bear>
Date: Tue Feb 13 12:11:44 2007

On Thu, 25 Jan 2007, Bradley Lucier wrote:


>Summary: floor, ceiling, truncate, and round are
>unnecessarily over-specified on infinities and NaNs

> On page 44 of the main body of the report, the description of floor,
> ceiling, truncate, and round contains the text

>> Although infinities and NaNs are not integers, these pro-
>> cedures return an infinity when given an infinity as an ar-
>> gument, and a NaN when given a NaN.

> I have argued in the past, and will continue to do so, that the
> generic arithmetic versions of these functions should return only
> integers, and that, in a "safe" environment (I know, I know, the
> existence of such things are no longer mandated) passing an infinity
> or a NaN to these four functions should throw an exception. I
> believe that implementations should be given the freedom to do
> exactly that. If people want the IEEE 754 behavior of these
> functions, they can call the fl* versions of these functions.

Infinities and NaNs are examples of what I call "error-objects";
that is, the result that a function gives you when, for whatever
reason, it can't give you what you ask for. Propagation of error-
objects through expressions to the point where the expression
result is checked is a good way, IMO, to handle error-objects.

Throwing an exception rather than propagating the error object,
gives a lot less control and typically no way to continue the
computation using ordinary control structures. If you propagate
error objects, the next cond clause or the 'else' clause of an
'if' statement can pick up the error and do the computation a
different way. I don't think that exception-throwing is as
simple and reasonable a control structure as 'if' or 'cond,' so
I prefer not to use it (and I especially prefer not *requiring*
people to use it, as exception throws in standard functions do)
when an alternate formulation makes it unnecessary. Therefore
I prefer the error-object propagating behavior described in the
report.

>So I suggest that the current wording should be kept in the
>specification of the fl* versions of these functions, and be removed
>from the main body of the report.

I suggest that the current wording be kept exactly as it is.

                                Bear
Received on Tue Feb 13 2007 - 12:11:37 UTC