Vlasyimil Adamovsky <v...@world2u.com> wrote in article <E5GyuM....@nonexistent.com>...

* cosc1...@Bayou.UH.EDU
| In C however, you need pointers for tasks which do not require them --
| modifying arguments to functions!

the very existence of a "better" mechanism to do this in C++ (references)
suggest that multiple return values really do make a lot of sense, despite
all the hostile arguments from certain camps when you suggest this.  that a
widely used tool like `perl' also supports them as a matter of course, and
to its users delight, is perhaps indicative of a fundamental flaw in the
argument that functions in programming languages should only return one
value, as opposed to functions in mathematics, which already differ greatly
from "our" functions.

incidentally, I happen to dislike the approaches to faking the return of
multiple values that don't actually return multiple values: structs in C,
lists in Scheme, OUT arguments in Ada, NAME in Simula, VAR in Pascal,
references (mere syntactic sugar for pointers) in C++, etc.

my favorite example is getting the current time under Unix and in C:
`gettimeofday' takes two pointers to structures you have to declare and
possibly allocate memory for, fills them in for you, and then you get to
retriev the values from them.  the function returns four integers in this
very complicated way: seconds since the epoch, microseconds into the
current second, time zone as the number of minutes west of Greenwich, and
the type of daylight savings time to apply.  let's also not forget that
`gettimeofday' includes an error return value to indicate only one kind of
error: "an argument address referenced invalid memory", or a stray pointer.
to decode this time into your current timezone, you need to decode it with
the function `localtime', which, unsurprisingly, takes a pointer to the
first return value from `gettimeofday' and returns a pointer to statically
allocated memory that contains the values you need in a structure.  you
need to make certain that you copy all of these values to your own space
before some other function clobbers it.  `localtime' returns 11 values,
most of which you don't need.  (and then, of course, the day of the month
is a number in the range 1-31, but the month is a number in the range 0-11
and the year is 1900 less than the actual year, but that's another can of
worms.)  all this to achieve the effect of multiple return values!  to
summarize: `gettimeofday' requires pointers to preallocated memory to
return multiple values, and has an error return value to barf on the
address of that memory, while `localtime' returns a pointer to a static
memory area overwritten by each call.  this epitomizes the Unix interface
as I see it -- Unix doesn't give its programmers the time of day.

: the very existence of a "better" mechanism to do this in C++ (references)
: suggest that multiple return values really do make a lot of sense, despite
: all the hostile arguments from certain camps when you suggest this.  

Multiple returns make plenty of sense.

