Re: unexpected behavior of "do for"

[<pl...@pi...>]

On 03/05/12 20:24, Ethan A Merritt wrote:
> Tait<gnu...@t4...>  wrote>
>>> So yes, there is an inconsistency.  There are currently three "for"
>>> constructs
>>>    do for
>>>    set for
>>>    plot for
>>>
>>> The first two of these always iterate at least once; the third one does not.
>>> The documentation is silent on the intended behavior.
>>> So which to change, "plot for" or both the others?
>>
>> Given that it's called "for" I'd say the principle of least surprise
>> dictate that it act consistently with "for" as used in most programming
>> languages (e.g. C).
>
> Well, C doesn't really have an automatic iterator of this form; you have to
> provide an explicit initialization, an explicit while condition, and an
> explicit iteration operation.
>
> It turns out to be surprisingly hard to determine what
> "most programming languages" do. Many require an explicit increment
> operation, like C.
>
> FWIW, here is what you get in R, whose syntax is close to that of gnuplot.
>
> R>   for (i in 4:1) { print(i) }
> [1] 4
> [1] 3
> [1] 2
> [1] 1
>
> So that's a third option to consider.
> It's not too late to consider adopting this behavior for gnuplot also:
>     for [i = start : end {: increment}]
> where increment defaults to -1 if (start>  end) and +1 otherwise.
>
> 	Ethan
>

Hi,

The R example is rather artificial. It is not the 'for' structure that 
automatically takes a negative increment. That is the result of the 
definition of the "range"  4:1 , which rightly defines a series 4 3 2 1 
, that is unique and unambiguous.

In this context the for-loop simply iterates a predetermined list , the 
loop increment is still +1 .


The idea that way the code is compiled varies dependant on the values of 
the data seems an aberration to me.  This sort of thing should be 
reserved for AI languages.

Perhaps someone could suggest how this would be advantageous.

If it is truly useful perhaps the idea of a range as a variable 
structure needs to implemented as in R. Though this would probably lead 
to an ambiguous syntax in for-loops which would have to have alternative 
code paths for conventional integer args and ranges.


Peter.