Am Mo., 7. Nov. 2022 um 14:18 Uhr schrieb Lassi Kortela <xxxxxx@lassi.io>:
>
> > In what sense do you think that potential problems arise?
>
> When code is only tested one one implementation, which deterministically
> returns e.g. the last value.

I could add a recommendation of returning zero values.

> > An expression like "(set! <identifier> <expression>)" could, in
> > principle, return the value, which is assigned to the identifier.
>
> Common Lisp's setf and setq do that, per the spec.
>
> > From a theoretical point of view, the only convincing stricter
> > semantics would be to return no values (as per "(values)").
>
> (values) would be a decent choice. (Optimizers can omit the return value
> where it's not used, so there ought not to be a performance penalty for
> specifying a value.)
>
> More generally, RnRS has a bunch of places where the return value is
> undefined. So perhaps a universal convention for what to do about
> undefined returns would be more productive than addressing the problem
> in only one SRFI.

Regarding program correctness and theoretical appeal, the best
resolution would be to equate "undefined returns" with "zero values".
Some code may break, but such code is probably buggy with a high
chance.