(+ (values 1 2)) should be 1

(+ (values 1 2)) should be 1

[Andy Wingo]

But, it is 1 and 2, currently.  (+ FOO) inlines just to FOO, too
optimistically.

Andy
-- 
http://wingolog.org/

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

[Hans Aberg]

On 22 May 2011, at 16:02, Andy Wingo wrote:

> But, it is 1 and 2, currently.  (+ FOO) inlines just to FOO, too
> optimistically.

It is unspecified according to rsr5.

Hans

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

[Andy Wingo]

On Mon 23 May 2011 15:34, Hans Aberg <haberg-1@telia.com> writes:

> On 22 May 2011, at 16:02, Andy Wingo wrote:
>
>> But, it is 1 and 2, currently.  (+ FOO) inlines just to FOO, too
>> optimistically.
>
> It is unspecified according to rsr5.

I know.  I'm talking about Guile here.

Andy
-- 
http://wingolog.org/

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

[Hans Aberg]

On 23 May 2011, at 15:49, Andy Wingo wrote:

>>> But, it is 1 and 2, currently.  (+ FOO) inlines just to FOO, too
>>> optimistically.
>> 
>> It is unspecified according to rsr5.
> 
> I know.  I'm talking about Guile here.

I know. You perhaps haven't described clearly enough what it should be. If using a tuples description, you want them to be truncated to the first component whenever possible and not using call-by-values explicitly, right?

Hans

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

[Hans Aberg]

On 23 May 2011, at 15:49, Andy Wingo wrote:

>>> But, it is 1 and 2, currently.  (+ FOO) inlines just to FOO, too
>>> optimistically.
>> 
>> It is unspecified according to rsr5.
> 
> I know.  I'm talking about Guile here.

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

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

[Andy Wingo]

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

> On 23 May 2011, at 15:49, Andy Wingo wrote:
>
>>>> But, it is 1 and 2, currently.  (+ FOO) inlines just to FOO, too
>>>> optimistically.
>>> 
>>> It is unspecified according to rsr5.
>> 
>> I know.  I'm talking about Guile here.
>
> 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.

When a continuation that expects one value receives more values than it
is expecting -- e.g., the <> in (+ <>) expects one value -- Guile
truncates those values to the first one.  If such a continuation
receives 0 values, Guile signals an error.

Andy
-- 
http://wingolog.org/

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

[Hans Aberg]

On 24 May 2011, at 15:11, Andy Wingo wrote:

>>>>> But, it is 1 and 2, currently.  (+ FOO) inlines just to FOO, too
>>>>> optimistically.
>>>> 
>>>> It is unspecified according to rsr5.
>>> 
>>> I know.  I'm talking about Guile here.
>> 
>> 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.

> When a continuation that expects one value receives more values than it
> is expecting -- e.g., the <> in (+ <>) expects one value -- Guile
> truncates those values to the first one.  If such a continuation
> receives 0 values, Guile signals an error.

So here I think one should enable some kind of Lisp-extension to get that.

There is no guarantee that Guile will not change again unless doing something like that. So it is useless for regular programming.

Hans

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

[Andy Wingo]

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/

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

[Hans Aberg]

On 24 May 2011, at 17:07, 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.

Right, but as the result is unspecified according to the standard, the Guile manual suggests that the value SCM_UNSPECIFIED as an interpretation of that. I merely say that I think it would be a good idea.

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

There are various interpretations, as they can change at any time, they are rather useless for any regular programming.

Hans

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

[Mark H Weaver]

Hans Aberg <haberg-1@telia.com> writes:
> Right, but as the result is unspecified according to the standard, the
> Guile manual suggests that the value SCM_UNSPECIFIED as an
> interpretation of that. I merely say that I think it would be a good
> idea.

Although Guile often returns SCM_UNSPECIFIED when the standards say the
value would be unspecified, it does not do this in _every_ case.  To do
so would be very inefficient in some cases, would violate the standards
in other cases, and is in general impossible.

For example, the R5RS says that the result of (eq? '(a) '(a)) is
unspecified.  That's because some implementations are clever enough to
combine the two '(a) immutable list literals into a single object, in
which case #t is returned.  Other implementations make two distinct
copies of '(a), in which case #f is returned.  Of course, efficiency
requires that `eq?' be implemented as a simple pointer comparison.  The
"unspecified" cases are there to allow `eq?' to be implemented
efficiently.

