🚀 go-pugleaf

In article <1207@quintus.UUCP> pds@quintus.UUCP (Peter Schachte) writes:
>CommonLisp, you may point out, does have multiple returns.  In fact,
>CommonLisp is a good example of the problem I'm pointing out.
>Basically, there's not much you can do with a multiple-value expression
>except ignore all but the first value (which happens if you nest a MV
>expression within a function call) and assign its results to variables.

Common Lisp is much more powerful than this:
  multiple-value-call
  multiple-value-prog1
  multiple-value-bind
  multiple-value-setq

Multiple-value-setq is the mv assignment being discussed. MVBind is the
binding construct which takes several values, creates variables and binds
the values to the variables. MVProg1 is like a begin expression, except it
returns (as multiple values) all the values returned by the FIRST expression
in the body. MVCall allows 'nesting of expressions', it calls a function
using multiple values.

Someone else claimed that returning multiple values requires garbage
collection. This is not correct. Multiple values are implemented as
an extension of the way a single value is returned, and do not inherently
require GC; they are not a separate structure.

In my experience with Common Lisp, multiple values are useful, but not
terribly so. One `problem' with them is that a set of values is easy
to percieve as a structure, but this is not really true. They are just
values returned on the stack (or however functions/expressions return
values), and most things I want to do with them requires removing them
from the stack to a separate structure. This is not a problem with
multiple values, it is a problem with my perception of what they do.

In the divrem example being discussed for example, many of the problems
center around using the quotient and remainder after they have been
returned. But the only things it makes sense to do with them is either
return them as values to someone else, or unpackage them and use them.
After unpackaging them, they are no longer multiple values, and should
not be thought of as such.

John
gateley@m2.csc.ti.com