World: r4wp

Being at it, this looks OK:

for i [1 2] 1 1 [prin mold i] ; [1 2]

this looks OK as well:

for i [1 2] 2 1 [prin mold i] ; [1 2] [2]

this too:

for i [1 2] 3 1 [prin mold i] ; [1 2][2][]

however, this looks arguable:

for i [1 2] 4 1 [prin mold i] ; [1 2][2][]

Is that along the lines of what you're thinking Ladislav?
 - yes, more or less

(I did not intend to use CFOR, wanted to make it "standalone")

I think mine used it, but I agree that standalone is better, and 
won't be any harder in this case.

Do either of you (Brian or Ladislav) know if there's a good FOR test 
suite in the REBOL base?

There are some tests in the core-tests suite (28 in total), but as 
you can see, there are many properties that aren't tested yet.

Thanks, cloned and found them.

I gave the

    for i 1 2 0 [prin "x"]


a second thought, and the fact is that the "forever" functionality 
looks legitimate as well. Thus, it would be best if we made a user 
poll to find out what is preferred. Whether looping forever or not 
looping at all. So, please, let us know what do you prefer.

Alternatives are:


1) for i 1 2 [prin "x"] loops forever printing "infinite" string 
xxx....
2) for i 1 2 [prin "x"] does not loop at all yielding none

Consistently, we want to see the same behaviour when encountering

for i 2 1 0 [prin "x"]

or

for i 1 1 0 [prin "x"]

Pekr, I hope that you do express your preference as well.

shouldn't a for loop run at least once, and then on the next run 
check to see if limits are exceeded?

That is a matter of preferences as well (at least IMO). You can have 
such preference and express it, but another legitimate wish is for 
this case:

    for i 2 1 1 [prin "x"]

to not run at all yielding #[none] as it currently does in R3

So, Graham, I did not understand your question as an expression of 
your preferences. So, you still have an oportunity to express what 
your preferences are.

well, I can imagine more scenarios, and it needs some thought to 
stay consistent between the cases. So my first thoughts, starting 
with the latest example:

for i 2 1 1 [prin "x"]


If above scenario means returning #none (and I agree with that), 
then I think that the for i 1 2 0 [print "x"] could be just the same. 
But - it might be related to the thoughts of the indexing. In REBOL 
series (if I am right), the position is in between the elements (not 
on the first element). So in that regards, skip 0 moves nowhere. 
But - it might also mean (as "first series" returns first element), 
that it should perform the loop just once. 


The last option for me is to cause an infinite loop, although from 
some point of view, it might make some sense too - you simply want 
to traverse the range, from 1 to 2, but you skip 0. If you would 
use just 'skip, you would cause an infinite loop. So - I really don't 
know ....

Well, I do not require you to invent or justify how it should work. 
I think that it really may be just a matter of preference. So, you 
just need to tell what it is you would find the most convenient behaviour 
when writing the

    for i 1 2 0 [prin "x"]

in your code.

Of course, there is an option that you just do not mind, since you 
do not intend to write such an expression at all.

(actually, in that case you might prefer the interpreter to cause 
an error for you to inform you that you did something you did not 
intend to do)

I prefer at least one execution.  If 0 is the loop increment, then 
it is a forever loop unless the loop parameters are also both 0

Thanks, Graham, counted.

so for i 0 0 0 [ .. executes only once ]

Aha, hmm, that is a problem. If

    for i 1 2 0 [prin "x"]

loops forever, I would expect that e.g.

    for i 1 1 0 [prin "x"]

behaves exactly the same way looping forever as well.

execute once, increment the loop counter and then check it against 
the upper bounds.

Yes, but it is in the bounds still.

so, in the first instance it's forever, the second is just once

You cannot get out of bounds adding 0.

>= to the upper bound

so that would be two iterations

hmm.. what happens with negative increments

so that would be two iterations
 - if I understand it well that looks like a preference shift.

execute once, increment counter from start, if counter is <= outer 
bound execute again.  if counter is now >= outer bound exit

we are allowed to alter the counter value inside the loop right?

if counter is now >= outer bound exit

 - however, that requires to use two distinct tests for iterations 
  (in the first case the upper bound is included in the range since 
 upper-bound <= upper-bound, while in the second test the upper bound 
 is excluded from the range since upper-bound >= upper-bound)

that would allow us to break out of a forever loop

Yes, we are:

* allowed to use BREAK
* allowed to change the cycle variable inside the body

So, a forever loop is not a problem when you do not think it is a 
problem

Regarding the negative bump versus the positive bump:


* I tend to think that the set of integers specified by start-bound 
1 end-bound 3 and bump 1 to contain the numbers [1 2 3] 

* I tend to think that the set of integers specified by start-bound 
3 end-bound 1 and bump -1 to contain the numbers [3 2 1]

* judged this way the set of integers specified by start-bound 1 
end-bound 3 and bump 0 may be considered
** incorrectly specified (cause error)

** empty since it does not specify correctly a nonempty set of integer 
numbers (do not loop)
** it may be specially defined as [1 2 3] (infinite loop)


Choosing an alternative of the above three I consider just a matter 
of preference.

In many other languages it leads to infinite loop.

It looks like (on R3) it checks the upper bound if the bump value 
is positive, lower bound if the bump value if negative
AND if the bound value can be reachable with the bump value.

for i 5 3 0  [i: 2 print i] ;==2, stop
for i 5 3 0  [i: 6 print i] ;==6, infinit

this is not consistent with 
>> for i 3 5 0  [i: 6 print i] ;== none
>> for i 3 5 0  [i: 2 print i] ;== none

Yes, that is the inconsistency described above.

in the first example, it checks the right-bound-value.

So if the bump value is zero, then it should check;
* always the right-bound
* or the lower one.

>> for i 5 5 0  [i: 2 print i] ;==2, stop.

I mean "decide the direction by looking at the bounds" then "check 
the bump value, if it is possible to reach that bound value (check 
the direction of bump value)"

if it is not reachable, return none without executing the block.

This can cover all the possibilties, pos., neg. or zero bump value.

I understand you, and youi gave some inspiration, but you used some 
terms that may be rather confusing:

right bound
 - did you mean the END value?
lower bound
 - did you mean the START value or the minimum of START and END?

Yes that was what I mean, sorry, English is not my main language, 
so it is a bit difficult what I exactly mean.

No problem, I just wanted to make sure.

this still leaves an uncertainty whether we want to handle the situation 
of

    for i 1 2 0

the same as

    for i 1 1 0