Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!mips!pacbell.com!att!ucbvax!bloom-beacon!dont-send-mail-to-path-lines
From: jonl%kuwait@lucid.COM (Jon L White)
Newsgroups: comp.lang.scheme
Subject: Multiple return values
Message-ID: <9104031856.AA27280@kuwait>
Date: 3 Apr 91 18:56:19 GMT
Sender: daemon@athena.mit.edu (Mr Background)
Organization: The Internet
Lines: 36

In Scheme Digest V3 #175, Jinxs says of the Common Lisp MV style:

    Date: 2 Apr 91 18:57:22 GMT
    From: "Guillermo J. Rozas" <jinx@zurich.ai.mit.edu>
    . . . 
    In particular, I believe that it should be possible to re-define

    (define (quotient x y)
      (values (old-quotient x y)
	      (old-remainder x y)))

    and have no-one who used the old version of QUOTIENT notice.


This is just an application of the principle of "referential transparency",
which is THE reason why Common Lisp opted for a multiple-value syntax
rather than fostering an embedding of multiple values into user-created
structures like LISTs or VECTORs.

There are times when this "transparency" causes hiccups -- like the
dissimilarity between passing in "multiple arguments" to a function
and receiving back "multiple values".  After long experience with
both styles of argument passing -- Interlisp's which simply dropped
any extra arguments passed into a function and padded out with NIL's 
any formal parameters that lacked passed-in arguments, and MacLisp's 
which signaled "wrong number of arguments" errors -- the CL community 
decided that "transparency" on the callee's side was counterproductive
(i.e., the client ought to know exactly the argument spectrum of the 
called function) but that "transparency" on the caller's side is 
extremely useful for functions like your QUOTIENT example.  

In short, being ignorant of extra returned information isn't nearly the 
disaster that being ignorant of some required input parameters is.


-- JonL --