Xref: utzoo comp.arch:10627 comp.lang.misc:3073
Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!rutgers!iuvax!purdue!mentor.cc.purdue.edu!l.cc.purdue.edu!cik
From: cik@l.cc.purdue.edu (Herman Rubin)
Newsgroups: comp.arch,comp.lang.misc
Subject: Re: Language Tenets (was Re: Double Width Integer Multiplication and Division
Summary: Some find it useful
Message-ID: <1406@l.cc.purdue.edu>
Date: 13 Jul 89 13:34:52 GMT
References: <57125@linus.UUCP> <1989Jun24.230056.27774@utzoo.uucp> <1207@quintus.UUCP>
Followup-To: comp.lang.misc
Organization: Purdue University Statistics Department
Lines: 62

In article <1207@quintus.UUCP>, pds@quintus.UUCP (Peter Schachte) writes:
> 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]

Even without architecture, I agree with it as a matter of language.  The
idea of a replacement statement is that the quantities being replaced are
determined by the arguments for the expression, which are not themselves
changed except by the replacement.  We sometimes allow address modification,
etc., to go on, but these are side effects to be used with caution.

What is so difficult about the idea that a process can have several results?

> 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?

That YOU cannot see a use for them is irrelevant at best.  Enough people
have posted that they can see a use for this aspect of computer language
to include it.  I will not object to your including something in the
language which I might not think even appropriate.

			.....................

>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.

There are times for elegance and times not to have elegance.  I will not
use an elegant definition if it obscures the concept.  I will not use a
short elegant proof, in general, if the understanding of the theorem is
compromised.  I will use a short computational procedure, however, because
in computation, time is the major issue.


> 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.

More than that can be done.  Results can be assigned to registers.  Not
having nesting would, to me, be a minor inconvenience.  Not having 
multiple values returned can be a major slowing down of the computational
procedure.

> The problem here is not just syntax, it's the semantics of multiple
> value returns.
> 
So there are some things one cannot do with strings of values.  I can
even think of situations where the string is just what I want to pass
to the next stage.
-- 
Herman Rubin, Dept. of Statistics, Purdue Univ., West Lafayette IN47907
Phone: (317)494-6054
hrubin@l.cc.purdue.edu (Internet, bitnet, UUCP)