[r6rs-discuss] string->number

[Thomas Lord]

Also and, sorta "by the way", I don't think
people should be freaked out to discover a mistake
like that or feel an urgent need to fix it.
Mistakes like that sometimes point out deep
things.

An analogy I'm familiar with is the POSIX spec
for regular expressions which, per its language,
has some ambiguity about the associativity of
certain operators.   This went unnoticed for 
many years until some implementers (I was one of them)
were really "raising the bar" on the quality of
implementations.   We were bringing to bear insights
into the practice of implementing regexps that were
not fully apparent to the original authors and the
new algorithms we worked with suddenly laid bare
the ambiguity in the spec.   As we discussed this (us
various implementers, working separately on various
implementations) we eventually concluded that the 
authors intended one reading, but the other reading
made much more sense.   So we wound up with implementations
that want to perfectly conform so as to be commodities and 
implementations that conform only to the letter not the
spirit but arguably have other advantages as a result.
And we wound up all better understanding the design space
and the limitations of the spec no matter how you read it.
We (some of us) came away with the strong suspicion 
that a wholly new spec would be desirable, in light of 
new knowledge.

I don't think it's entirely a coincidence that the mistake
in the spec pointed to the deeper issues we wound up
recognizing.  It was an accident, sure, but not a coincidence.
People tend to make mistakes like these in exactly the
areas that their intended design has problems.

At some point, someone ought to be able to say
"the MD5 checksum of the text of R6 is...."

Now, perhaps R6 is the end of the road for Scheme.
You can do whatever you like in libraries so perhaps
the core needs no further attention other than little
touch-ups to fix typos and eliminate ambiguities.
The problem "design Scheme," in that view, is now
"solved".  Done.  Stick a fork in it.

If that's the case, then I agree -- an errata is
appropriate.  But I still won't recognize that 
language as "Scheme".

-t



On Wed, 2009-03-25 at 10:40 -0400, David Van Horn wrote:
> 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