multiple values

[Chris Hanson <CPH@AI.AI.MIT.EDU>]

I've finally finished reading all of the mail on this topic, and I'd
like to offer a few comments:

First, I disagree with Alan when he states that not discarding extra
values misses the point of multiple values.  In fact, I think there
are two things that one gets, which JAR indicated with his message.
First, just having multiple values of any kind is useful by itself.
The extra functionality of discarding additional values is an
additional convenience and not in any way "essential" to the concept
of multiple values.  Like JAR, I've been using semantics #1 for some
time and have found it quite useful, even implemented in Scheme as I
have done.

Jinx's argument in favor of semantics #2 contains an additional flaw.
In fact, the particular example he chose highlights it rather clearly:
given an implementation of quotient that returned two values, why is
there any particular reason that the first value should be treated
specially?  In fact, one might be interested in the remainder more
often than the quotient, and the order of arguments then enforces a
built in prejudice about which value is used more often.  Am I then to
assume that, to correct for this bias, `remainder' also returns two
values, but in the opposite order?

Another argument in favor of semantics #1 is that programs written in
that semantics will also run in an implementation with semantics #2.
On possible way to resolve the conflict is to accept semantics #1
immediately with a provision to upgrade to semantics #2 later if
everyone can be convinced that it is reasonable.

However, I'd like to propose something different.  We have already
accepted (I think) that multiple values are optional extensions rather
than required.  Why not accept BOTH semantics?  That gives
implementations more flexibility since they can choose between three
options: no multiple values, or either of the semantics #1 or #2.
People can write programs in any of those forms, with appropriate
restrictions to portability: in my case I might choose to write using
semantics #1, accepting that my programs will not run in systems
without multiple values (or else supplying my own implementation in
those cases).  Others could write using semantics #2 and accept that
their programs would be somewhat less portable.

In any case, because multiple values are optional, I think that
standard procedures (like `quotient') should not return multiple
values.

Lastly, I like the names `values' and `with-values'.  But I must admit
that I wish

    (with-values (lambda () <generate>) <receive>)

would read

    (with-values <generate> <receive>.

However, I understand why this might be undesirable from the
implementor's point of view.