Am Mo., 7. Nov. 2022 um 15:45 Uhr schrieb Lassi Kortela <xxxxxx@lassi.io>:
>
> > R6RS allows zero or more than one value.
>
> That's good.
>
> > Additions to R[67]RS outside the standard libraries can enforce the
> > "unspecified = zero values" convention without problems with backward
> > compatibility.
>
> Can, but probably should not since there are so many SRFIs and other
> libraries written by dozens of people. Many of whom are out of reach.
>
> A macro would be a smooth way to let individual Scheme implementations
> solve this problem for themselves. With enough uptake, perhaps most of
> them will converge on a solution one day, which can then be enshrined in
> RnRS.
>
> >> 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.
>
> We probably can't excise "unspecified" from RnRS at this point since
> there are too many implementations. But kudos to anyone who tries.
>
> > 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.
>
> Probably not a type error. Values are received into locations, which are
> dynamically typed in Scheme. "Wrong number of locations" is different
> from "wrong type of value in a location", no?

A "type" can mean a lot of things.  You can interpret "type" through
the number of values (see the discussion in SRFI 165) and this is a
sound typing theory for Scheme.

> Intuitively, tuples have a similar nature to multiple values, but tuples
> are objects. I'm starting to lean into the view that Lisp-style multiple
> values are a mistake.

Not everything in Scheme is an object.  In fact, most entities aren't.