Am Mo., 7. Nov. 2022 um 15:14 Uhr schrieb Lassi Kortela <xxxxxx@lassi.io>:
>
> > In some sense, it can make a sound theory.  Namely, when the number of
> > return values is undefined, something like
> >
> > (let ([x (set! y 4)])
> >    ...)
> >
> > would be a typing error because the assignment expression could return
> > not only one but also zero or more than one value.  Automated testing
> > tools could exploit this.
>
> I looked it up in R7RS. The term it uses is "unspecified". ("Undefined"
> is used for an undefined variable in the formal semantics.)
>
> "If the value of an expression is said to be "unspecified," then the
> expression must evaluate to some object without signaling an error, but
> the value depends on the implementation; this report explicitly does not
> say what value is returned."
>
> If I read that right, R7RS says an unspecified value must be exactly one
> value, not zero or >1. That's too bad - I agree zero values would make
> sense.

R6RS allows zero or more than one value.  But also failed to enforce
zero values.

Additions to R[67]RS outside the standard libraries can enforce the
"unspecified = zero values" convention without problems with backward
compatibility.

> If an unspecified return could be "zero or more values", then the same
> expression could return a different number of values each time. A test
> can't reliably catch that.
>
> > But always zero values would undoubtedly be better.
>
> If there's a standard expression (unspecified) or (void), it could
> return zero values in some implementations.

That would be a good macro for writing code that has to work with
several implementations and standards; but it shouldn't be in a
standard itself.

> (In an implementation with
> real multiple values, a zero-value return will be coerce into some
> default value when the receiver is expecting a value. So in that
> implementation, it would not be much of a problem if (unspecified)
> returns zero values even if we interpret RnRS to say that one value
> should be returned.)

R7RS, not RnRS.

Coercing zero values into some default value is precisely what we
don't want because it covers bugs.  It's a typing error and the
implementation should not be silent about it.