: that a
: widely used tool like `perl' also supports them as a matter of course, and
: to its users delight, is perhaps indicative of a fundamental flaw in the
: argument that functions in programming languages should only return one
: value, as opposed to functions in mathematics, which already differ greatly
: from "our" functions.

Frankly I'm all for the return of multiple values from functions.

: incidentally, I happen to dislike the approaches to faking the return of
: multiple values that don't actually return multiple values: structs in C,
: lists in Scheme, OUT arguments in Ada, NAME in Simula, VAR in Pascal,
: references (mere syntactic sugar for pointers) in C++, etc.

Well I like to be able to simply return the values without
faking also, but if the "faking" is transparent then I won't
mind.  For instance, Haskell doesn't allow multiple returns
from functions but it does consider the tuple to be a basic
data type and therefore multiple values can be encapsulated
in a tuple and easily used.  For instance:

(x, y, z) = f a b c

Here, f is returning one value, a tuple, but you can place
variables inside the tuple and they will get the value of
each corresponding element.  Tuples are also homogenous, so
even though this is "faking", it's virtually invisible and
is even better than the real thing since you can store
the entire return in one variable and later pick out the
components with great ease and elegance.

[Snip -- long but excellent example of the convolutions you can
go through to simulate multiple return values]

: all this to achieve the effect of multiple return values!  to
: summarize: `gettimeofday' requires pointers to preallocated memory to
: return multiple values, and has an error return value to barf on the
: address of that memory, while `localtime' returns a pointer to a static
: memory area overwritten by each call.  this epitomizes the Unix interface
: as I see it -- Unix doesn't give its programmers the time of day.

All I can say is I couldn't agree more.  Great example and a
great point.

: #\Erik
: --
: my other car is a cdr

: each corresponding element.  Tuples are also homogenous, so
                                               ^^^^^^^^^^

Hetereogenous is what I meant to say.  Apologies all.

[Snip]

: : #\Erik
: : --
: : my other car is a cdr

: --
: Cya,
: Ahmed

--
Cya,
Ahmed

In article <E5GyuM....@nonexistent.com>,
        v...@world2u.com (Vlasyimil Adamovsky) writes:

I have no questions, M'Lud. The defence rests.

--
si...@intelligent.co.uk (Simon Brooke) http://www.intelligent.co.uk/~simon

With a mighty <3064828794077...@naggum.no>,
e...@naggum.no wibbled into the void...

[beautiful critique of C/C++ kludges for returning multiple values]

"Dann Corbit" <dcor...@solutionsiq.com> starts a C++/Lisp war...

In article <5dgboh$...@Masala.CC.UH.EDU> cosc1...@Bayou.UH.EDU (cosc1...@bayou.uh.edu) writes:

* Erik Naggum <e...@naggum.no> writes:
| incidentally, I happen to dislike the approaches to faking the return of
| multiple values that don't actually return multiple values: structs in C,
| lists in Scheme,

* Chris Bitmead
| I don't see the problem of returning lists as in Scheme.

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.

when multiple return values require special care in the compiler, be that
with some heavily optimized forms of lists, or register-allocated vectors
or whatever, it is silly to argue that they aren't special and could just
as well be represented by some ordinary data type.

| There is a proposed standard for multiple return values in scheme.  It
| can be implemented as syntactic sugar for returning lists.

I really hope it can be implemented more efficiently, too.

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.

(define values list)
(define (call-with-values val func) (apply func (val)))
e.g.
(call-with-values (lambda () (values 6 7)) *)
=>42

* 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.

This message was composed in response to a thread whose subject
was "What is wrong with OO ?".  I have changed the subject line,
removed comp.lang.c++ from the list of newsgroups, and added
comp.lang.scheme (in case its residents need new fuel).

The code posted by Chris Bitmead was not a correct implementation
of R5RS multiple return values, which requires (VALUES X) to be
equivalent to X, and requires (CALL-WITH-VALUES * -) to evaluate
to -1.

It is true that an inefficient version of the R5RS multiple value
facility can be implemented in R4RS Scheme using lists, but the
code is somewhat more complex.  Furthermore an implementation
in R4RS Scheme wouldn't be able to perform full error checking.

    (+ (floor 17.42) 3)
and (+ (FIRST-VALUE (FLOOR 17.42)) 3)

would be errors because both contain a call to FLOOR in which the
continuation demands exactly 1 argument.

This is a matter of philosphy.  The Scheme community considered
a semantics in which the continuation passed to FLOOR would
accept 1 or more return values, but some felt that Common Lisp's
implicit ignoring of extra return values would lead to bugs in
which a return value that should not be ignored would be.

#flame on

In fact, the Scheme community went so far as to adopt a semantics
in which

    (begin (floor 17.42) 3)

would be an error if FLOOR were to return 2 values.  I think this
is incredibly silly.  I would be unhappy with any implementation
of R5RS Scheme that does not provide the option of ignoring such
"errors".

#flame off

Erik continued:

William D Clinger <w...@ccs.neu.edu> writes:

        ...

Congratulations to the Scheme community :)  It took them 13 years to
adopt as a standard what was there and obviously useful (and non
consing) in Common Lisp in 1984.  Of course, in the process the
semantics had to be changed. :)

In the year 2010 R6RS will probably contain a "standard" version of
'format' or maybe of keywords parameters.  :)

(declaim (extension:flame-off))

Chris Bitmead <Chris.Bitm...@Alcatel.com.au> wrote in article
<BITMEADC.97Feb19145...@Alcatel.com.au>...

so you have to waste a good chunk of time and money on imposing it.  In
the design of C++ is a punishment/reward system that is heavily in favor of
violating OO.

True programming freedom is having a language that is strict enough to make
certain classes of programming errors unthinkable, and real optimization is
using better
algorithms (which may be too unwieldly to write in a really raw language
like C++).

For example:
O(n^2) algorithms written in optimized assembler can't compete with
O(n*lg(n)) algorithms
written in ...say pitiful VB... if you give it enough data to chew on.
With 32M-64M becoming standard on PCs, that day is coming very soon.  The
capacity of PCs is changing the whole meaning of 'optimization' and it is
making less and less sense to haggle on bytes and CPU cycles.  Really good
algorithms can be a pain to write in
C++ because it's too close to the metal, so you see silly people trying to
save bytes
and CPU cycles within an algorithm that is wasting an order of magnitude
more than it
ever should in any language whatsoever.  C++ should not be used for most
types
of applications because of its promiscuity, inconsistency, and complexity.