World: r4wp

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

and, of course, it is immediately obvious why =end is not a termination 
condition then

Is this a bug?

>> val: [a b c]
== [a b c]

>> val = [a b c]
== true

>> switch val [[a b c] [1]]  
== none

The 'swtich doc string doesn't indicate any restriction on the type 
whch can be used as the switch value.

Looks a bit odd.....

In R2 it doesn't work if the val is a block! but it does with hash!
In R3, block! doesn't work but map! does

Test code:
   val: make map! [1 2 3 4] switch val reduce [val [print 1]]

Should I add it to curecode?

%new-loop.r updated with Ladislav's latest examples.

BTW,

    for i 1 1 0 [print i]

is an infinite cycle both in R2 as well as in R3

BrianH: I used 'for quite a bit in R2.  But I used it simply when 
I needed access to a counter.

Ladislav, you are not getting that I am applying an *additional* 
termination condition before the start of the first loop, in addition 
the normal termination condition applied after every iteration of 
the loop, before the bump. Please don't mistake an intentional constraint 
for confusion.

I am not at all confused by your argument, I just don't agree with 
it.

Proposed fix for http://curecode.org/rebol3/ticket.rsp?id=1979- 
https://github.com/0branch/r3/commit/5bc79f6812a67f28ccd79372361c7fad7f3a6ea0

The linear search isn't ideal, though it means that existing structures 
can be re-used without further allocation.

Now https://github.com/rebol/r3/pull/105

'Ladislav, you are not getting that I am applying an *additional* 
termination condition before the start of the first loop, in addition 
the normal termination condition applied after every iteration of 
the loop, before the bump. Please don't mistake an intentional constraint 
for confusion.'  a couple of notes:


- you still don't get that if you are not consistent producing a 
lot of exceptions your code will be full of bugs and arbitrarinesses 
(there is absolutely no escape from this)

- you still don't get that there are concrete examples above demonstrating 
the problems you did not even consider yet

And I am not mentioning other problems I did not even discuss yet.

Also, saying that a cycle runs exactly once (which is, thus, independent 
on the cycle body) is too inflexible to not be considered just a 
bug  when knowing that the cycle varialble may be adjusted in the 
cycle body

Brian, on CC, your latest note links to #864, which I think should 
be #884.

Brian and Ladislav, how can we resolve this? Maybe you could both 
look at %new-loop.r and it would unite you against my incorrect and 
overly complex attempt. :-)

:-)

Meanwhile, you can check this to compare:


https://groups.google.com/forum/?fromgroups#!topic/Rebol/appT3TV5urY

>> for i 10 5 -1 [print i]
** Math Error: Math or number overflow
** Where: for
** Near: either max-int - bump <

needs correction, as it looks, checking

Seems to be the same for all negative steps (quick test).

aha, I swapped the condition, try with either negative? bump, please

disregard, needs something else...

aha, it should have been max-int + bump

I shall put the code here

I'll test it when you do.

done

At a quick glance, I believe for FOR and my LOOP have the same behavior, 
though I didn't address overflow as an initial goal.

Yes, that is what I guessed

(but I did not test your LOOP, to be honest)