[racket] Multiple return values

At Fri, 16 Dec 2011 14:45:51 +0200, Markku Rontu wrote:
> Hmm, I don't get the logic. Ignored single return value is not a bug and is
> ok (because that's how things happened to be in that case in the first
> place) but ignored multiple-value is a bug (because that's how things
> happened to be in that case in the first place)?

That's not quite right. A `begin' ignores all values that are returned
by expressions preceding the last, and that's the case whether a given
expression returns a single or multiple values. So, that issue is not
about single versus multiple values, but about always ignored versus
not ignored.


At Thu, 15 Dec 2011 15:39:04 +0400, Zayr Okale wrote:
> Since one of the reasons behind 
> multiple return values is, as David Van Horn pointed out, symmetry with 
> multiple input values (function arguments), then why optional input 
> values are allowed, but optional output values aren't?

Following up on Stephen's reply: If you provide too many arguments to a
function, then the extra arguments are not ignored; you get an
exception. Returning multiple values to a single-valued context is
treated the same way, raising an exception.

It sometimes happens that a higher-order function accepts a "callback"
argument that itself can take either N or M arguments. The function can
test whether the callback wants N or M arguments using
`procedure-arity-includes?'. To me, the right way to support functions
like Common Lisp's `floor' would be to allow the function to check the
arity of the current continuation, and then it can choose to return 1
or 2 values. That doesn't work currently, though; continuations claim
to accept any number of arguments.

As a practical matter, I find that the need for varying return arities
is rare enough that it's ok to just pick different names --- `floor'
vs. `floor*', say --- while the need for optional arguments is so
common that picking different names is painful. Better support for
varying result arities is something we can keep in mind, though.


If I had it all to do over again, I'd probably get rid of multiple
values and just have tuples. The compiler and run-time system would
cooperate to match tuple results with tuple receives to avoid
allocation much of the time, but a tuple would still count as a value.
That choice, of course, would move even further away from the idea that
extra result values can be ignored, and it would move away from a
symmetry between arguments and return values. I think it would work
better overall, but I'm not sure.