| From: Sebastian Egner <xxxxxx@philips.com>
 | Date: Tue, 14 Jun 2005 09:46:30 +0200
 |
 | Aubrey Jaffer wrote:
 |
 | > Function: limit proc x1 x2 k
 | > Function: limit proc x1 x2
 | >
 | >     ...
 |
 | The specification and implementation of LIMIT has really improved a
 | lot.  Good work!  So LIMIT is now specified as a certain extrapolation
 | algorithm using the points (x, f(x1 + x2/k)), k in {1..d}.
 |
 | Although I still have doubts that this functionality should go into
 | the core of a general purpose programming language (for many programs
 | it might not be relevant and it's also not essential for portability)
 | this operation is certainly a reasonably well-defined numerical
 | algorithm.

In the current version of SRFI-70 I removed the requirement for the
LIMIT procedure; changing it to a "library procedure".  As LIMIT has
developed, it no longer has platform dependencies.  It is most similar
to RATIONALIZE among Scheme procedures; so I moved its description to
follow RATIONALIZE in section 6.2.5.

Choices for its disposition are:

[a] LIMIT is a library procedure
[b] LIMIT is an optional procedure
[c] LIMIT is removed from SRFI-70

Choices for infinity notation are:

[d] 1/0, -1/0, 0/0
[e] 1/0., -1/0., 0/0.
[f] #i1/0, #i-1/0, #i0/0

Choices for (/ 0 0) are:

[g] (/ 0 0) is an error (implementations are not constrained)
[h] (/ 0 0) behavior is unspecified (must not signal error)
[i] (/ 0 0) returns 0/0 or signals an error

Choices for (expt 0 0) are:

[j] (expt 0 0) returns 1
[k] (expt 0 0) is an error (implementations are not constrained)
[l] (expt 0 0) behavior is unspecified (must not signal error)
[m] (expt 0 0) returns 0/0 or signals an error

What do you (all) recommend on these 4 issues?