note 56062 rejected from language.control-structures by bjori

Note Submitter: kit dot lester at lycos doc co dot uk ---- There seems to be some abivalence thoughout the manual between the terms "command" and "statement" - they seem to be used interchangably to mean pretty much the same thing. I find the switching between the terms confusing, making the manual's meaning rather uncertain. I prefer "command" - it's clearer to novice programmers. [The term "statement" is a relic of the early muddled thinking of the late 1950s, when the first programming languages were being defined: it seems time we dragged the jargon into the 1960s?] The first paragraph of this page (after the list) seems to define "statement", but leaves out such as "echo" which isn't a function call because one can omit the round-brackets (the manual section on echo calls it a "construct", but then expressions are also said to be "constructs", so presumbly "construct" isn't intended as a third synonym for "statement/command"). That definition of "statement" in the first paragraph also omits other things that the interpreter happily accepts in statement/command contexts - e.g. * calls of phpinfo() [which is also described as a "construct"], and * any form of expression other than assignments and function calls - this leaves out "commands" such as "$i++;", calls of the execution operator (which might not have useful results, and so can reasonably be used followed by semicolon as a statement/command) - tests of those and others suggest that like C/C++/JavaScript (but unlike Java) **any** PHP expression can be used in a statement context, with the result being "voided" (as the C & C++ standards term it - meaning that the result is thrown away, the expression effectively being cast to the "void" type of those languages.) Amazingly, the definition of "statement" even manges to leave out the loops - but combinations such as if (...) while (...) ... clearly work, which makes the while the controlled statement/command of the if. Mercifully, the definition does include the null/empty statement - but the searcher finds only this use of "empty statement", and none of "empty command", "null statement" or "null command", so (e.g.) there's no place for any warning about the danger of unintended null statements - i.e. of writing such as if(...); statement - which is a common mistake by novices who've been told to put a semicolon after what sounds like pretty much everything - and after that's been sorted, the next lesson then includes blocks so our novice then writes if(...) { statements }; else... which is nightmare confusing because the error message is on the "else" - not at the actual place of the error... Or perhaps the "can be" at the start of the definition means it's only intended as a quick reminder, not as a definition: but the list that follows is then too complete for a reminder, yet not complete enough for a definition. The title of the page - "Control *Constructs*" seems to be ducking the statement/command ambivalence. Finally, the include/require entries at the end of the list don't affect the order in which things are obeyed, so I don't see how they rate as *control* constructs. All this leaves me very uncertain. I'd expect these slight blurrings in a tutorial - where being too precise too early is likely to overload learners - but such apparent differences in a reference manual COULD mean that there's some subtlety that I'm missing. In summary - there's something not quite right here (either conflicts and gaps; OR something buried rather deep). Other readers - beware! </rant>