World: r4wp

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.

In case you have got an arbitrary reason for every design detail 
you can still enforce your decisions against any other alternative; 
just don't expect me to not classify it as "crap full of bugs" as 
I already did for the previous version of FOR

Well, that difference is a downside to CFOR, but the upsides outweigh 
it so I prefer #864.

You are just not used to writing code with bugs in it Ladislav. You 
don't understand how constraints can be a benefit.

Nice benefit to know that the best what can be done is to not use 
the function at all.

Well, when you're writing infinite loops, yes. It really is better 
to use FOREVER, it makes your code easier to understand.

(For normal people I mean, that's not your problem.)

Also, (just a warning). If you still want to allow cycle variable 
changes you do need to have the means how to determine when to terminate 
and when not

Right, that is where the termination condititions come into play. 
The initial conditions just determine which set of termination conditions 
we want to use.

If you prefer to not have any cycle variable changes, then you are 
better off having the ability to make your rules consistent somehow

No, I prefer to allow cycle variable changes in the code block to 
affect the cycle. The code block is assumed to be under developer 
control.

The models I specified only had to do with initial conditions.

Then you are being inconsistent mixing incompatible rules.

Good luck with that.

Well, when you're writing infinite loops, yes

 - nonsense, the inconsistencies will be observable in finite loops 
 as well

That wasn't a comment on the inconsistencies, that was an answer 
to the previous message where you said "the best what can be done 
is to not use the function at all." - I was agreeing with you in 
the infinite loop case, and giving my reasons why.

But that sill does not solve the case of finite loops, does it?

We are giving developers more control by saying that some stuff is 
under their control (i.e. the code blocks). We are providing some 
safety by saying that some stuff is presumed to be not under their 
control and thus possibly suspect (i.e. immediate-evaluation parameters 
to functions that they didn't write). We do screening of some stuff 
because that cuts down on the screening they have to do themselves. 
That way dvelopers can use functions and assume that they are safe 
to use by default.


For instance, one advantage of #1993 FOR would be that they would 
have to go out of their way to make it do an infinite loop, since 
no combination of start, end and bump would generate one. That means 
that they wouldn't have to wrap calls to FOR in expensive conditional 
code, they can just pass in any values of those parameters and trust 
FOR to never go infinite without them expecting it. Your CFOR would 
not have that advantage, but since it takes code blocks for all parameters 
it is assumed that you are more careful about those code blocks, 
as you should be as a general rule in R3.


It's about providing a balance. Complete consistency in how all parameters 
are treated regardless of their nature would not allow us to help 
developers where they need it. However, having a consistent policy 
that code must be treated more carefully by developers than non-code 
allows developers some flexibility while still allowing them to be 
careful. That is why code that developers provide explicitly is considered 
to be what they want to do, at least from the outside of functions. 
And you can make the distinction between code and non-code using 
simple type tests, which is why we have APPLY and ASSERT/type.

But that sill does not solve the case of finite loops, does it?

 - well, you could have really large finite loops that on a pragmatic 
 level are close enough to infinite to still cause a problem. I think 
 that there is a global evaluation limit that is supposed to protect 
 you from that, but I don't know if that currently works.

Of course the evaluation limit is under developer control.

THat is absoluteyl misunderstanding where the real problem is.

OK, nevermind. I will try to be understandable for you:


if you want to do so, you *can* eliminate the only combination of 
START, END, BUMP values that causes infinite loop by default while 
still remaining consistent at the cost of disallowing something that 
may be perceived as "legitimate" by some users, and as an "unsolicited 
for" limitation.

Really? Because I was assuming that FOR would have termination conditions 
(similar to yours). The initial conditions model just picks which 
set of termination conditions to apply, at least as far as the start, 
end and bump parameters are concerned. The body parameter, being 
a code block, is assumed to be under developer control. So if the 
developer wants to hack the termination conditions in the code block 
that is their fault.

Ha, are we still discussing 1993 or some other ticket?

FOREVER is assumed to be a solicited-for infinite loop, because it's 
right there in the name. #864 is assumed to be whatever the developer 
says, because "General loop" is right there in the doc string. #1993-1994 
FOR has the *feature* of not *accidentally* being infinite for any 
value of start, end and bump, its constraint is a feature; of course 
it could be *intentionally* infinite by changing the index in the 
code block, but that just means that there is one parameter that 
the developer would have to be careful about, the body block, and 
since that is a general pattern throughout R3 they would be doing 
that anyway.

Assuming that we are discussing #1993 and assuming:


* you insiste to allow the FOR I 1 1 0 and similar to be "infinite 
by default"

* want to support cycle variable changes in a simple and consistent 
way

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. Some people may object, 
but otherwise it looks as not a big deal.

err: "you insist to not allow FOR I 1 1 0 and similar to be "infinite 
by default"" is what I meant

{you insiste to allow the FOR I 1 1 0 and similar to be "infinite 
by default"} -> {you insiste to allow the FOR I 1 1 0 and similar 
to never be "infinite by default"}

Right.

The fact that we even have a FOREVER loop at all means that there 
would be a value in having developers use it, just for their own 
documentation.

And that allows developers to be less careful with start, end and 
bump, for values of "careful" that mean "wrapping FOR in expensive 
conditional code".

We've been trying to reduce the amount of expensive conditional code 
throughout R3. That's why a lot more functions allow none now.

ASSERT/type means that typechecks don't have to be considered expensive 
anymore. Value checks still require EITHER and other conditional 
functions though.

For that matter, typesets make the type tests of function argument 
specs less expensive now too, so we can afford to be picky there 
as well.