World: r4wp

Ladislav, in your latest FOR notes, is your last case [for i 1 1 
0] an infinite loop? I changed %new-loop.r to reflect your design, 
but tripped over that and wanted to clarify. Is this a correct interpretation?

Normal termination
    [loop [i 1 2 1]  [print i]]
    [loop [i 2 1 -1] [print i]]

Should not start
    [loop [i 2 1 1]  [print i]]
    [loop [i 1 2 -1] [print i]]
    [loop [i 1 2 0]  [print i]]
    [loop [i 2 1 0]  [print i]]

One cycle
    [loop [i 1 1 1]  [print i]]
    [loop [i 1 1 -1] [print i]]

Infinite loop
    loop [i 1 1 0]  [print i]

Ladislav, in your latest FOR notes, is your last case [for i 1 1 
0] an infinite loop?

 - hmm, I cannot tell for sure allowing the changes of the cycle variable. 
 However, if no change occurs, it is expected to be

The case

    for i 1 1 0 [print i]

certainly is

I appreciate your effort trying to understand what I wrote. I am 
not the best author of easily readable texts, usually preferring 
unambiguity, exactlness or other qualities.

The examples are great. It was just this one case, which I think 
differs from Brian's model.

That is, should FOR sometimes go infinite.

In any case, I can post my update for evaluation.

One thing that we need to make sure of is that the #1993 FOR should 
never ever result in an infinite loop if the loop variable isn't 
modified in the code block. That should never be an option.

OK, then we need to clarify that final case.

I just posted my changes, but the last case does result in an infintie 
loop.

I was very specific about that in the initial choice of models. Any 
model which allowed any value of bump to result in an infinite loop 
needs to be excluded from out choices.

I need to be more clear about that in the ticket and comments.

It was just this one case, which I think differs from Brian's model.

 - that is not true, in fact. Brian stated arbitrary rules like "for 
 i 1 1 whatever [...] should loop exactly once", that is a difference 
 as well

OK, so the difference between your model and one of my two models 
is that it allows something that we absolutely need to forbid? Or 
am I misunderstanding your model?

Having any termination test that can happen only if there is:


a) no adjustment of the cycle variable in the body changing this 
"expectation"

b) the bump is 0, which, of course, cannot change the termination 
test result when the variable remanins unadjusted

Brian, your arbitrary rules don't make sense when observed from the 
"termination test" POV. There is no termination test that can yield 
TRUE and FALSE being run twice in a row and not having changed inputs

Examples:

for i 1 1 1 [i: 0]

shall loop infinitely

OK, so the important question which you are glossing over by going 
on about termination tests is: Can any combination of start, end 
and bump result in an infinite loop without changing the index explicitly 
in the body block? Because that is what we need to make sure *never* 
happens.

for i 1 2 1 [i: 1]

shall loop infinitely as well

The whole point is to avoid accidental infinite loops.

for i 1 2 1 [i: 1]

That is changing the index in the body block. That is assumed to 
be intentional.

Brian, agreed, and agreed on accidental infinite loops.

Because that is what we need to make sure *never* happens.

 - there is only one way how it can *never* happen: if we forget about 
 termination tests and do some arbitrarinesses whatever they are. 
 Count me out

I really need to make this clear in the ticket. We need to block 
accidental infinite loops. We have FOREVER for intentional infinite 
loops, or the #864 FOR.

Nonsense. There is no such *need* especially when it is making the 
whole "business" inconsistent

For the moment, assuming all Lad's latest tests and design pass, 
except [1 1 0], as outlined above, are there any other issues Brian?

For example, what is the "consistent" behaviour of:

for i 1 1 1 [print i i: -5]

(I know what it is having described it in my proposal)

It's not arbitrary, it's just not based on termination tests, but 
based on initial conditions. Once the initial conditions are met 
it is assumed that any stuff done in the code block is intentional.

And, Ladislav, *should* [1 1 0] be an intentional, infinite loop 
in your design?

It's not clear to me that it should be, since [1 2 0] and [2 1 0] 
are not.

Termination conditions affect when the loop ends. Initial conditions 
affect when it starts and which direction it is thought to be going 
in.

OK, concrete example:

for i 1 1 1 [print i i: -5]

How and why?

And if it should *not* be infinite, is it a "should never start" 
case, or a "once only" case?

Well, I do know what shall happen in

for i 1 1 0 [...] depending on the value of i

(which may have been adjusted in the cycle body)

Once you get past the initial conditions then everything after that 
is affected by the direction, the bump and the code block. But we 
have to assume that start, end and bump could have come from the 
result of a possible erroneous calculation based on crappy data. 
The initial conditions guard against that. Ladislav, every code example 
you give that sets the index in the code block is considered intentional 
behavior. It is only start, end and bump that are considered possible 
out of the developer's control. If a developer passes an unknown 
code block to FOR then they deserve what they get.

SImilarly I do know what shall happen in

    for i 1 1 1 [...]

depending on the value of I

You are putting your ... in the wrong place.

Ladislav, can we address indexing changing scenarios separately?


I have to run. Will check back later. If the chat gets long, could 
someone summarize final thoughts at the end? Thanks.

That ... in the body block is the only thing we can safely assume 
is under the developer's control.

every code example you give that sets the index in the code block 
is considered intentional behavior.

 - what behaviour? (I do know what shall happen having specified it, 
 but what shall happen according to your arbitrary rules and why?)

My rules aren't arbitrary, as I explained above. Your termination 
condition rules just don't cover initial condition screening.

Ladislav, can we address indexing changing scenarios separately?

 - you can do whatever you like being inconsistent however you like. 
 I already addressed all the cases

This is a common factor in all of the R3 control functions. The body 
blocks are considered to be under developer control, while calculated 
intial conditions are considered to be possibly out of their control.

My rules address any combination of START, END and BUMP with any 
combination of the actual cycle variable VALUE telling whether the 
loop shall terminate or not.

Um, no, because it doesn't handle the problem of making sure that 
accidental infinite loops aren't screened for. The termination condition 
that would be affected by bump=0 in your model could also be affected 
by index changes in the body. Everything in the body is considered 
intentional. So, you are lumping in presumed-intentional infinite 
looping with presumed-unintentional infinite looping. It's the same 
reason why FOREACH [] data body triggers an error, but FOREACH [a:] 
data body doesn't.

aren't -> are
I hate not being able to edit my posts.

For instance, you might noting that FOR has a lit-word parameter 
for its index. That makes the word peovided considered intentional, 
because you have to do an extra step to not know which word was provided. 
And in general, people are presumed to know where they get their 
code blocks from.

So, your CFOR taking 4 code blocks means that people are presumed 
to control the contents of those blocks. So, infinite loops would 
be OK in CFOR because it says "General loop" right there in the doc 
string.

In the constrained #1993 FOR, the constraint is a feature. It will 
protect you from infinite loops that you don't intend, regardless 
of what start, end and bump say. You would have to go out of your 
way to make an infinite loop, by setting the index in code that you 
wrote. That way, you know you can safely call FOR when you don't 
even know what start, end and bump are.