On Tue, 2009-03-24 at 18:08 -0400, John Cowan wrote:
> Thomas Lord scripsit:
>
> > "Note: The string->number procedure always returns
> > a number object or #f;
>
> Even when the computer crashes and burns?
Clearly not, for in such a case the
hardware (I assume you mean literally "burns")
has failed to faithfully execute the
implementation of Scheme which itself was
otherwise doing just fine.
>
> > The specification is flawed either way, of course.
> > It should no more require an exception than it
> > should require a return value of #f.
>
> On that assumption, + should not be required to return
> 4 when applied to (2 2).
>
No, that does not follow.
"2" and "4" are, I think we all agree, reasonably
claimed as the definitive default syntaxes of certain
exact integers. "+" reasonably claimed as any
procedure that (in part) performs ordinary addition on exact
finite integers (possibly with range limitations
but no so limited as to exclude "4").
Those are arbitrary choices, certainly, but they
are very clearly uncontroversial choices. They
don't damage extensibility, except perhaps in the
definition of the reader (CL has the better idea
in that area and there are likely better and more
Scheme-style ideas still).
In contrast, to buy into your conclusion that I
may not extend Unicode with bucky-bits in Scheme,
yet should buy that it's ok because I can do what I
want in a library, I must first accept that
exceptions and libs are the right mechanism for
hooking in my bucky-bit extension. I see no reason
to do so: exceptions are quite a heavy mechanism for
such purposes and there is nothing essential or
common sense about their application in this area.
Perhaps if I write a Scheme with a thoroughly customizable
top-level environment I can support R6 but the thing
I'm so supporting ("R6") is not therefore a good
definition of Scheme. And perhaps I can similarly
support a Scheme in an R6 library - but even then,
R6 must be understood as something other than Scheme.
-t
_______________________________________________
r6rs-discuss mailing list
[email protected]
http://lists.r6rs.org/cgi-bin/mailman/listinfo/r6rs-discuss
