2 Jun
2007
2 Jun
'07
2:33 p.m.
On Sat, 2 Jun 2007, dwight elvey wrote:
Hi Dave
I'd expect it to evaluate the left side of the equation first before
determining the address. A[2]=1. Any other order would not make
sense.
It would to some compiler authors. (who sometimes have a different
reality than you and I do)
But that only goes to show how poor this type of
notation is for
defining sequence of execution. This is why I still think RPN notation
is much better for computer programming. This need not be a stack
language like Forth. It is concise. Events happen left to right. No special
rules. It isn't familar to what you learned in grade school but doesn't
take long to grasp.
Any completely defined language should produce the same results no matter
what is fed to the compilers. But, what about Y = X/0 ? In a simple
microcomputer implementation, howzbout
N = 32767; /*or 2147483647 (as used in MS-DOS file and partition size)*/
N = N + 1; ?
K&R was NOT a very rigid complete definition of the language. There were
many parts subject to choice or interpretation by the compiler author.
If you want to shoot yourself in the foot, C will provide you unlimited
large caliber ammunition.
Going back to the original post, . . .
in addition to real problems with compilers (such as mishandling of
scope), programmers will tend to claim bugs in the compiler whenever they
encounter different results than from their "baby duck" compiler.
Mine was FORTRAN, followed by APL, 1401 machine, 1401 SPS, BASIC, . . .
(and a real programmer can write a FORTRAN program in any language)
Without meaning to offend you, I'm going to guess that you started with
FORTH and then branched out. There does seem to be less potential for
ambiguity in a RPN language that has one operation per instruction.
(which is what makes machine language so fulfilling)
--
Grumpy Ol' Fred cisin at xenosoft.com