Newsgroups: comp.lang.scheme
Path: cantaloupe.srv.cs.cmu.edu!das-news2.harvard.edu!fas-news.harvard.edu!newspump.wustl.edu!news.starnet.net!wupost!howland.reston.ans.net!ix.netcom.com!netcom.com!NewsWatcher!user
From: hbaker@netcom.com (Henry Baker)
Subject: Re: multiple-value return & optimising compilers
Message-ID: <hbaker-0602951001510001@192.0.2.1>
Sender: hbaker@netcom.com (Henry G. Baker)
Organization: nil
References: <dig-Scheme-7.26@mc.lcs.mit.edu> <9501310741.AA25479@clark.lcs.mit.edu> <QOBI.95Jan31210942@qobi.ai> <3h3l87$3su@cat.cis.Brown.EDU>
Date: Mon, 6 Feb 1995 17:59:18 GMT
Lines: 38

In article <3h3l87$3su@cat.cis.Brown.EDU>, mj@cs.brown.edu (Mark Johnson) wrote:

> I think that Jeff Sisskind makes an extremely perceptive point when he
> notes that almost always the multiple values returned by
> multiply-valued procedures are semantically related.  In fact, in
> the application he describes they form structured entities.
> 
> My question is this: instead of having the `generic' containers
> William Clinger (sp?) speaks of, could we have user-declared `named'
> structures or tuples (which could be defined with either a local or
> global scope), and still achieve the desired performance enhancements?
> 
> (I am rather doubtful about the semantic enhancements; as someone else
> pointed out, multi-argument functions can be regarded merely as a
> syntactic sugaring (Currying) of single-argument functions, but the
> same is not true for multiple return values).
> 
> Returning to my proposal to use structures rather than just generic
> containers: I agree that this is moving more in the direction of a
> typed language, but isn't this what Sisskind's example (and my
> own experience agrees) suggests is really necessary?

The major problem with making return multiple-values structures first-class
is that most people throw out the baby with the bath-water by making
real Smalltalk-like objects out of these things.  This is wrong.

Such structures should be _extensional_, meaning that they are not
mutable objects.

Such structures should be trivial product types, meaning that their
type is compared by _structure_, not by _name_ (i.e., C rules rather than
Ada rules).

Such structures should be efficient -- i.e., most implementations via
cons (or equivalent) don't cut it.

See ftp://ftp.netcom.com/pub/hb/hbaker/ObjectIdentity.html (also .ps.Z) for
more discussion.
