"for" loops in C ...

[Chris Torek]

In article <342 at igor.Rational.COM> dsb at Rational.COM (David S. Bakin) writes:
>Well I've read several responses to my innocent and IMHO reasonable 
>"assertion" that C's << operator was a left shift.  All pointed out
>that it is a machine-dependent left shift and deliberately so in the
>name of efficiency.
>
>This means two things to me.  First, I have to reread the C manuals
>I have verrry carefully.  And second, my original opinion was right:
>C is no more than an assembly language with extra whitespace and
>slower language translators.  :-)

To some extent, yes.  But this is true of most languages.  There are
remarkably few languages in which `*' (or whatever the local symbol may
be) *really* means `multiply', for instance.  It usually means `choose
the appropriate MUL instruction/subroutine and let the chips fly where
they may'---often into the bit bucket.  There are a number of languages
where

	for i:integer from 0 to 60000 do ... rof

runs forever on a 16-bit machine.  This deviation from the
`mathematically proper' behaviour is virtually always done for
`efficiency'.  There is often some attempt at allowing runtime error
checking (via, e.g., exceptions), but it is also often weak (which
arithmetic exceptions are *guaranteed* in Ada? PL/I?).

There *are* languages in which `*' really means `multiply'.  One of
these is even old enough for most people to have heard of it :-)
---Lisp.  If you multiply big numbers, you get back a bignum, not an
overflow.  If you shift n left s, you get n times two-sup-s.  You also
pay a penalty in efficiency---so much so that the local Lisp dialect
usually provides an `I think this cannot overflow so use the MUL
instruction' variant.  Type-inferencing (and range-inferencing)
languages or compilers sometimes do this for you in `safe' ways.  More
of these sorts of languages are appearing all the time.  These are
the real `high level' languages.  They are still largely pure research
vehicles.

Languages of the other sort, including C, Pascal, Modula, FORTRAN,
etc., are designed as a compromise between `what the machine really
does' and `what abstractions programmers would like the machine to
do'.  The real differences between `low' and `high' level languages are
not in their syntaxes, but rather in how well they insulate the
programmer from the shocks found down on the bare metal.  The
insulation is sometimes quite thin, and it is your job as a programmer
to know exactly where and how much.  When you said:

>... I have to reread the C manuals I have verrry carefully.

you were right.  You should have done that earlier (but with the dpANS
you will have to do it again anyway---some of that insulation has been
moved around).

If you write anything more than toy programs, know your languages'
weak spots.
-- 
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163)
Domain:	chris at mimsy.umd.edu	Path:	uunet!mimsy!chris