Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!uwm.edu!psuvax1!hsdndev!husc6!carlton From: carlton@husc10.harvard.edu (david carlton) Newsgroups: comp.lang.scheme Subject: Re: Multiple return values Message-ID: Date: 5 Apr 91 04:36:11 GMT References: Sender: news@husc6.harvard.edu Organization: Citizens for Boysenberry Jam Lines: 44 In-reply-to: jinx@zurich.ai.mit.edu's message of 3 Apr 91 21:01:50 GMT In article jinx@zurich.ai.mit.edu (Guillermo J. Rozas) writes: There are a lot of issues in multiple values that haven't been mentioned. I like to classify them by code. Here are some of the more controversial points. ... E: Is the following expression legal, and, if so, what does it return? (let ((x (values))) x) ... My preferences are: E: No. But would accept a compromise where any of the above are left unspecified. My arm would need a lot of twisting to accept a proposal that requires any of those decisions to be otherwise. Although this set of choices may appear inconsistent, the crucial observation, that points out the asymmetry between APPLY and VALUES is that there are no implicit procedures, but there are implicit continuations. Furthermore, the continuation that VALUES is invoking is not apparent in the VALUES expression, but the (expression evaluating to) the procedure in APPLY expressions is. Given these asymmetries, the decisions need not be the same. I think that I agree with you everywhere but here - I would probably want to allow E as well, though it should be undefined what happens if the value returned by the expression is ever used. This would nicely solve the problem of what to do with the special forms and functions that currently return undefined values - they could simply not return a value. Of course, you could do that in any case, but then you would break currently legal code that calls those functions from locations whose continuations expect a single argument. Not sure, though - I'm not even sure that I would want to allow (let ((x (values 1 2))) x) david carlton carlton@husc9.harvard.edu