I must admit to a certain amount of interest, and also grim amusement, at this thread of discussion.
It seems to me that we have two issues afoot, here. One concerns programming style, and on this point, we may debate endlessly. The second concerns whether a language specification leads to unambigous compilation of a line of source code. On this point, the debate leads to a clearer result. The discussion blurs when one uses programming style to cover for problems in an ambiguous language specification. To approach the problem of compilation ambiguity by enforcing rules of style is really rather irresponsible. The language definition, and its compiler should never force one into this situation. I can write clear C/C++ code if I keep to a strict style, and as long as that style forbids the writing of code that is, well, code in itself, enigmatic enough to give any compiler of that language pause. Languages and their compilers ought not contribute to this sort of thing.
I personally have felt that that persistence of C/C++ is largely due to the fact that at some point, it became too expensive to switch (inasmuch as the language is almost impossible to mechanically translate to another, reliably, so that other choices become less and less feasible to contemplate), and the compilers for it have been fixed, and fixed again, and continue to be fixed some more, to the point where, when used together with a rigidly enforced style manual, one can (almost) stay out of trouble.
FWIW,
Mike
_____
From: Les May <zen53397{([at]})nowhere.xy
To: BLACKBOX{([at]})nowhere.xy
Sent: Wed, December 29, 2010 5:39:30 AM
Subject: [BLACKBOX] Seasons Greetings from Linuxland
Les May wrote
// z = x++ + ++y;
++y;
z = x + y;
x++;
But which forms best express what the program writer intended?
------------------------------------------------------------------------------------------------
Chris Burrows wrote
The original point made by Wirth was related to the problem of parsing:
x+++++y
It was your interpretation that it must have been intended to be:
z = x++ + ++y;
-----------------------------------------------------------------------------------------
I think that this rather reinforces the point I was trying to make. Wirth suggested that x+++++y is a riddle. More complex expressions make it difficult to understand what the program writer intended that the code should do. Parsing problems are not confined to mechanical parsers.
Even if we ignore the vagaries of the C compiler then neither the intention of the programmer nor the outcome of the expression
digdata[digNr] = (bitdata[bitNr++] * 8) + (bitdata[bitNr++] * 4) +
(bitdata[bitNr++] * 2) + (bitdata[bitNr++]);
is immediately obvious.
It could be made obvious by expanding it to
bitNr++;
digdata[digNr] = (bitdata[bitNr] * 8) + (bitdata[bitNr] * 4) +
(bitdata[bitNr] * 2) + (bitdata[bitNr]);
or to
digdata[digNr] = (bitdata[bitNr] * 8) + (bitdata[bitNr] * 4) +
(bitdata[bitNr] * 2) + (bitdata[bitNr]);
bitNr++;
depending on what the writer intended.
It also follows the convention that text is to be read from left to right and from top to bottom. This means that there are fewer intermediate results (e.g. bitNr++)
to be stored on the reader's 'mental stack' which I believe aids understanding. The line
RETURN (ch <= '9') & (ch >= '0');
does not because once the comparisons and boolean have been mentally evaluated what to do with the result is at the beginning of the line.
I don't think this is a problem confined to C. I believe it is a applicable to all languages. Programs give the wrong 'answer' when there is a difference between what the programmer intended the code the to do and what it actually does. This suggests that it is a good idea to make your intentions explicit when writing programs especially if you might have to maintain them.
Les May
---- To unsubscribe, send a message with body "SIGNOFF BLACKBOX" to LISTSERV{([at]})nowhere.xy
---- To unsubscribe, send a message with body "SIGNOFF BLACKBOX" to LISTSERV{([at]})nowhere.xy
Received on Thu Dec 30 2010 - 15:33:11 UTC