Am Sa., 13. Nov. 2021 um 19:47 Uhr schrieb John Cowan <xxxxxx@ccil.org>:

Thanks! I partially retract my second claim, though I note that Kawa doesn't claim R6RS compliance, and this provision makes Kawa not R[57]RS-compliant either. Just saying.

If continuations that accept one value in Kawa silently accept multiple values, R7RS-compliance will actually be maintained.

(I don't know what is actually be true for Kawa, but this is how Chibi works, for example.)

In any case, breaking R7RS-compliance here would actually be a very good idea IMO. A program that would break under this incompatibility would most likely include a logical error anyway. And in the unlikely case that it wouldn't, it could be easily fixed.

Marc

On Wed, Nov 10, 2021 at 8:34 AM Per Bothner <xxxxxx@bothner.com> wrote:

On 11/9/21 23:03, Marc Nieper-Wißkirchen wrote:
arantees the R7RS behavior for its built-in procedures, it cannot guarantee this for all extension libraries.
>
> Similarly, when someone implements (set! x 0) to return zero or two values, I'll be happy to retract my claim that in practice R6RS procedures that are defined to return unspecified values in practice return exactly one value.
>
>
> Neither do I know of an implementation that doesn't return exactly one value. But I would prefer if zero values were returned because it would help a lot to catch a number of errors earlier.

In Kawa set! returns 0 values, as does set-car! and many others.
More specifically, the return type is void, and the return values is #!void, which is
equivalent to (values).
--
--Per Bothner
xxxxxx@bothner.com http://per.bothner.com/