[R6RS] The unspecified values,
multiple-value semantics and all that
William D Clinger
will at ccs.neu.edu
Mon Nov 6 20:29:53 EST 2006
> I'm trying to find out what exactly you're referring to. The main
> "negative reactions" I can see to your post
> all seem to say that they're bewildered by a semantics that coerce
> zero return values to the/an unspecified value. That may be because
> they genuinely prefer a semantics that forbids this, or because the
> semantic option you prefer hasn't been adequately or prominently
> explained. Maybe it should?
Maybe, but it seems to me that we've been over this before:
not just the editors, but the entire Scheme community. To
* Returning zero values when there is no useful value to
return sounds like a good idea, but it isn't safe unless
you know for sure that the continuation will accept zero
* In R5RS Scheme, you very seldom know that.
* Returning values to a continuation is similar in theory
to passing values to a procedure, but not in practice:
You never call a procedure unless you know its contract,
but you seldom know much about the continuation. With
proper tail recursion, the procedure that created the
continuation can be arbitrarily far removed from your
* Proper tail recursion works well in practice because of
the implicit assumption (dating back to the era before
multiple return values) that continuations always accept
one result. (That implicit assumption is the reason
multiple return values are used so rarely in Scheme, in
such limited circumstances, and are lamented by so many
* Making the implicit one-result assumption explicit would
increase the complexity of specifications.
* Library procedures can't ever be sure their continuation
will accept zero values. That assumption could be added
to their contract, but that would be an incompatible
change to the contracts of procedures that currently
return a single unspecified result.
* Requiring all continuations not created by call-with-values
to accept zero values would solve the problem, but at least
two of the editors have indicated strong opposition to this.
If we can't even convince the editors, what chance have we
of convincing the community at large?
* Do you really want to try to explain all this over in
the R6RS discussion group? It would invite a public
dispute in that group between the editors themselves.
(Not that I have a problem with that, but I'd prefer
to argue about more important things.)
> It seems important enough to enough people to have generated one of
> the longest threads on the list. At least the issues need to be
> explained at some point in the rationale document.
We shouldn't judge the importance of a topic by the length
of its thread. As Ralph London used to say, an important
technical issue will often generate very little discussion
because so few people feel qualified to comment upon it.
When it comes time to order paper clips, however, everyone
will get involved in the argument over which kind to order,
because everyone is qualified to have an opinion about paper
The unspecified value is a paper clip.
More information about the R6RS