World: r4wp

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.

We should allow one iteration when start = end, but trigger an error 
otherwise if we have a non-advancing step.

 - I am asking to make sure I understand this formulation. Does it 
 mean that you want to allow

    for i 1 1 step [...]

in case step <> 0 but not in case step = 0?

For start > end, if step is positive then FOR should do nothing. 
It should only trigger an error for 0. 
 - hmm, I find it quite natural to prefer:


For start > end, if step is not negative then FOR should do nothing
 like Endo seems to prefer

The reason is that it is simpler.

 even though general loops are more expensive to use in interpreted 
 languages

 - that may be true in general, but, funnily enough, my general loop 
 implementation was always faster in R2 than FOR

Actually, there is one more reason I see why a general loop is quite 
natural and it is needed in Rebol: in case we need to iterate using 
decimal! values, it is quite likely that we need more "custom" END 
comparisons than any FOR implementation can give us. That is exactly 
the case when FOR cannot be improved much.

'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.' - agreed, it may be convenient when the user needs such 
a feature

Gregg: I'm all for constraints if there is a significant "win" component. 
 If it doesn't, don't constrain it.  Apple, but especially Microsoft, 
are really good at artificially constraining software.  Frustrates 
me to death.  Most of the time, it just seems like a poor design 
decision.  Other times, I can see how the constraint is being used 
to generate revenue.

However, I am quite unsure whether Carl implemented it as a "power 
user feature" or if he had some other reason (looks likely to me)

For some reason I thought that R2 allowed indexes to be changes, 
but R3 didn't, and that was a loss of functionality. After actually 
testing, it appears it was the other way around, a gain of functionality. 
I'm for R3's model in this case, enough so that I didn't think it 
worth adding a ticket.

If this was a language designed to promote "proper" programming, 
I could see having constraints on every function to keep them from 
being used in new ways, and to promote the proper usage of the function. 
 However, in real life, flexibility is key.


Let me know if this makes any sense:  If I want to rip the fender 
off my car and fashion it into a medieval helmet, physics allows 
me to do so (if I had the requisite skill).  However, in programming 
languages, this type of thing would rarely be possible.


So what I'm saying is this: Try as much as possible to refrain from 
placing software developers in a box when it comes to how they might 
choose to use a function or a feature.

Bo, we're agreeing with you in this case. Stop arguing before you 
convinve us otherwise! :)

There is nothing preventing you from hacking FOR into a helmet. What 
I'm saying is that we should tell developers "Here is a helmet, and 
here is a fender. You should use each appropriately." and we shouldn't 
make the fender a poorer fender design in order to accommodate helmet 
makers.