Xref: utzoo comp.arch:10535 comp.lang.misc:3047
Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!csd4.milw.wisc.edu!cs.utexas.edu!uunet!mcvax!hp4nl!philapd!ssp1!roelof
From: roelof@idca.tds.PHILIPS.nl (R. Vuurboom)
Newsgroups: comp.arch,comp.lang.misc
Subject: Re: Language Tenets (was Re: Double Width Integer Multiplication and Division
Message-ID: <147@ssp1.idca.tds.philips.nl>
Date: 7 Jul 89 16:37:11 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>
Organization: Philips Telecommunication and Data Systems, The Netherlands
Lines: 79

In article <13961@haddock.ima.isc.com> suitti@haddock.ima.isc.com (Stephen Uitti) writes:
[>> Herman Rubin writes]
>
>Is there anything really evil with this:
>	q = divrem(top, bottom, &remainder);

Well, since you ask...yes.
A cardinal sin that a language can commit is being incapable of expressing
a relevant concept adequately.

In this case we are acting on one pair of concepts (top,bottom) to produce
values for another pair of concepts (quotient,remainder). What we need here
is the capability of expressing _adequately_ (read elegantly) the idea
of acting on one concept pair to generate values for a second concept pair.

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
	[q,r] = t/b
	t b / => q r
	/t,b/ >>  (q,r)

However
	q <- t/b r
doesn't. Confer quotient = div(top,bottem,&remainder)


Lest you consider this some quaint academic hand waving I will hasten to 
point out that this problem trundles straight down into your implementation.

For this I'll pull out my second language architectural tenet and that is:

evaluation (interpretation so you desire) should follow syntactic grouping.

The syntactic expression  q r <- t/b   does not obligate nor disallow
parallel evaluation of q and r. If the underlying implementation
(computer architecture) allows simultaneous calculation with attendant
efficiencies all the better.

On the other hand the syntactic expression q <- t/b r obligates a
prior calculation of t b and r before that of q. (I'm assuming non-lazy
evaluation here). Even if the implementation can parallelize the
calculation of q and r the language specification ought to specify
a partial ordering (viz first t/b and r then q).

The implementation could in fact parallelize (as you point out) but _only_ 
if the end result is not differentiable from the partially ordered evaluation.

But if the language _relies_ on such a parallelization I would consider it
broken.


>>Since the hardware allows simple things like this [viz parallel evaluation],
the language should [support this].
>
>The language does.  It just doesn't allow you to do it with the
>syntax you want. 

The _language_ doesn't. Because it can't group the concepts correctly.

>OK, so the terminology for C is a little broken.  I've used

Not terminology ...syntax. And perhaps inadequate is more accurate than
broken.

>languages that have (for example) German words for keywords.
>That didn't mean that i felt the need to change the language's
>syntax or terminology.
>
Fortunately, (some) others do. Developing adequate expression to
enable clear, concise, complete and _relevant_ conceptualization has 
always been a major breakthrough in any intellectual endeavour.

Anyway weren't most of our parents onto us about not using bad language? :-)
-- 
Roelof Vuurboom  SSP/V3   Philips TDS Apeldoorn, The Netherlands   +31 55 432226
domain: roelof@idca.tds.philips.nl             uucp:  ...!mcvax!philapd!roelof