Newsgroups: comp.lang.scheme
Path: cantaloupe.srv.cs.cmu.edu!bb3.andrew.cmu.edu!newsfeed.pitt.edu!dsinc!spool.mu.edu!news.sgi.com!news.msfc.nasa.gov!newsfeed.internetmci.com!athena.cytanet.com.cy!zeus.cc.ucy.ac.cy!01-newsfeed.univie.ac.at!02-newsfeed.univie.ac.at!newsfeed.uk.ibm.net!news.ibm.net.il!news.biu.ac.il!discus.technion.ac.il!news!qobi
From: qobi@eesun.technion.ac.il (Jeffrey Mark Siskind)
Subject: Re: multiple values
Reply-To: Qobi@EE.Technion.AC.IL
Organization: Technion, Israel Institute of Technology
Date: Wed, 31 Jul 1996 05:47:51 GMT
Message-ID: <QOBI.96Jul31084752@eesun.technion.ac.il>
In-Reply-To: gjr@hplgr2.hpl.hp.com's message of 26 Jul 1996 18:03:56 GMT
X-Nntp-Posting-Host: eesun.technion.ac.il
References: <QOBI.96Jul24212552@eesun.technion.ac.il>
	<GJR.96Jul26110356@hplgr2.hpl.hp.com>
Sender: news@discus.technion.ac.il (News system)
Lines: 49

In article <GJR.96Jul26110356@hplgr2.hpl.hp.com> gjr@hplgr2.hpl.hp.com (Guillermo (Bill) J. Rozas) writes:

   |   I think that the last point is very important. It is not that they are
   |   containers. It is that they are analogous to containers.

   But they can be.

So we are in agreement. Your proposal makes multiple values first class in
everyway except EQ?-ness. And you propose eliminating EQ?-ness as a means for
allowing unboxing. Such unboxing can be done even without eliminating EQ?-ness
by doing linearity analysis.

Independent of how you do unboxing, the issues of unboxing, EQ?-ness, and
linearity are more general, pervasive, and orthogonal to the issue of multiple
values. They apply to aggregate objects in general. Since the efficiency
benefits of multiple values are better handled in a more general way, and
because of the dubious value of the multiple value return constructs
themselves, I believe that there is no place for multiple value return
contructs in a properly designed language, except as syntact sugar that is
part of a more general structuring/destructuring facility.

   |
   |   (multiple-value-bind (la lb lc) (line p3x p3y p4x p4y)
   |    (multiple-value-bind (rx ry rtheta) (ray p1x p1y p2x p2y)
   |     (intersection-ray-line rx ry rtheta la lb lc)))

   This is bad coding practice _whether_ multiple values are containers
   or not.

This was precisely my point.

   Even if multiple values are ordinary containers, I would expect people
   to use some destructuring sugar.  Whether you call this MULTIPLE-VALUE-BIND
   or destructuring-let (or extend LET's syntax) the issue is the same.

   When you wrote this code, you chose a complicated interface with
   insufficient abstraction, and this came back to bite you.

What better kind of interface would you suggest that I use? I contend that
with the conventional semantics for multiple values, there is no better
interface possible (short of writing your own compiler for conventional
expression notation and having that compiler do the boxing/unboxing
automatically). And I contend that the proper interface/abstraction is the
conventional expression-oriented formulation that I included in my original
post which treated the semantically-related multiple values as aggregate
objects.
-- 

    Jeff (home page http://tochna.technion.ac.il/~qobi)
