This page is part of the web mail archives of SRFI 70 from before July 7th, 2015. The new archives for SRFI 70 contain all messages, not just those from before July 7th, 2015.
Aubrey Jaffer <agj@xxxxxxxxxxxx> writes: > | From: Thomas Bushnell BSG <tb@xxxxxxxxxx> > | Date: Thu, 02 Jun 2005 13:05:29 -0700 > | > | Aubrey Jaffer <agj@xxxxxxxxxxxx> writes: > | > | > Yes, I should have written "inexact numbers". > | > | Ok, but when we speak of symbolic "infinite precision" representations > | of sqrt(2), presumably we are using exact numbers. > > No! My point is that inexact numbers correspond to real number > neighborhoods; and hence have finite precision. Ok, that's fine. I agree completely with what you've said about *inexact* numbers. > The text in section 6.2.6 specifies that `number->string' produces an > EXTERNAL REPRESENTATION. Thus the numerical representations produced > by `number->string' have the same notation as numerical constants. > `Read' converts EXTERNAL REPRESENTATIONs, so it also has the same > notation as numerical constants. > > `number->string' and `string->number' are constrained to use the same > representations. > > The relation between the forms `read' and `write'n is not explicitly > stated, but is reasonably assumed to be the same. I agree that the functions must have this relationship. I think that a Scheme implementation may also extend the nature of an external representation if it wishes, provided it keeps numbers separate from identifiers for all programs, in the right way. In other words, an implementation can invent a new syntax, say #s, where #sNNNN is the square root of NNNN, exact iff NNNN is. For a great many of the standard operations of Scheme, this exactness can be easily preserved with a straightforward implementation. NUMBER->STRING must produce this representation, and STRING->NUMBER must be able to handle it, and it should work the same as READ and in program text. Such an extension is fully allowed by R5RS. If you argue that external representations for numbers CANNOT be extended, then you can make no sense of the explicit statements in the standard and the rationale for supporting exact numbers of just this sort. Thomas