Using current CVS version, the following loop prints only two values of n:
do for [n = 1:10] {
if (n < 3) k = 1;
print n
}
It seems like, depending on the outcome of the test in the if clause (and whether there is an else clause or not), the loop iterates without executing the remaining statements below the test. See also the attached script for various test cases.
Also tested with CVS as of 2011-07-11, ie. before the nested iteration patch by Peter Juhasz.
test cases
In fact, the effect of the old-style "if" clause is not exclusive to "do for" loops: the same happens with "while" loops, with even worse consequences:
n = 1
while (n < 10) {
if (n < 3) k = 1
print n
n = n+1
}
This causes an infinite loop, because the n = n + 1 line doesn't get executed after the "if" condition becomes false.
The old-style if/then syntax is not compatible with the new bracket-delineated block structure commands. It does say this in the manual, altough perhaps it needs to be stated more prominently. Where would you suggest?
gnuplot> help if
[...snip...]
The old single-line if/else syntax is still supported, but should not be
mixed with the new block-structured syntax. See `if-old`.
If the old-style "if" really cannot be made compatible with {} blocks, is there a way to make the parser issue a warning?
In the documentation, a hint and a link to 'if' in the 'Do' and 'While' sections would be helpful.
Btw. these new features are great!
A possible hack: in the function that processes the "if" command, check for the "{" character, and if none is found, insert one artificially. Then insert a closing "}" at the end of the command line or before the "else" if there is one. Then proceed as if the new-style "if" syntax were used.
Processing an old-style "if" is no problem if a { has not yet been encountered. It's the opposite ordering that doesn't work.
The problem is this:
When a { is encountered, input is accumulated onto a single extended line until the matching } is read in. Any old-style if/them clauses have thus become embedded into a single very long command line. But the old-style syntax is based on the if/then clause extending all the way to the end of the current command line. So as it stands, by the time the program has read in a {...} clause it is no longer possible to parse old-style if statements.
Added stronger warnings to the documentation.
The program now issues an error message if the old-style syntax is encountered inside a bracketed clause.