🚀 go-pugleaf

   From: gateley@m2.csc.ti.com (John Gateley)
   Newsgroups: comp.arch,comp.lang.misc

   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.

I don't know what you mean by unpackaging them.  The typical use I'd
make of a divrem function, in the high-level terms in which I think,
is usually something like this:

(1) compute the numerator
(2) compute the denominator
(3) perform divrem
(4) give a name to the quotient and remainder
(5) proceed with my computation, now that I have the quotient and remainder

For example,

(multiple-value-bind (n-blocks offset-within-block)
    (divrem (get-total-size-in-units) size-of-block-in-units)
  (format t "There are %d blocks, with %d units left over%n"
          n-blocks offset-within-block)
  (dotimes (i n-blocks)
    (process-one-block))
  ... and so on ...
  )

Back before we had multiple values, we had to create bogus structures;
divrem would return one, then we'd need this awkward code to extract
the values from the structure.  To add insult to injury, the structure
was then garbage and contributed eventually to GC costs.  The great
thing about this style is that there isn't any unpackaging.  There
isn't any synthetic, bogus, distracting object whose only purpose is
to hold the two values.

Such an object is bogus because it does not model any concept at the
level of the application; it's only there for programming language
purposes, not because it is a useful expression of what the program is
about.  (Usually, you notice this when you try to figure out what its
name is.  Usually there isn't any good name and you have to make up
something rather non-mnemonic and awkward.)

I used the programming style illustrated above in Zetalisp and Common
Lisp for about ten years, and in my experience and opinion, it's quite
useful and readable.