On Wed, Jan 11, 2012 at 12:28 PM, Vincent Manis <vmanis@telus.net> wrote:
>
> 2. Exact results for rational operations
>
> Sec 6.2.2 states `Rational operations such as + should always produce
> exact results when given exact arguments. If the operation is unable
> to produce an exact result, then it may either report the violation
> of an implementation restriction or it may silently coerce its result
> to an inexact value. See section 6.2.3.'
>
> This contains an apparent (but not real) contradiction. Perhaps
> altering the first sentence to `Rational operations such as + should
> always ATTEMPT TO produce exact results when given exact arguments.'
> might make it clearer. (I assume that + is relevant here in the case
> where an integer result is too large to be represented in a fixnum,
> but would fit into a flonum, this on an implementation without bignums.)

I think the formal meaning of "should" used in the draft already
implies "attempt to".

> 3. Exactitude on legacy names
>
> The Notes states `The R5RS names inexact->exact for exact and
> exact->inexact for inexact were retained, with a note indicating
> that their names are historical.' I can find no reference to the
> name etymology in the entry for these two procedures on p. 36.

I removed this because we don't, in general, discuss the
historical reasons for names so it seemed out of place.
The notes were not updated, but will be before the final
draft (unless someone proposes we uniformly explain all
non-obvious names).

--
Alex

_______________________________________________
Scheme-reports mailing list
Scheme-reports@scheme-reports.org
http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports