World: r4wp

Then start-vs-end sets the direction, and bump sets the velocity. 
It's just a way to explain *why* to newbiees.

Dealing with the consequences of triggering an error is more expensive, 
so we tend to only want to trigger errors when they really *are* 
errors. If there is a plausible way to just do nothing and/or return 
none when it's not potentially damaging, we should come up with a 
rationale that lets do that instead.

You can say that you "support" zero velocity by "not looping", but, 
in fact, you rather don't support it by failing as silently as possible.

It's really a rationale.

No problem to say it is "zero velocity". The problem is that in "normal 
life" something having zero velocity does not "vanish", rather it 
stays where it is.

So you may be caught as using "inappropriate logic", but I do not 
mind, being able to eventually answer that it is an exceptional case 
that you simply did not want to handle to not cause headaches to 
some users, while causing inconveniences to people being able to 
calculate what it is they should have expected.

We can just arbitrarily declare that we want 0 velocity to be considered 
out of range, as a favor to the developer, and the velocity explanation 
gives us a good excuse to not trigger an error. FOREVER existing 
means that they have other options, and index setting means that 
they can do whatever they want if they really want to, so it's not 
actually a constraint if they don't want it to be.

You can always declare something arbitrarily. The problem is that 
if you do declare a + b = none in case a = 0 you are most probably 
causing inconveniences to all people knowing that there might have 
been a more consistent behaviour...

Remember, #864 is a proposal to replace FOR with a more flexible 
power-user function that would be less safe to use. They lose some 
safety as a tradeoff for more power and prettier sytnax. So, they 
lose two features (safety and backwards compatibility) but gain more 
flexibility. The greater flexibility would come at the expense of 
a slower function: negligably in the case of the function itself, 
but more when you add the conditional wrapper code, so it would have 
to be used carefully if you want it to be efficient. Overall, that 
is the R3 motto right there: R2 is for newbies, R3 for power users.

But let's just forget about it in this specific case. I guess that 
FOR is not expected to be used extensively anyway.

So, I would recommend that the #1993 restrictions against accidental 
infinite loops should go into R3/Backwards and rebol-patches, because 
R2 is for newbies. And I would recommend that #864 be the new FOR 
for R3 and R2/Forward, because R3 is for power users.

Man, you guys are typing faster than I'm reading. :-)

LOL

the best you can do is to cause an error when finding out that

 
   all [start = end bump = 0]

is TRUE, since in that case there 
is no reasonable terminating condition that could not cause infinite 
loop by default.


I think this answers what I was asking. Though it seems that Ladislav 
wants [1 1 0] to be infinite for consistency, while Biran and I want 
it not to be, for perceived user friendliness. :-)

Brian, for that case, does your model make it a "no loop" or "once 
only" condition?

Gregg, we just agreed to make it "no-loop"

OK, I skimmed too fast. Thanks.

(which is "the most silent failure")

once only

 would be rather inconsistent with any terminating condition, because 
 there is none that could cause it to loop exactly once

Updting %new-loop.r now.

Posted %mezz/new-loop.r

Gress, for the start-vs-end-sets-direction bump-is-velocity model:

* start=end means no direction so just loop until the =end termination 
condition is met and ignore bump. If the index gets changed in the 
body block, let the =end termination condition handle it.

* start<end means positive direction, for values of "positive" that 
don't include 0, so bump <= 0 is out of range, meaning no loop. The 
termination condition *if we start looping* is >= end.

* start>end means negative direction, for values of "negative" that 
don't include 0, so bump >= 0 is out of range, meaning no loop. The 
termination condition *if we start looping* is >= start.


Positive and negative directions don't include 0 because if the developer 
wanted to do an infinite loop they would have used FOREVER or R3's 
#864 FOR general loop. R2 was aimed at newbies, and they need extra 
coddling.

Gress -> Gregg

For the bump-sets-direction start-and-end-set-the-range model, 0 
doesn't set a direction so it should trigger an error. Otherwise, 
the same.

Brian, can you point out which test case is incorrect, and what it 
should produce? That way we can match against Ladislav's examples.

I like the model that doesn't trigger an error.

And I tested %new-loop.r only under R2, not R3, just in case.

