Thomas Lord wrote:
> On Tue, 2009-03-24 at 00:49 -0400, David Van Horn wrote:
>> it should only be applicable to
>> a string or to a string and an exact integer in {2, 8, 10, 16}. This
>> follows from section 6.2 "Procedure entries" and the particular text in
>> the string->number entry.
>
>> "the report follows the convention that if a parameter name is also the
>> name of a type, then the corresponding argument must be of the named type."
>
>> "the argument specifications are exhaustive: if the number of arguments
>> provided in a procedure call does not match any number of arguments
>> accepted by the procedure, an exception with condition type &assertion
>> must be raised."
>
>> "Descriptions of procedures may express other restrictions on the
>> arguments of a procedure. Typically, such a restriction is formulated as
>> a phrase of the form "x must be a ..." (or otherwise using the word
>> "must")."
>>
>> "(string->number string) procedure"
>> "(string->number string radix) procedure"
>>
>> "Radix must be an exact integer object, either 2, 8, 10, or 16."
>>
>> If we interpret the report as allowing string->number to be applied to
>> arguments other than a string or a string and a radix, then "must" is
>> meaningless and the report pretty much collapses.
>
>
> Nonsense. Why are you not equally a defender
> of the words "never" and "always":
>
> "Note: The string->number procedure always returns
> a number object or #f; it never raises an exception."
As made clear by the context of this note, the cited discussion
of the editors, and the recent comments on this list by the editors,
that note is applicable only when the string->number procedure may
be applied to its arguments.
It is a simple typo -- a quantifier has been omitted. An erratum is
deserved. I hope the editors fix the problem and move on.
David
_______________________________________________
r6rs-discuss mailing list
[email protected]
http://lists.r6rs.org/cgi-bin/mailman/listinfo/r6rs-discuss
