[Scheme-reports] Three really picky points

[Vincent Manis <vmanis@x>]

I went into fussy mode today.

1. string->number, read, and programs

I took a look through the Draft for something that constrains read 
and string->number. Specifically, I can't find anywhere that says that
read uses the same lexical syntax for numbers as string->number does, 
and that programs follow that same lexical syntax. The closest I can 
see is the sentence in the entry for read: `That is, [read] is a parser 
for the nonterminal ⟨datum⟩ (see sections 7.1.2 and 6.4).' My specific 
concerns relate to the implementation restrictions listed on p. 37. 
It is theoretically possible to have read, string->number, and the 
lexical scanner used to read programs all follow slightly different 
implementation restrictions. Admittedly, I can't imagine why any
implementer would do it that way, but I'd still prefer an explicit 
statement. That could be `The lexical syntax for numbers accepted by 
string->number and read, and the corresponding syntax in programs shall 
be the same', or it could be `The relationship between the lexical 
syntax for numbers accepted by string->number and read, and the 
corresponding syntax in programs is unspecified'. 

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.)

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. 

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