[racket-dev] [racket] Multiple return values

[re-directed to Dev]


On Dec 16, 2011, at 9:47 AM, Matthew Flatt wrote:

> 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.


This is an interesting point. We can think of vectors as syntactically 
awkward tuples and we can use match to fake tuple-receive. We could at 
least implement some syntactically tolerable version of it and experiment. 

;; --- 

Having said that I will personally admit that I went a full 180 degrees. 
I really disliked multiple values in the 1990s when both Soft Scheme 
and MrSpidey did badly with values and any study of 'type inference' for
Scheme suggested values weren't quite right -- from a meta-perspective. 

By now, I find myself programming with multiple values quite a bit. I 
like the convenience of define-syntax for sharing something state-ish 
and easily. I like for/fold with multiple-values a lot because it makes 
loops that 'feel imperative' so functional. I don't even know whether 
Haskellians or MLers have anything remotely as elegant, and I'd love for
you to check and write a 5-page JFP paper that explains these for loops. 
In short I have come around to the pragmatics of multiple values as 
provided by Racket. 

;; --- 

My hunch is that I forgot my meta-meta-lessons from the 1980s. Back then
the standard argument for lazy programming was that 'the regular lambda
calculus is uniform and easy to use and you never have to think about 
when substitution works'. [This argument applied both for the misleading
idea of thinking 'applicative reduction' -- whatever that really is --
had anything to do with CBV or the Plotkin-style reasoning.] Worse, when
you generalize this to imperative languages, it looked like it all broke
down and therefore it wasn't any good either. My reply used to be that 
pragmatics of programming comes first and we have got to develop the 
reasoning tools for the pragmatically good languages, though with some
give and take. [My argument works equally well for axiomatic condemnation
of call/cc and friends.]

Well, this argument applies to multiple values, too, and I just wish I
had recalled it in the 90s. 

-- Matthias