Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!sdd.hp.com!spool.mu.edu!snorkelwacker.mit.edu!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: <9104042101.AA28583@kuwait>
Date: 4 Apr 91 21:01:00 GMT
Article-I.D.: kuwait.9104042101.AA28583
Sender: daemon@athena.mit.edu (Mr Background)
Organization: The Internet
Lines: 70

In Scheme Digest V3 #176

    Date: 3 Apr 91 10:47:43 GMT
    From: "Thomas M. Breuel" <tmb@ai.mit.edu>

    A nice addition to Scheme that would make the use of lists
    as multiple return values a little more convenient would be some
    form of destructuring. I doubt that the Scheme committee as a whole
    could agree on destructuring binding for argument lists (which I would
    prefer), but a special form DESTRUCTURING-BIND or DLET would certainly
    be nice.


In fact, Lisp/370 (predecessor to IBM's "Uncommon Lisp" called
LISP/VM) had automatic destructuring in every lambda argument
position, including the input arguments.  By 1980, such an 
extension was working in parts of MacLisp and in VAX/NIL.  In
fact, it even "destructured" over vectors as well as lists; e.g.:

     (defun foo ((a #(b c) . l) &optional haha) ...)

could be called like  

     (foo '("Note This" #(dollars cents))) 

and the arguments would be bound thus:

       a = "Note This"
       b = dollars
       c = cents
       l = ()

This was particularly useful in the VAX/NIL compiler and assembler
where much more use was made of simple vectors rather than lists.  
We even had a version that would destructure over DEFSTRUCT instances,
in the expectation that "objects" like vectors and structures would 
displace lists as the more common data structure "of choice".

There was no technical difficulty in extending these ideas for Common 
Lisp; but instead a debate arose over whether the pattern should be 
defined to be a data object (i.e., a cons cell implying taking the CAR 
and CDR of the input argument) or to be a program [i.e., for the above
example, write `(,a `#(,b ,c) . ,l) instead of (a #(b c) . l)].  And in 
addition to this debate, there was an undercurrent of thinking that LET
was sacred and primitive in it's historic, one-to-one definition.  So 
that killed that.  Too bad.  I'm always having to intersperse lines of 
LET's amongst multiple incarnations of DESTRUCTURING-BIND, as well as 
with MULTIPLE-VALUE-BIND's.




re: Date: 3 Apr 91 21:01:50 GMT
    From: "Guillermo J. Rozas" <jinx@zurich.ai.mit.edu>

    There are a lot of issues in multiple values that haven't been
    mentioned.  I like to classify them by code.  Here are some of the
    more controversial points. . . . 

Your particular suggestions look fine to me, but what's missing from
the dialogue is the concept, elaborately worked out in the CL world,
of constructs that (1) truncate multiple-values down to one value, 
and (2) "pass back" multiple values.  For example, your case D easily 
falls out of one of the obvious rules here for (1) [unless there is to 
be a radical change to the syntax/semantics of LET, to accommodate 
either destructuring or multiple values.]



-- JonL --