Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!usc!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: 2 Apr 91 18:57:22 GMT References: <1991Mar26.155905.12906@daffy.cs.wisc.edu> <1991Apr1.181633.12561@snitor.uucp> Sender: news@ai.mit.edu Reply-To: jinx@zurich.ai.mit.edu Organization: M.I.T. Artificial Intelligence Lab. Lines: 43 In-reply-to: doug@snitor.uucp's message of 1 Apr 91 18:16:33 GMT I think my proposal has two advantages over the one described by Pavel: 1. It is simpler. No fundamentally new mechanisms need to be added to the language; the only language change is a simple generalization of let and let*. 2. It is more powerful. My proposed extension to let makes it easier to use procedures which represent multiple return values by a list; IN ADDITION, the new let syntax can be used to simplify code which disassembles list structure. Also, Scheme provides a rich set of operations on lists. Any of these operations can be used on the value returned by a procedure that adheres to the multiple-return-values-are-lists convention. Perhaps I should claim that my proposal is more synergistic. There is another issue which your proposal does not satisfy, while Pavel's can be made to. I, and some other people, think that there is no reason (besides efficiency) nor is it particularly desirable to add multiple return values to Scheme unless new expressive power is gained. Certainly neither proposal adds any as stated. The form of additional expressive power that I have in mind is some form of that available in Common Lisp, by which additional return values can be dropped if not expected. In particular, I believe that it should be possible to re-define (define (quotient x y) (values (old-quotient x y) (old-remainder x y))) and have no-one who used the old version of QUOTIENT notice. Your proposal can't really accommodate that, while Pavel's can (although it does not require it). What you propose is a possible implementation of Pavel's proposal if no new expressive power is gained, but implementations that want to extend his proposal along these or other lines can do it with his but not yours.