World: r4wp

On range!, my thinking is that the default would be a 'bump of 1 
(next value in a series), because that's how I think of iterating 
over a range of values.

We can't really discourage anything because we don't have "warnings" 
in Rebol (no way to implement them without a logging facility, and 
no point in logging them without a precompiler). It's allowed or 
it's not. If it's allowed (in R3 at least) it's because it's part 
of the intentioned model.

We can't really discourage anything

 - I guess that Gregg mentions to discourage it in the documentation

Yes, in docs.

(should be "means")

The range! type turned out to not actually be useful. You can stop 
adding a ! when referring to ranges :)

So the question we're posing is whether we want the developer to 
be able to manually affect the FOR loop process from the inside (a 
feature, useful for advanced developers), or whether we want the 
loop process to be inviolate regardless of changes to the index in 
the code (another feature, useful for compilers that might want to 
unroll loops). Given that we don't have a compiler, that suggests 
that affecting it might be a useful feature, but Red compatibility 
and the overhead of checking the index value rather than just setting 
it based on an internal value in native code suggests that the latter 
might be better. There is no point in discouraging anything, since 
there is so much overhead to allowing it at all that we should only 
do so to provide a feature explicitly.

If you have the loop process inviolate then you can use a C value 
or even a raw value slot as an internal loop counter. If you want 
changes to the index in the code to persist, the loop would need 
to check that word after the loop cycle ends to determine its current 
value, then change that. That has overhead, like checking for and 
reacting to unset values, that just ignoring the word's value doesn't 
have. So if we want to allow it at all, it shouldn't be discouraged 
except as a potential gotcha, it should be considered a feature.

in languages like C  the for loop is the basic iterator and it should 
be completely open.   but in REBOL we do have a lot of purpose-built 
iterators, I think FOR shoudn't allow non advancing steps and should't 
allow the inner loop to affect index.   This would make FOR faster 
for its primary purpose.  


I don't see the point in trying to make every different iterator 
another interface to while/until

in languages like C  the for loop is the basic iterator and it should 
be completely open

 - actually, C does not have a FOR loop, it only have a general loop 
 called for ()

IMHO, differenciation of each iterator, increase their relative "relevance" 
in the language.

Whatever we choose with FOR, we should make REPEAT behave similarly 
in that same choice. Those two are in the same family.

i.e. C language for () is not a FOR loop, in fact. it is a general 
loop

Ladislav, try to keep on topic. We're not talking about CFOR, we're 
talking about FOR :)

It was Max who mentioned that

Back to the step argument: For FOR, the main factor for whether the 
loop would normally end is whether the step > 0 if start < end, or 
step < 0 if start > end. So it's not whether it = 0. We should allow 
one iteration when start = end, but trigger an error otherwise if 
we have a non-advancing step. Developers can just as easily use BREAK 
and such for an advancing step.

Simply not doing anything is bad here because it makes the error 
much harder to track down. It's terrible for debugging.

Wait, I might be wrong about step. For start > end, if step is positive 
then FOR should do nothing. It should only trigger an error for 0. 
The step sign determines the direction of the FOR.

exactly.   it should only raise an error when the step  = 0

I've used some languages that try to prevent ranges which are opposite 
to step (with an error) but I found that very annoying when playing 
with code which uses variables for start & end values.

Do we have enough factors to make some tests and tickets for FOR? 
I'm not sure whether we came to an agreement about the changing index 
issue, so that might be worth an issue ticket (assuming this conversation 
will disappear because we're in AltME, not CureCode).

I can make the tickets later today - it just looks like two, one 
for step, one for index-changing.

Sorry, bump. Don't know why I thought it was called step.

I think that 'for should be as flexible as possible.  One of the 
main problems IMHO of most programming languages and software systems 
is designed inflexibility.

Let's say that I have two series that are the same length, and the 
values at each position of each series are related to each other. 
 What if I want to use a 'for loop to increment through the first 
series, but in some cases, depending on the value of the first series, 
I want to skip x values ahead, and on other values, I want to access 
that same position in the second series and perform an action on 
it.  Why couldn't I use a 'for loop to do this if I wanted?

It would be sad if 'for was designed to disallow me from doing this.

Well, FOR isn't a general loop like in C, it's just an iterator. 
If we need a general loop we should add one, even though general 
loops are more expensive to use in interpreted languages than specific 
loops (which is why we have specific loops rather than one general 
loop). However, "I want to skip x values ahead" does sound like an 
argument for allowing index changes to affect the looping process, 
as a power-user feature.

(Sorry for the tangent:) Can anyone reproduce http://curecode.org/rebol3/ticket.rsp?id=1974
on OSX? For me, I obtain the expected result on OSX and see the erroneous 
9.9.9 under Linux.

s/For me, //

Bo, I'd say don't use FOR its just about the worse fit for that algorithm 
.   :-)

I came up with two models for the start/end/bump situation, both 
of which make sense. We can pick the one we like the most. I'll put 
it in the ticket.

Maxim: Right now, I would use something like the following:

x: 1
endval: length? b
until [
	either s1/:x = b [
		do something
		x: x + 1
	][
		do something2
		x: x + 5
	]
	x >= endval
]

MarcS, I cannot replicate that on OSX with build fc51038.

I don't see it in the experimental 64 bit build either.

Henrik: thanks for the info.

BTW, this is on 10.8.

Here too

Bo: you could rely on FORALL and series positions instead of carrying 
numerical indexes around:

forall b [
    offset: either b/1 = pick s1 index? b [
        do something
        1
    ][
        do something2
        5
    ]
    b: skip b offset
]

Sunanda mentions that 1.1.1 / .1 is correct under R2/Windows. Can't 
test that currently, but 9.9.9 is returned by R2/Linux (i.e., this 
behaviour doesn't look like a regression in R3)..

Marc: R2/Win correct here. R3/Win incorrect here.

I have a provisional fix in place for R3/Linux.

Bo, while I want flexibility as well, especially in a language like 
REBOL, I don't think we need complete flexibility everywhere. Constraints 
are very powerful and helpful.

To me, FOR creates an expectation of consistent stepping behavior, 
*but* there are times when you don't want that, and FOR seems like 
the first function you still want to go do.

Ticket for the FOR stepping behavior: http://issue.cc/r3/1993. The 
FOR index modification behavior will be a separate ticket, since 
while they'll likely need to be implemented at the same time, they 
need to be discussed separately.

Thanks Brian.

Is this by design or oversight? DATE can be used for most access 
paths, but not with PICK
    ser: [1-jan-2000 9999]
    select ser 1-jan-2000
    == 9999
    find ser 1-jan-2000
    == [1-Jan-2000 9999]

    ser/1-jan-2000
    == 9999
    pick ser 1-jan-2000
    ** Script error: invalid argument: 1-Jan-2000

I would say it's by design.

That is, what position would it reference?

It would make sense for maps, where SELECT and PICK are pretty much 
the same thing, but not for series, where they mean something different.

PICK for series just means the index, or something that can be translated 
into an index like logic is.