Re: (+ (values 1 2)) should be 1

[Andy Wingo <wingo@pobox.com>]

On Tue 24 May 2011 15:48, Hans Aberg <haberg-1@telia.com> writes:

> On 24 May 2011, at 15:11, Andy Wingo wrote:
>
>>> The Guile manual, sec. 10.2.5.2, says that SCM_UNSPECIFIED is to be used when the Scheme standard says the return is an unspecified value.
>>> 
>>> So this Lisp extension breaks off from that. If one wants it, > perhaps, there should be some way to invoke it.
>> 
>> Hans, you are misreading.  (+ 1) is 1 according to the R5RS.  (+ "foo")
>> is an error.  (+ (values 1 2)) is unspecified, as an instance of
>> returning an unexpected number of values to a continuation, but it is
>> not an instance of the unspecified value.
>
> Andy, I think (values 1 2) should here return SCM_UNSPECIFIED first
> argument to '+', so that people will know that the standard does leave
> the value unspecified.

That is not what the standard says.  It says that the effect of
returning an unexpected number of values is unspecified, not that the
*value* is unspecified -- which wouldn't make sense anyway, as they are
multiple values in the first place.

See the R5RS, the R6RS, and the NEWS please.

    ** Returning multiple values to compiled code will silently truncate the
       values to the expected number

    For example, the interpreter would raise an error evaluating the form,
    `(+ (values 1 2) (values 3 4))', because it would see the operands as
    being two compound "values" objects, to which `+' does not apply.

    The compiler, on the other hand, receives multiple values on the stack,
    not as a compound object. Given that it must check the number of values
    anyway, if too many values are provided for a continuation, it chooses
    to truncate those values, effectively evaluating `(+ 1 3)' instead.

    The idea is that the semantics that the compiler implements is more
    intuitive, and the use of the interpreter will fade out with time.
    This behavior is allowed both by the R5RS and the R6RS.

Andy
-- 
http://wingolog.org/