At Fri, 16 Dec 2011 14:45:51 +0200, Markku Rontu wrote: > Hmm, I don't get the logic. Ignored single return value is not a bug and is > ok (because that's how things happened to be in that case in the first > place) but ignored multiple-value is a bug (because that's how things > happened to be in that case in the first place)?
That's not quite right. A `begin' ignores all values that are returned by expressions preceding the last, and that's the case whether a given expression returns a single or multiple values. So, that issue is not about single versus multiple values, but about always ignored versus not ignored. At Thu, 15 Dec 2011 15:39:04 +0400, Zayr Okale wrote: > Since one of the reasons behind > multiple return values is, as David Van Horn pointed out, symmetry with > multiple input values (function arguments), then why optional input > values are allowed, but optional output values aren't? Following up on Stephen's reply: If you provide too many arguments to a function, then the extra arguments are not ignored; you get an exception. Returning multiple values to a single-valued context is treated the same way, raising an exception. It sometimes happens that a higher-order function accepts a "callback" argument that itself can take either N or M arguments. The function can test whether the callback wants N or M arguments using `procedure-arity-includes?'. To me, the right way to support functions like Common Lisp's `floor' would be to allow the function to check the arity of the current continuation, and then it can choose to return 1 or 2 values. That doesn't work currently, though; continuations claim to accept any number of arguments. As a practical matter, I find that the need for varying return arities is rare enough that it's ok to just pick different names --- `floor' vs. `floor*', say --- while the need for optional arguments is so common that picking different names is painful. Better support for varying result arities is something we can keep in mind, though. 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. _________________________________________________ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/users