Test cases for the first model, just using literal numbers as metaphors 
for the principles:
; start = end, start is not constrained, termination is x = end
[i: 0 1 = for x 5 5 1 [if i >= 1 [break/return 'fail] i: i + 1]]
[i: 0 1 = for x 5 5 -1 [if i >= 1 [break/return 'fail] i: i + 1]]
[i: 0 1 = for x 5 5 0 [if i >= 1 [break/return 'fail] i: i + 1]]
; start < end, start is x >= end, termination is x >= end
[i: 0 2 = for x 4 5 1 [if i > 2 [break/return 'fail] i: i + 1]]
[none? for x 4 5 -1 [break/return 'fail]]
[none? for x 4 5 0 [break/return 'fail]]
; start > end, start is x <= end, termination is x <= end
[i: 0 2 = for x 5 4 -1 [if i > 2 [break/return 'fail] i: i + 1]]
[none? for x 5 4 1 [break/return 'fail]]
[none? for x 5 4 0 [break/return 'fail]]


In all cases, bump is added to x after the termination condition 
is not met and before looping again.

Let me fix some comments above:

; start < end, start is bump > 0 and x >= end, termination is x >= 
end

; start > end, start is bump < 0 and x <= end, termination is x <= 
end


So, the direction sets the termination condition, and the bump sets 
the velocity that the loop is advanced between iterations, with range 
limits on the velocity as a starting condition in addition to the 
end range limits.

Ugh, let me fix the comments again, AltME is annoying:

; start < end, start is bump > 0 and x <= end, termination is x >= 
end

; start > end, start is bump < 0 and x >= end, termination is x <= 
end

Thanks. I'll have to make time to reconcile those with the tests 
I have in there now. I was hoping you could just say which don't 
match your model.

I kind of don't have time for that. I'm on the clock doing something 
non-Rebol-related.

OK.

If you get a chance, it runs the tests and just outputs to the console, 
so you can, I hope, see quickly where it goes off.

Well, when I get the chance I would like to review all of the FOR 
tests. But the question is whether at this stage of the game we should 
change tests for an R2 function. R3/Backwards and rebol-patches make 
R2 fixes relevant again, and this change is in keeping with R2's 
target market (newbies), but I don't know whether FOR's behavior 
is important enough to make it worth fixing in the tests, or important 
to keep bug-for-bug compatible (does anyone actually use it?). For 
R3, the tests will probably end up having to be redone for #864 FOR.

R2's original target market was newbies, but it kinda failed to hit 
that market. So at this point R2's target market is existing R2 users.

Is there even a significant number of existing R2 users who even 
use FOR at all? I mean, it really was crappy in R2. I definitely 
want to fix this in rebol-patches just on general principle, and 
likely R3/Backwards too since they're supposed to be compatible with 
each other, but does it even make sense to have a regression test 
for R2 if we're not going to have new versions? Are the R2 tests 
supposed to be testing rebol-patches and R3/Backwards, or new R2 
versions that may never exist?

I don't think we can know, aside from scanning rebol.org and asking 
people. I use it sparingly.

Over 10% of scripts at Rebol.org seem to use FOR. (135 out of 1152).

That's an upper bound as there may be a few false hits if someone 
is using 'for as a word etc....The search URL below finds the word 
FOR where it is in the body of a script (ie not in a comment, string 
or header)

    www.rebol.org/search.r?Find=[b]for

Hmm, to my big surprise I found my script in the list. But, after 
checking, FOR appeared really just in the COMMENT.

* start=end means no direction so just loop until the =end termination 
condition is met and ignore bump. If the index gets changed in the 
body block, let the =end termination condition handle it.

 - that is not reasonable for BUMP = 0 (no consistent termination 
 condition can be defined for that), also, the termination condition 
 should be VALUE <> END in this case if you want to be consistent

(the "no consistent TC" means no termination condition consistent 
with your requirement to not loop infinitely)

And =end is not a termination condition because you want the cycle 
to run at least once

Sorry.......As I said, some false hits - no easy way to exclude
    comment [....]
from searches.
When I said it excluded comments, I meant
    ; comment

understood, no problem

Brian, =end is not a termination condition, see these examples:

for i 5 5 1 [print i i: -5] ; this should print 5 and terminate
for i 5 5 1 [print i i: 3] ; this should be print 5 and terminate
for i 5 5 1 [print i i: 4] ; this should be an infinite loop
for i 5 5 1 [print i i: 5] ; this should print 5 and terminate
for i 5 5 1 [print i i: 6] ; this should print 5 and terminate

It is quite funny that you read what I wrote in the ticket but have 
got no idea what the differences are

similar examples for negative BUMP:

for i 5 5 -1 [print i i: 3] ; this should print 5 and terminate
for i 5 5 -1 [print i i: 4] ; this should print 5 and terminate
for i 5 5 -1 [print i i: 5] ; this should print 5 and terminate
for i 5 5 -1 [print i i: 6] ; this should be an infinite loop
for i 5 5 -1 [print i i: 7] ; this should print 5 and terminate

and as I said for zero bump you do not have any reasonable termination 
condition to use that would allow you to iterate at least once but 
not infinitely many times by default, so you just have to terminate 
before starting

Your problem is that you did not realize that the only way how to 
stop *before* starting is to apply the termination condition *just 
before* entering the cycle body