Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!sdd.hp.com!spool.mu.edu!snorkelwacker.mit.edu!ai-lab!zurich.ai.mit.edu!jinx From: jinx@zurich.ai.mit.edu (Guillermo J. Rozas) Newsgroups: comp.lang.scheme Subject: Re: Multiple return values Message-ID: Date: 3 Apr 91 21:41:34 GMT Article-I.D.: chamarti.JINX.91Apr3164134 References: <1991Apr1.181633.12561@snitor.uucp> <9104022333.AA00572@cymbal.reasoning.com.> <14592@life.ai.mit.edu> Sender: news@ai.mit.edu Reply-To: jinx@zurich.ai.mit.edu Organization: M.I.T. Artificial Intelligence Lab. Lines: 62 In-reply-to: tmb@ai.mit.edu's message of 3 Apr 91 11:22:35 GMT In article <14592@life.ai.mit.edu> tmb@ai.mit.edu (Thomas M. Breuel) writes: I think it is wrong to add multiple return values to Scheme for efficiency reasons: the gain in efficiency is small to non-existent for good compilers, and the semantics are messy. I think you are mistaken about the efficiency issue. It obviously depends on whether you use multiple values frequently or not, and if you do, it is clear that the CONSING behavior of either CPS code or multiple-values-as-lists is much worse than that of a properly implemented multiple values facility. I don't know what you mean by semantics. If you mean the naive semantics, I think you are mistaken, because there are several simple consistent semantics for multiple values that are easy to describe. If you mean the denotational semantics of Scheme that appear at the end of R3RS, you are also mistaken, since Will Clinger cleverly arranged it so that only two items need to be modified to integrate multiple values into the current language, namely the definition of ``single'', and the expansion of ``begin''. In order to gain efficiency through the use of a special multiple return values data type, you have to seriously restrict how you can manipulate multiple return values (if you treat a set of multiple return values as a first class object, you might as well use lists, since the Scheme optimizer would face exactly the same problems in compiling this new data type efficiently). This adds lots of semantic hair to the language. Your assumption that there is a new multiple-values data type is not correct. A simple implementation leaves a special marker on the stack when multiple values are expected, and VALUES checks for the presence of the marker and puts the values in the correct registers or stack locations. Thus the values are never consed on the heap with no need for compiler smarts. There is no need for first-class VALUES objects, nor are they particularly desirable. And, the gains in execution speed are dubious at best. In fact, I suspect that since modern Scheme implementations have done away with the stack altogether and allocate all procedure activation frames on the heap, data structures representing multiple return values would simply end up on the heap as well. Also, in those cases where multiple return values could be allocated in a stack-like manner, a Scheme compiler stands a pretty good chance to eliminate heap allocation even when they are implemented using lists. You are also mistaken about what modern Scheme implementations do. All of the modern compilers that I am familiar with try very hard to use a stack, and resort to heap-allocated closures only when they can't figure out what else to do. A nice addition to Scheme that would make the use of lists as multiple return values a little more convenient would be some form of destructuring. I doubt that the Scheme committee as a whole could agree on destructuring binding for argument lists (which I would prefer), but a special form DESTRUCTURING-BIND or DLET would certainly be nice. Since we are supposedly close to agreeing on a macro facility, users can write their favorite destructurers and make them publicly available. I don't think that this is the sort of thing we should standardize on.