Re: Comments on SRFI 70

[Aubrey Jaffer <agj@xxxxxxxxxxxx>]

 | Date: Thu, 11 Aug 2005 11:13:28 -0400
 | From: David Van Horn <dvanhorn@xxxxxxxxxxxxxxx>
 | 
 | Below are comments and questions I have on SRFI 70 Numerics with
 | Infinities, following roughly in the order of the SRFI document.

Thanks for your critique.  I have made many improvements to SRFI-70
per your suggestions.

The title is changed from "Numerics with Infinities" to "Numbers" to
reflect its focus on section 6.2 of R5RS.

 | ...  The abstract does not mention that the syntax
 | of numbers is going to be extended.

That is now corrected.

 | If this SRFI extends
 | the syntax of numerical constants, the relevant section 7.1.1 Lexical
 | structure must be revised to reflect these changes.

Good point.  The Specification now begins with:

  In R5RS section "7.1.1 Lexical structure" replace the line:

    <real R> --> <sign> <ureal R>

  with the line:

    <real R> --> <sign> <ureal R> | <sign> I N F . 0

  in order to extend number syntax to include `+inf.0' and `-inf.0'.

 | Rather than the requisite detailed rationale, the section includes
 | an descriptions and discussions on each of the specific changes
 | made in Section 6 of R5RS.  It addresses the What rather the Why of
 | the proposal.  The description material is more appropriately in
 | the specification section, using some typographical convention to
 | offset it from the revised R5RS text.  The discussion material is
 | more appropriately placed in a Discussion section, such as in SRFI
 | 1.

I have not reorganized to that extent, but the abstract now begins:

  This SRFI proposes text to replace section 6.2 "Numbers" of R5RS in
  order to extend its capabilities, correct errors in its specification,
  make it more explicit about limitations of precision and magnitude,
  and improve portability between implementations.

 | ... Indeed, the word portability is not used in the document
 | outside of the opening paragraph of the document.

Most sections of the Rationale now discuss portability.

 |     library procedure: floor->exact x
 |     library procedure: ceiling->exact x
 |     library procedure: truncate->exact x
 |     library procedure: round->exact x
 | 
 |      These procedures are the compositions of `inexact->exact' with
 |     `floor', `ceiling', `truncate', and `round'.
 | 
 | These have portable definitions---they can't extend portability.

These are convenience functions capturing common patterns of use, like
caaaar ... cddddr.

 | Further, these seem to be a poor choice of names.  The name x->y
 | traditionally names a function taking values of type x to type y, such
 | as string->list.  But the convention breaks here; what's a value of
 | type floor?

The names are changed to exact-x.

 | limit seems out of place in relation to the rest of the section in
 | R5RS.

It is removed.

 | The procedures exact->inexact and inexact->exact are implementation
 | dependent.  How does their idempotency lead to portability?
 | What is the rationale for this change?

Writing code to test exactness before calling `inexact->exact' makes
tedium and opportunities for mistakes with no compensating benefits.

 | How does an optional non-real infinity 0/0. lead to portability?

Good point.  I have recast 0/0 as the numeric error-object, completely
unconstrained by SRFI-70.