World: r4wp

Thanks, I'll fix that. Originally it was HTML entities, but something 
about CC's update process converts those entities to their original 
characters, which corrupted the code examples. I started using blah 
before I switched to bang.

This is something that surprises me:

system/version ; == 2.100.111.3.1
for i 1 2 0 [prin "x"] ; == none (I am OK with this)

for i 2 1 0 [prin "x"] ; xxxx..... (this does not look compatible 
with the above)

Yeah, that looks like a bug. Write a ticket?

And a step of 0 makes it not run and return none, instead of triggering 
an error? Is that right?

Yes, but I do not object against that (no problem with me)

Does somebody have other preferences?

I'm OK with that, since the alternative is either an endless loop 
or conditional code to avoid error trapping. But it needs to make 
sense conceptually.

Oh, and please don't be bug-for-bug compatible in your R2 version. 
If you find bugs in R3's version, let's report and fix them, now's 
the time :)

Another test:

for i 1 1 0 [prin "x"] ; xxxx.....

If we define the FOR function with a special-case that a step of 
0 will definitely not make the loop run, and have the function return 
none, that makes for some simple tests to add to rebol-tests. Just 
have it break/return something other than none in the code block. 
Like this:
[none? for i 1 1 0 [break/return 1]]
[none? for i 1 2 0 [break/return 1]]
[none? for i 2 1 0 [break/return 1]]
... maybe.

Yes, I am OK with that

none? for i 1 1 0 [break]

looks sufficient as well

Good.

FOREACH triggers an error in that case, the case of the empty word 
block.

Should we be consistent?

I thoguht I did a FOR compatible wrapper for CFOR at one time, but 
I can't find it right now.

Is that along the lines of what you're thinking Ladislav?

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