🚀 go-pugleaf

[Good contributions from, inter alia, cik@l.cc.purdue.edu (Herman Rubin),
pds@quintus.UUCP (Peter Schachte), roelof@idca.tds.PHILIPS.nl (R. Vuurboom),
and suitti@haddock.ima.isc.com (Stephen Uitti) on the problem of "q r <- t/b".]

I think there are several issues here, which are in danger of confusing
each other.

   (a)  Is it a language deficiency if "q r <- t/b" cannot be sensibly
written?  Answer:  yes.  Solutions on the lines of

		q = t/b; r = t%b; /* "and the optimiser should tidy up" */

are inadequate because I might want to write

		records[i++] errcount <- write(fd,buf,BIGBSIZE)/BSIZE

after which

		records[i++] = write(fd,buf,BIGBSIZE)/BSIZE;
		errcount = write(fd,buf,BIGBSIZE)%BSIZE;

is erroneous and

		{ int temp = write(fd,buf,BIGBSIZE);
		  records[i++] = temp / BSIZE;
		  errcount = temp % BSIZE; }

is becoming gross (and much harder to optimise).

   (b)  Should all possible machine-code short-cuts be expressible within
the language?  Answer:  yes.  "asm" and its relatives almost provide the
solution here.  I know of several quite old languages in which the embedded
machine code could include expressions, provided that certain restrictions
were observed.	 Where it matters, there are ways of making this portable.

   (c)  Should languages permit "functions with several results"?  Answer:
I don't know what the question means, but the answer is yes.  In languages
that are (as part of their definition) stack-based, it's very natural for a
function to push several objects onto the stack.  For more traditional
languages, it's harder to see how the function can be defined sensibly
unless the objects are grouped in some way;  but it is clearly a language
deficiency if structures and arrays (as well as pointers thereto) cannot be
returned from functions.  Many popular languages are defective in this way;
some are not.

   (d)  How should "q r <- t/b" actually be written?  Answer:  form should
follow function.  Reasonably, the right-hand side should be either a library
function (presumably inlined for efficiency) or, equivalently, an infix
operator:  "divrem (t, b)" or "t DIVREM b", according to taste.  The problem
is with the left-hand side.  Unless I've missed a trick, I don't think
there is any way in either C or Algol [my arbitors of taste in such matters!]
of bundling up "q" and "r" into an appropriate "lvalue".  That is, there is
no way of defining "bundle" in Algol (for example) such that

		bundle (q, r) := t DIVREM b

can assign sensibly to "q" and "r".  It's easy, and left as an exercise for
the reader [:-)], to define in Algol an operator "ASSIGN" such that

		bundle (q, r) ASSIGN t DIVREM b

does the right thing, but it's not looking quite so nice.  There are other
solutions, but they start looking like the `evil' "q = divrem (t, b, &r)".
Note that CPL would have permitted

		q, r := t/b, t%b

from which

		q, r := t DIVREM b

is quite a small step, and well within the Algol/Pascal/C tradition.

-- 
Andy Walker, Maths Dept., Nott'm Univ., UK.
anw@maths.nott.ac.uk