[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[ALAN: multiple return values]

I agree with ALAN here.  I used to prefer the stricter semantics, but
after some thought I've arrived at the conclusion that it is silly.
It adds no new functionality and is hardly more convenient than
passing an explicit continuation (syntax for which can be provided).

The case I like to consider is the case of QUOTIENT (there are many
others like it).  It is often very cheap (or even necessary) to
produce the remainder of an integer division when computing the
quotient.  Thus it would be natural for QUOTIENT to return the
remainder as a second value.  The strict semantics would force anyone
using quotient to use RECEIVE-VALUES, although a very common use, in
fact, is to ignore the remainder.  In the absence of "loose" multiple
values, there are two possibilities, both distasteful:

- Provide another procedure which returns both (as in the case of MIT
Scheme's INTEGER-DIVIDE), but this tends to increase the number of
procedures that users have to know about to an unreasonable extent.

- Force users to use both QUOTIENT and REMAINDER when both results are
desired.  The only way to get efficiency out of this one is to fall
into the "mighty compiler" assumption.

I think, therefore, that it would not be a good idea to agree on a
standard that allows the strict semantics (and I would vote against
it).  If some people have serious objections to the "loose" semantics,
then we may be better off not standardizing at all.