[plt-scheme] Multiple values

From: Adam Wick (awick at cs.utah.edu)
Date: Tue Feb 21 04:43:59 EST 2006

On Feb 21, 2006, at 2:07 AM, Jim Blandy wrote:
> But in this case, utility and happiness did not bloom magically into
> existence through the removal of restrictions, as the Scheme mythology
> requires.  It doesn't seem that people generally find multiple value
> returns very useful.

Just as a data point, I find multiple value returns very useful, I  
use them frequently, and they make me very happy.

The example I use most often involves compiler passes. Many times in  
a compiler pass, for any particularly expression or statement, how  
you want to recombine the statement after recursing over the sub- 
parts depends on additional information about those subparts. For  
example, what variables they reference, the types of the  
subexpressions, whether or not one of the subexpressions called setjmp 
() or call/cc, and so on. Multiple value returns offer a very  
convenient way to pass the information back up the recursion stack  
without making the routines go exponential.

You can, of course, pass the information back in other ways. Passing  
tuples back certainly works, but it's a pain; you're constantly  
allocating the tuple to return, immediately splitting it apart and  
then let-binding it anyways. It makes more sense to me to just return  
the values directly, and then let-bind them all at once with let- 
values. CPS works, and it's what I used before I learned the joys of  
value/let-values, but CPS does bad things to one's stack trace when  
trying to hunt down errors. Also, as a minor point, at some point  
with CPS either you begin to fragment your program past sensibility  
or your indenting just goes insane.

I'd also like to note that just about every C API I've seen would be  
vastly improved by multiple value returns. Passing information back  
through pointer arguments (because you need the return value for a  
possible error code) is such a deep and true invitation to pain.


Posted on the users mailing list.