On Tue, 2009-03-24 at 00:49 -0400, David Van Horn wrote:
> 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.
Unfortunately so.
>
> You may think this is a mistaken direction that R6RS goes in compared
> with the much looser specifications of R5RS.
I do.
Indeed, an "R6RS strict" environment could be built
from a lax core that included facilities for
exceptions and libraries. That would simplify
the core and eliminate the controversy. That
is a good direction forward from R6.
> 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 is only a "report". An inconsistency - especially
one that accidentally highlights a design controversy -
seems to me a fine way to leave it.
> 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."
The report generally follows the conventions you
quote, as it says. Yet in this entry for string->number
it explicitly gives more specific language
"scoped" to just that one entry.
The specification is flawed either way, of course.
It should no more require an exception than it
should require a return value of #f.
If the intent of issuing an errata is to give
a chance for editors to clarify which mistake,
exactly, they now say they made then I guess it
is worth the time and effort. I'm not sure what
the value to the larger Scheme society is, though.
Rather:
>
> > 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,
It's a better idea to have a lax core
with plenty unspecified and then create
a library that presents a strict environment.
When one writes code against the lax core,
one is writing code that is ambiguous.
What's wrong with that? Ambiguous code snips
like that rigorously describe some class
of algebraic expressions.
If that same code is moved to the strict
environment - that is one way to eliminate
the ambiguity. But, there is more than one
way to do it. I might want to run the
code so that an exception is raised. Or,
I might want to run the code so that a
first-class "#unspecified" special value is
returned. Or, I might want to run the code
in an environment that supports roman numerals,
as BH suggested.
What *basis set* - what core set of concepts
consolidates and supports all those possible
libraries? A lax core!
R6, as you point out, tries to not be
a lax core. Well, that's a mistake.
The language in R6 presents a case where it
is linguistically ambiguous which kind of
strict core R6 meant. That's a second mistake.
What's left to do? Make it clearer
exactly what mistake was meant? And, what
are the odds that there are many more
such ambiguities in R6? Clear up which
mistake was meant in each case?
It's just a "report". Mistakes are honest.
Leave them be. There are better things to
work on.
> 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.
I think you are saying that it is
possible to create R6 libraries in which
one can implement Scheme.
And that's certainly true. :-)
>
> In other words, I think the answer to your question "Who is to say?" is
> anybody that can write a library.
"It allows you to do whatever you like in libraries"
is a particularly disappointing measure of the quality
of a core language and base 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.
And the core language and base library. If
we keep up this line of reasoning there is
no reason at all to write R7. We're done
at R6: that's the pinnacle. Scheme is
complete.
>
> >> 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."
The report, in that entry (string->number) uses
"must" (by reference) and "never" and "always" (directly).
It's ambiguous in that it says superficially contradictory
things.
In my view, that reflects the process and reasoning
that went into the report. It improves the accuracy
of the report. It's a "report", after all.
>
> >> 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 follow you there. Is that missing
some uses of the word "only"? If so,
then yes - that is sad.
If you look back at the record, you'll see
that during the discussion period I took up
the same issue over different types and butted
heads with Cowan, along with Bear. The course
of that discussion and the outcome were about the
point at which the sorrow really set in.
> I don't see string->number as being
> different in this regard.
I don't claim otherwise.
>
> (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?)
>
Well, I'm sad that pretensions of false rigor
and progress have so muddled the thinking of the
Scheme community - and replaced the rigor we
started with:
Originally - and, I'm sure I can't use the math
vocabulary perfectly here but let me try to convey
the idea -
Scheme set out to build a kind of unified theory
of computation where that theory would have particularly
practical implications both for analysis and implementation.
Types in the definition of Scheme were classes - each
implementation chose constructive sets which were
members of the various classes.
The semantics characterized the classes with respect
to sub-classes such as "unspecified". An implementation
could do whatever the heck it pleased with these and
several implementations did useful things (e.g.,
SCM's explicit "#unspecified" value and other implementations'
various exception mechanisms.)
>From the formal semantic theory one could derive rigorous
meanings for programs which did not produce, for example,
unspecified values at any point or under any interpretation.
The partial denotations - the least fixed-point - is what
defined Scheme: the essential elements we could agree upon.
We could agree upon some essential characteristics of numbers,
of lambdas, of characters and strings, and so forth - and
all of this was neatly collected in the report (almost but not
quite without little mistakes here and there).
This was nicely ***extensible***. Add more number types.
Expand the character set. etc. And you would still have Scheme,
but now, conceptually, maybe you would have "Scheme++".
And an interesting thing about the kind of categorical/denotational
-- about the math I imperfectly understand ----- is that
Scheme programs that represented particularly potent abstractions
were not infrequently useful when run in "Scheme++" situations.
A boring trivial example: someone writes "times-pi"
("(lambda (x) (* pi x))") and that code is perfectly meaningful
and useful in an implementation that has added new numeric
types to fill in some of those "unspecified" parts.
What programming language is a programmer writing in
when they write "(lambda (x) (* pi x))" INTENDING to
be ambiguous about the definition of a number?
We didn't call it "scheme++" - we called it "scheme".
I don't know what R6 is about, exactly. I think it is about
market perceptions and political structures as reflected
on a certain social surface. But it ain't about what I'd
call Scheme.
Let it lie. And let's get back to Scheme.
Now you might counter that the presence of mandatory
exceptions in R6 and of a library system mean that
one can build whatever environment they like.
True, but:
We didn't all agree that disambiguating "unspecified"
and friends as exceptions was a fine model. Some of
us put a lot of energy into expressing detailed
disagreement. As I said: I don't know what the core
language and base library of R6 is, exactly, but I
wouldn't identify it in a line-up as "Scheme".
-t
> David
_______________________________________________
r6rs-discuss mailing list
[email protected]
http://lists.r6rs.org/cgi-bin/mailman/listinfo/r6rs-discuss
