Subject: Re: What is wrong with OO ? From: Erik Naggum <erik@naggum.no> Date: 1997/02/21 Newsgroups: comp.lang.c++,comp.lang.lisp Message-ID: <3065519826667614@naggum.no> * Erik Naggum | that's just like saying you don't see the problem of returning structures | in C, isn't it? returning a compound structure is very different from | returning multiple values, and specifically so in the many cases where only | the first value will be used. * Chris Bitmead | I fail to see the big difference. Sure, having a standard way of doing | it allows the compiler to make more optimisations. (The more library | functions in a language that are standardised the better you can | optimize. Nothing unique about multiple return values.) | | Just to illustrate, here is an example the Scheme multiple return value | standard proposal, implemented as lists. (It's probably a naive and | flawed implementation), but you get the idea about how little difference | there is. sigh. let me illustrate what I mean with "in the many cases where only the first value will be used" since you (and others) continue to talk about operations on _all_ the returned values. in Common Lisp, `floor' of one argument returns two values, the largest integer smaller than the argument, and the "rest". normally, you don't need the second value. in Common Lisp, (+ (floor 17.42) 3) evaluates to 20. if I read your Scheme proposal right, you need to know that the function can return multiple values and the expression becomes (+ (first-value (floor 17.42)) 3), where `first-value' is just another name for `car'. it is _this_ aspect of multiple values that requires special handling in the compiler, and which, if you fake them with lists or whatever, you _still_ must recognize as a special property of the first of the returned values that does not apply to the first element of a returned list. a multiple value return mechanism that does not cons is _very_ valuable. one that conses and costs a hell of a lot more than normal value returns (e.g., in always having to fetch the first value explicitly) is just too painful to use. #\Erik -- if you think big enough, you never have to do it