Newsgroups: comp.lang.scheme
Path: cantaloupe.srv.cs.cmu.edu!das-news2.harvard.edu!news2.near.net!news.mathworks.com!europa.eng.gtefsd.com!news.umbc.edu!haven.umd.edu!purdue!news.cs.indiana.edu!dyb@cs.indiana.edu
From: "R. Kent Dybvig" <dyb@cs.indiana.edu>
Subject: Re: giving up (Was: Re: Explanation about call-with-values)
Message-ID: <1995Jan29.222433.21858@news.cs.indiana.edu>
Organization: Computer Science, Indiana University
References: <BLUME.95Jan22133847@dynamic.cs.princeton.edu> <3g004e$7ps@nkosi.well.com> 	<BLUME.95Jan23140314@dynamic.cs.princeton.edu> 	<3g67ne$e4e@narnia.ccs.neu.edu> 	<BLUME.95Jan25165400@atomic.cs.princeton.edu> 	<1995Jan26.174431.9717@news.cs.indiana.edu> <BLUME.95Jan27114524@atomic.cs.princeton.edu>
Date: Sun, 29 Jan 1995 22:24:30 -0500
Lines: 68

blume@atomic.cs.princeton.edu (Matthias Blume) writes:

>This whole discussion shows that multiple values are not just a
>straight-forward extension to single values.  They are something
>conceptually different.  They are containers!  As a matter of fact, I
>would prefer (eq? (values 2) 2) to be #f, just like (eq? (list 2) 2)
>is #f. 

But in fact they are not containers.  There is no more a container for
multiple than for single return values, just as there is no more a
container for multiple than for single arguments.  This is a point that
you seem to have missed all along, and in missing it you have convinced
yourself that multiple values are conceptually different from single
values, even though we can write a cps conversion or denotational
semantics (such as the one in the revised report) that shows that they
are no more different than are multiple arguments from single arguments.

>   Arguments
>   don't come in first-class containers, although the syntax of lambda
>   allows us to put them in one (a list).  And as you point out you can do
>   the same thing with call-with-values (and with macros, you can make
>   doing so very concise).

>Actually, I would like to have all functions take just exactly one
>argument.  If you want to pass more, then pass a container!  (Witness SML!)
>This would make things symmetrical, and it would also settle your
>complaint about list/apply not properly taking care of call/cc's behavior.

So you would like multiple return values to be packaged in a container
of some sort, and you would like the same for multiple arguments.  I
don't like the idea, and in fact think it goes in exactly the wrong
direction for reasons I don't care to enumerate right now.  (Some of my
reasons were given in a September 1990 LASC article Bob Hieb and I
wrote, called ``A new approach to procedures with variable arity'', in
which we proposed an alternative to the current Scheme "rest" interface
and, incidentally, a different multiple return values interface that I
still prefer.)  Regardless, we aren't going to change the language to
eliminate multiple-argument procedures (or the list-based rest
interface, for that matter), and the containerless multiple return
values of the call-with-values/values interface is symmetric with the
containerless multiple argument values.

>Sometimes I might want to say:

>	(call/cc
>	  (lambda (k)
>	    (let ((r (f ...)))
>	      <do something else>
>              (if (panic? ...) (k r))
>              <do even more>
>              r)))

>I.e., I want to capture the return value(s) of the call to `f' and
>pass them on to my continuation, and this should look the same no
>matter whether my continuation takes one or many (or no) values.

This is trivially accomplished with call-with-values and values:

  (call/cc
    (lambda (k)
      (let ((r (call-with-values (lambda () (f ...)) list)))
         <do something else>
         (if (panic? ...) (apply k r))
         <do even more>
         (apply values r))))

This isn't quite as concise, but then in my experience it isn't often
necessary to do this.
