Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!wuarchive!psuvax1!psuvax1!schwartz
From: schwartz@psuvax1.cs.psu.edu (Scott Schwartz)
Newsgroups: comp.arch
Subject: Re: VLIW Architecture
Message-ID: <SCHWARTZ.89Oct6114801@psuvax1.cs.psu.edu>
Date: 6 Oct 89 16:48:01 GMT
References: <251FCB3F.12366@maccs.dcss.mcmaster.ca> <1050@m3.mfci.UUCP>
	<1632@l.cc.purdue.edu> <2311@munnari.oz.au>
Sender: news@psuvax1.cs.psu.edu
Organization: Pennsylvania State University, computer science
Lines: 23
In-Reply-To: ok@cs.mu.oz.au's message of 6 Oct 89 05:23:26 GMT

In article <2311@munnari.oz.au> ok@cs.mu.oz.au (Richard O'Keefe) writes:
   Herman Rubin writes:
   > I want
   > to be able even to introduce overloaded infix operators in addition to the
   > usual ones. Another feature missing from most languages since day 1 is to
   > allow the return of a list (NOT a struct).
   The reason that most languages don't return lists is precisely
   that they are designed to let the hardware show through, and you can't
   fit much in a register.

Isn't the idea to return out-parameters on the left side of an
assignment?  I.e.
	(out1, out2, out3) := foo (in1, in2, in3);
corresponds to
	procedure foo (in in1, in2, in3; out out1, out2, out3) 	...
	foo (in1, in2, in3, out1, out2, out3);

This doesn't seem that bad to me.  A byte full of syntactic
sugar helps the eyestrain go down. :-)

--
Scott Schwartz		<schwartz@shire.cs.psu.edu>
Now back to our regularly scheduled programming....