[R6RS] The unspecified values, multiple-value semantics and all that

[William D Clinger]

Mike wrote:
> I'm trying to find out what exactly you're referring to.  The main
> "negative reactions" I can see to your post
>
> http://lists.r6rs.org/pipermail/r6rs-discuss/2006-September/000104.html
>
> 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
review:

 *  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
    values.

 *  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
    caller.

 *  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
    Scheme programmers.)

 *  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
clips.

The unspecified value is a paper clip.

Will