[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Scheme-reports] Three really picky points

Two of my three picky points got some very good discussion. The third (actually the first one on my list) doesn't seem to have gotten any discussion, so I thought I'd raise it again. 

This refers to number syntax and pragmatics (I don't think there are semantics issues, we all ought to agree what a numeric representation means!). I couldn't find anywhere in the Draft that described the relation between numeric conversion in string->number, read, and in source programs, and was hoping for some kind of clarification (or a pointer to where I missed the clarification). 

The syntactic issues relate to such things as whether S, F, D, and L are valid (`the implementation *may* accept...', p. 32). Pragmatic issues include whether integer or other literals might overflow (on a bignumless implementation), whether or not the implementation applies the same restrictions, described at the bottom of p. 37) to string->number, read, and literals in source programs; the default precision if the E exponent marker is used; and numerical roundoff on input conversion (whether, e.g., (= (string->number? 0.1) 0.1) is defined to be true). 

It's obvious that string->number and read should use the same conversion routine; and I would appreciate a statement in the entry for read that says that the same conversion applies for numbers as in string->number. As for source programs, it might be obvious that any sane compiler will read programs by calling read, but that leaves out the cross-compiler case. Imagine a compiler that outputs assembly language source (or C source) in which floating-point literals are expressed in external form (e.g., PI: .const f'3.1415926'). Then this will be processed by the target assembler (using whatever roundoff, etc it uses), and then used with a runtime that has different characteristics from the cross-compiler, e.g., perhaps the default precision is single rather than double (this isn't crazy, on a game console). 

So I think I'd prefer a statement that says that the relationship between literals in source programs on the one hand and string->number and read on the other is unspecified, but that the latter two use the same conversion rules. If that's already there, please everyone accept my apologies.

-- vincent

Scheme-reports mailing list