Thomas Lord wrote:
> On Mon, 2009-03-23 at 19:34 -0400, David Van Horn wrote:
>> Thomas Lord wrote:
>
>>> "Unspecified" seems like the accurate spec.
>> (string->number string) procedure
>> (string->number string radix) procedure
>>
>> It is clear that the intention was that string->number could only be
>> applied either to a string or to string and an exact integer that is
>> either 2, 8, 10, or 16---both from the text of the report and from the
>> recent emails by the editors.
>
> It is not hard to imagine generalizations.
> One can easily imagine (quite serious, not
> fake example) extensions to "string->number"
> to support additional types and numbers of
> arguments.
Sure, I agree it is easy to imagine generalizations, but the report as a
whole is quite clear that these kinds of generalizations are not valid
implementations of the rnrs procedures.
You may think this is a mistaken direction that R6RS goes in compared
with the much looser specifications of R5RS. But regardless of whether
it is the right or wrong direction, if string->number is to be
consistent with the rest of the report, 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.
> It is hard to imagine a set of generalizations
> that everyone would agree every implementation
> ought to have.
Agreed.
> So, how to handle these "edge cases"?
>
> An exception? Return #f? Something else (say,
> perhaps, making the function a generic in the CL
> sense)?
>
> Who is to say?
An R6RS library could provide a generalized string->number procedure
that accepts more or different types of arguments, so there is no
restriction on exploring this design space beyond the fact that such a
generalized procedure must be different from the one provided by the
(rnrs base (6)) library.
In other words, I think the answer to your question "Who is to say?" is
anybody that can write a library. Before there was a library system, it
may have been more compelling to have unspecified behavior allowing for
such extensions. But with a library system in place, it is easy to
ignore the standard libraries if they are not to your liking.
>> If this is unspecified, the word "must" would mean very little in the
>> report.
>
> Wouldn't it mean something like "must if the
> behavior of the program is expected to be defined
> by this report"?
Yes, this is very close to how the report defines the word:
"This word means that a statement is an absolute requirement of the
specification."
>> An erratum clarifying the note seems appropriate.
>
> Only in a very sad way, to me.
I think you must (sorry) already be sad about the fact that + must be
applied to complex number arguments and that string-append must be
applied to string arguments. I don't see string->number as being
different in this regard.
(But like I've said, this doesn't stop you from writing a library that
provides +, string-append, and string->number, extended however you see
fit; so how sad can you really be?)
David
_______________________________________________
r6rs-discuss mailing list
[email protected]
http://lists.r6rs.org/cgi-bin/mailman/listinfo/r6rs-discuss