The R5RS gives these examples:

  (eq? 2 2)        ==>  _unspecified_
  (eq? #\A #\A)    ==>  _unspecified_

and also says:

  `Eq?''s behavior on numbers and characters is
  implementation-dependent, but it will always return either true or
  false, [...]

If we were to make (eq? 2 2) return SCM_UNSPECIFIED, we would violate
the requirement above.

Whether `eqv?' should return SCM_UNSPECIFIED when applied to procedures
is undecidable.  The R5RS requires that the result is true when the
procedures' location tags are equal (i.e. when they have the same
identity), and requires that the result is false when the procedures
would "behave differently (return different value(s) or have different
side effects) for some arguments".  The results in all other cases are
unspecified.  The R5RS gives the following example:

  (eqv? (lambda (x) x)
        (lambda (y) y))  ==>  _unspecified_

Here we would need to determine whether two distinct procedures are
equivalent in the sense of always returning the same values and
producing the same side effects.  For such procedures, we should return
SCM_UNSPECIFIED.  Unfortunately, this is undecidable in the general
case.  If we could decide this, we could also decide the halting
problem.

Having said all this, one could still make the case that we should
attempt to return SCM_UNSPECIFIED from expressions whose values are
unspecified by the standards whenever _practical_.  However, doing this
would prevent us from implementing extensions to many aspects of the
standard.

For example, within string literals, the R5RS "does not specify the
effect of a backslash within a string that is not followed by a
doublequote or backslash."  If we were to follow your suggestion, we
should make "foo\n" return SCM_UNSPECIFIED.  In other words, we would be
unable to add our own implementation-specific backslash escapes.

Let's always keep in mind these two common rationales for unspecified
behavior in language specifications:

* to allow more efficient implementation
* to allow extensions to the standard

    Best,
     Mark

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

[Hans Aberg]

On 25 May 2011, at 02:25, Mark H Weaver wrote:

>> Right, but as the result is unspecified according to the standard, the
>> Guile manual suggests that the value SCM_UNSPECIFIED as an
>> interpretation of that. I merely say that I think it would be a good
>> idea.
...
> Having said all this, one could still make the case that we should
> attempt to return SCM_UNSPECIFIED from expressions whose values are
> unspecified by the standards whenever _practical_.  However, doing this
> would prevent us from implementing extensions to many aspects of the
> standard.

Then sec. 10.2.5.2 of the manual needs to be clarified. It should say if a returned value is SCM_UNSPECIFIED then the standard says it is unspecified, but not the other way around.

> Let's always keep in mind these two common rationales for unspecified
> behavior in language specifications:
> 
> * to allow more efficient implementation
> * to allow extensions to the standard

Then it agrees with this for unspecified values.

Hans

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

[Mark H Weaver]

Hans Aberg <haberg-1@telia.com> writes:

> On 25 May 2011, at 02:25, Mark H Weaver wrote:
>
>>> Right, but as the result is unspecified according to the standard, the
>>> Guile manual suggests that the value SCM_UNSPECIFIED as an
>>> interpretation of that. I merely say that I think it would be a good
>>> idea.
> ...
>> Having said all this, one could still make the case that we should
>> attempt to return SCM_UNSPECIFIED from expressions whose values are
>> unspecified by the standards whenever _practical_.  However, doing this
>> would prevent us from implementing extensions to many aspects of the
>> standard.
>
> Then sec. 10.2.5.2 of the manual needs to be clarified. It should say
> if a returned value is SCM_UNSPECIFIED then the standard says it is
> unspecified, but not the other way around.

Okay, I have clarified the description of SCM_UNSPECIFIED.
Thanks for pointing this out.

    Best,
     Mark

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

[Hans Aberg]

On 25 May 2011, at 18:54, Mark H Weaver wrote:

>>>> Right, but as the result is unspecified according to the standard, the
>>>> Guile manual suggests that the value SCM_UNSPECIFIED as an
>>>> interpretation of that. I merely say that I think it would be a good
>>>> idea.
>> ...
>>> Having said all this, one could still make the case that we should
>>> attempt to return SCM_UNSPECIFIED from expressions whose values are
>>> unspecified by the standards whenever _practical_.  However, doing this
>>> would prevent us from implementing extensions to many aspects of the
>>> standard.
>> 
>> Then sec. 10.2.5.2 of the manual needs to be clarified. It should say
>> if a returned value is SCM_UNSPECIFIED then the standard says it is
>> unspecified, but not the other way around.
> 
> Okay, I have clarified the description of SCM_UNSPECIFIED.

Fine.

> Thanks for pointing this out.

You are welcome.

Hans

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

[Andy Wingo]

On Sun 22 May 2011 16:02, Andy Wingo <wingo@pobox.com> writes:

> But, it is 1 and 2, currently.  (+ FOO) inlines just to FOO, too
> optimistically.

Fixed in git.  (+ FOO) now inlines to (values FOO).

Andy
-- 
http://wingolog.org/