Xref: utzoo comp.arch:10620 comp.lang.misc:3071
Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!apple!sun-barr!newstop!sun!quintus!pds
From: pds@quintus.UUCP (Peter Schachte)
Newsgroups: comp.arch,comp.lang.misc
Subject: Re: Language Tenets (was Re: Double Width Integer Multiplication and Division
Message-ID: <1207@quintus.UUCP>
Date: 12 Jul 89 22:24:44 GMT
References: <57125@linus.UUCP> <1989Jun24.230056.27774@utzoo.uucp> <13946@haddock.ima.isc.com> <1388@l.cc.purdue.edu> <13961@haddock.ima.isc.com> <147@ssp1.idca.tds.philips.nl>
Reply-To: pds@quintus.UUCP (Peter Schachte)
Organization: Quintus Computer Systems, Inc.
Lines: 46

In article <147@ssp1.idca.tds.philips.nl> roelof@idca.tds.PHILIPS.nl (R. Vuurboom) writes:
>In article <13961@haddock.ima.isc.com> suitti@haddock.ima.isc.com (Stephen Uitti) writes:
>>Is there anything really evil with this:
>>	q = divrem(top, bottom, &remainder);
>Well, since you ask...yes.
>A basic language architectural tenet is that logical (semantic) grouping 
>should lead to syntactic grouping and vice verse. Any of the notations below 
>would satisfy this
>	q r  <- t/b
[followed with variations on this basic style]

There's a big problem with this:  you have an expression that's no good
for anything but putting on the right side of an assignment.  What good
are expressions if you can't nest them?

APL, as someone else pointed out, could handle this just fine, since you
would be returning an array instead of a scalar, and APL can handle
arrays very well (if I'm not mistaken, encode is exactly (a
generalization of) this quotient/remainder function).  And this sort of
thing would be ok in forth, since there's nothing wrong with leaving
more than one result on the stack.  But C (and Pascal, and Modula-2, and
most procedural languages) just aren't equipped to handle this.

All is not lost, though.  In C, you can have

	divrem(top, bottom, &quotient, &remainder)

and something similar is possible with VAR parameters in Pascal (and
Modula-2, I think).  This is symmetrical and reasonably elegant.  More
elegant, I think, than complicating a language with multiple value
expressions without adding enough power to do anything other than assign
them to something.

CommonLisp, you may point out, does have multiple returns.  In fact,
CommonLisp is a good example of the problem I'm pointing out.
Basically, there's not much you can do with a multiple-value expression
except ignore all but the first value (which happens if you nest a MV
expression within a function call) and assign its results to variables.

The problem here is not just syntax, it's the semantics of multiple
value returns.

-- 
-Peter Schachte
pds@quintus.uucp
...!sun!quintus!pds