World: r4wp

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

BTW, END and START I did not mean as English words. I meant them 
as the respective FOR parameters.

according to my explanation, both should return none, because end 
value is not reachable.

hmm, but 1 = 1 + 0, i.e. the END value actually is reachable in the 
latter case

Yes, if step is negative START - END should be swapped.

aha, second case, you are right.

wait, it should pass the END value.
For i=1 To 1 Step 0 --> infinite loop on  BASIC.

Normally, in old BASICs languages, variable used in FOR, its value 
stays END+1 at the end of the loop.

* end_value + step_value

Hmm, that is not convenient in some cases

There is another issue;
on R3:

for i 1 3 0.2  [print i] ; prints 1 ... 2.8 (end value is not included)

for i 3 1 -0.2 [print i] ; prints 3 ... 1.2 (end value is not included)
on R2:

for i 1 3 0.2 [print i] ; prints 1 ... 3 (both start & end value 
included)

for i 3 1 -0.2 [print i] ; prints 3 ... 1 (both start & end value 
included)

I think R2's behaviour is "more" correct.

for i 1 3 0.2  [print i] ; prints 1 ... 2.8 (end value is not included)

 - this is an arithmetic problem; 0.2 is not representable exactly 
 by a binary floating point (i.e. decimal!) value.

I do *not* recommend to use a general code for such loops

right,
for i 1 3 0.1999999999999999 [print i] ; --> 1.0 ... 3.0

This is an excellent question Ladislav. What if we start with the 
doc string:

  R2: Repeats a block over a range of values.
  R3: Evaluate a block over a range of values.


That makes me think 'bump has to be non-zero, and it should throw 
an error. It should also throw an error (under R2) if 'start and 
'end are series values and won't terminate (e.g. empty series). R3 
does this now. That is, FOR should always terminate.


R2 allows char! values, R3 does not. Under R2 specifying an 'end 
of #"ÿ" (char 255) also results in an endless loop. My RANGE func 
tests for that, because it caused me a problem at one point.

I think that we have two conflicting values here:

* Do what I *say*, since you can't read my mind to know what I mean

* Trigger errors when you run into something almost definitely wrong 
as a favor to the developer


In the case of FOREACH, it triggers an error for an empty words block 
and doesn't allow none because that block is part of the control 
structure, not the data (which we do allow empty or none for). In 
the case of a block of only set-words, that also doesn't really advance, 
but at least you get a reference to the series so you could in theory 
be doing something (that you should probably use WHILE to do instead), 
so not triggering an error in that case is iffy, you could make an 
argument either way.


For FOR, the main factor for whether the loop would normally end 
(without BREAK or changing the index manually somehow) is whether 
the step > 0 if start < end, or step < 0 if start > end. So it's 
not whether it = 0.

My preference, then, is to 1) throw an error or 2) never execute 
the loop.

Bad control parameters usually mean triggering an error in R3, to 
better help the developer with their debugging. We only do nothing 
for empty data, sometimes for values of "empty" that include none.

And since I mentioned RANGE (which I still think could be a useful 
datatype), how would we expect FOR to work in the context of a range! 
type? e.g., a range with bounds of 0 and 0.


With regard to decimal 'bump values, I do allow them in my RANGE 
func, which uses FOR internally. It is one of the few places I do 
use FOR.

REPEAT would be used with the range, not FOR. FOR takes too many 
parameters.

Brian, yes. I vote for an error because FOR says, to me, that you 
expect the loop to terminate. If you want an infinite loop, use FOREVER 
to make that clear.

Well, yes, REPEAT would be the clear choice, but if you have a range! 
and passed its lower and upper bounds to FOR, what would you expect? 
FWIW, I've always thought 'bump should have been a refinement option 
in FOR.

Right. One thing we need to consider is whether we want changes to 
the index in the code block to affect the index of the loop, or whether 
we just want to do that with BREAK. There are advantages to either 
model. If manual changes to the index are ignored, it becomes safe 
to change in your code. If they aren't ignored, it becomes another 
way to affect the loop in your code.

Another fun question. :-)

If you have a range type (which was rejected, btw, but might get 
revisited) and you break out its upper and lower bounds so it can 
be passed to FOR's *two* parameters for those values, the programmer 
would still need to specify them as they see fit.

While I think it's a bad idea to mess with the index, there are reasons 
to allow it. I think manual changes should be allowed, but discouraged.