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@scheme-reports.org
http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports