World: r4wp

We have some more flexibility here because we can't actually do this 
as a mezzanine, it has to be native code (no [throw]). So let's take 
the opportunity to make it really nice.

And, BTW, CFOR is substantially more powerful than what C for() offers.

Fortunately enough, I do not need to care.

 - agreed. That is not your job. You job is adding real power, not 
 the impression of power. The latter is more my job :-/

powerful
 in the sense of expressivity, not in any other sense

Yup, I got that :)

Btw, REWORD has a #539 problem too, as of the http://issue.cc/r3/1990
changes. Those new features need [throw] to work peoperly, or a native 
implementation. Oh well, that's the price of a powerful dialect sometimes.

Brian, Gregg -- PICK for dates....Thanks. For some reason I was reasoning 
beyond what is sensible for PICK. Let's keep it as now!

CFOR, EVERY etc

I'm happy with FOR as I do not need to construct and perhaps REDUCE 
a block to set up variable start conditions -- just have to set words 
to values.

For me, the syntaxtic sugar neatness of the new proposals is outweighed 
by the simplicity of the setup for the existing method.


No real opinion on how to standardise the existing behavior other 
than to reiterate a point Brian has already made: FOR start and end 
can work on series too; all the examples I've seen of proposed change 
behavior is for numbers. We need to ensure thar series FORing works 
as expected too.

Regarding http://curecode.org/rebol3/ticket.rsp?id=1974, https://github.com/0branch/r3/commit/7b4e8529e683c92d406e89b287092507c5876924

Perhaps I should have mentioned truncation explicitly in that commit 
msg.

Posted %mezz/new-loop.r for comment. Not complete, but should be 
enough to use for discussion, pro or con.

I think the proposed loop is too mighty.

How easily do you forget an argument without getting an error and 
doing something different to what you wanted.

I'm happy with FOR as I do not need to construct and perhaps REDUCE 
a block to set up variable start conditions 

 - this looks like you never used CFOR, otherwise you would have know 
 that it does not require anything of that kind

For me, the syntaxtic sugar neatness of the new proposals is outweighed 
by the simplicity of the setup for the existing method.

 - funny, again, the simplicity of the setup of CFOR is mentioned 
 while not taking into account that:


* there are requirements FOR can never meet already handled by CFOR
* the simplicity of CFOR setup was not even checked

https://groups.google.com/forum/#!msg/Rebol/appT3TV5urY/rQ1XJLwZXFwJ

Sqlab (I'm sorry I don't remember your real name, and it's not in 
your profile here), it would certainly be easy to add keywords as 
markers, even optionally; or remove the REPEAT compatible option 
if that's too liberal. With the latter change, the only difference 
from FOR is that the bump value is optional.

Pull request addressing CC #1974, https://github.com/rebol/r3/pull/104

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?