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

[William D Clinger]

Comments on Mike's draft statement:

> The 5.91 draft for the R6RS specifies that these procedures return a
> new "unspecified value," a value with a fixed identity.  This
> tightening of the specification with respect to R5RS came from a
> desire to increase portability....
>
> Arguably, this change potentially improves portability, but also
> potentially degrades readability by inviting programmers to rely on
> this specific value.

I'm not sure you want to say that, since the tightening
did not actually increase portability in any meaningful
way.  It would be better just to admit we goofed on this,
without speculation as to what we might have been thinking.

> The design issues associated with the unspecified values are
> interdependent with the semantics of multiple values.

I'm not sure you want to make that claim either.  I agree
with the claim myself, but when I tried to suggest this
connection over on r6rs-discuss, reaction was generally
negative.

> This semantics for multiple return values is not the semantics
> currently implemented by many Scheme systems that require the number
> of return values to always match the number of values explicitly
> accepted by its continuation.  In such a system, any attempt to use
> the return value of an operation returning zero values is an error,
> and usually signalled as such.

I'm not sure you want to say that either, because it makes
us look like we don't know what current implementations
actually do.  A quick check of (let ((x (values 1 2 3))) x)
on a Linux machine gave the following results:

    Bigloo          1
    Chicken         1
    Gambit          1 2 3 (multiple values were returned)
    Kawa            1 2 3 (multiple values were returned)
    Larceny         1 2 3 (multiple values were returned)
    MIT Scheme      #[compiled-closure...] (no error)
    MzScheme        error
    Petite Chez     1 2 3 (multiple values were returned)
    Scheme 48       error
    scm             error

I realize that some of the compilers are simplifying the
expression to (values 1 2 3), but that's allowed by the
R5RS.  The point is that a majority of systems do not
reliably signal an error for this sort of thing.

> Here are some possible directions for these issues to take:
>
> 1. Leave things as they are.
>
> 2. Drop the unspecified value from the report, and specify the
>    operations currently specified to return it to return *an*
>    unspecified value.

That's confusing.  Choice 2 means leaving things as they
are in R5RS.  By choice 1, you actually mean changing things
from what they are in R5RS.

> 3. Specify the operations that currently the unspecified value to
>    return zero return values, and

The word "return" is missing.  In the three choices, the
word "possibly" is a trifle inconsistent with the definitive
wording of the main choices.

In general, I think the length of your proposed message would
give the impression that we are spending altogether much too
much thought on this trivial matter, when there are far more
important things for us to fix.

My personal vote would be to drop the whole thing, leaving
the matter as in R5RS, and turn our attention to the more
important things.

Will