World: r4wp

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.

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.
 - yes, makes sense to me, Bo. I alway try to achieve that

BrianH: Thanks. Sometimes I end up "preaching to the choir."


Gregg: I wasn't proposing to compromise the intended functionality 
of a function.  I was simply stating that *artificial* constraints 
shouldn't be placed on a function for the purpose of limiting its 
functionality.

Agreed Bo. Constraints should exist only to empower us.

Ladislav, in answer to your first question about "We should allow 
one iteration when start = end, but trigger an error otherwise if 
we have a non-advancing step.", yes. That is the difference between 
the two models in that ticket. 0 bump should behave consistently, 
according to a model which makes sense.


In one of those models, the bump is given primacy over the start-vs-end 
factor, and judged *on its own* a bump of 0 is an error (since it 
doesn't make FOR advance in one or the other direction). So, that 
error should be triggered categorically before the range is even 
considered.


If, on the other hand, start-vs-end is given primacy, then we have 
3 valid answers to the direction argument: forwards, backwards, or 
once - the bump argument doesn't determine direction, it determines 
velocity in the direction already chosen. In the start=end case the 
bump is always ignored, so ignoring it for 0 makes sense. In the 
start<end or start>end cases, a bump of 0 is basically out of range 
because those cases are only defined  to move in the positive or 
negative direction, respectively. That means that start<end is only 
positive, and start>end is only negative.


Does that make the difference between the models clear? Of course, 
because you can BREAK, CONTINUE, or even set the index position in 
the code, that doesn't actually reduce our flexibility where we really 
want to do anything interesting. It just makes the basic model make 
sense.

For me, the model preferring START and END to determine the direction 
makes more sense and looks less constraining.

The model preferring BUMP looks rather "uninteligent" and "constraining" 
to me.

Agreed. I mostly put that in for contrast.

I understand that you put the "if START = END" rule there to have 
the definition simple enough but not simpler than useful

Well, if you think bump should have primacy, triggering an error 
for 0 before you even look at start or end is the only thing that 
makes sense. And the velocity model for bump is the only justification 
for its existence at all if start-vs-end has primacy. Really, it 
can be anything we want as long as it makes sense :)

However, I must agree with Fork that we need a general loop in Rebol 
no matter what. (see e.g. iteration in the decimal range as an example) 
Just the dialect he proposed does not look sensible to me when compared 
to the general loop I am using for a long time.)

I think that something as powerful as yours, but maybe a little friendlier 
for the newbies, and maybe with some REWORD-style thoroughness, might 
work. I think that we need to go beyond the old style of general 
loop though - we're competing against languages with list comprehensions, 
not just C-like languages :)

But CFOR can do list comprehensions easily, I do not see any problem 
with that

http://issue.cc/r3/884

So it's not a power thing. Cool.

It's a dialect thing then.

power

 only in the sense that you get the power to specify looping in an 
 easy and flexible way

However, it is easy to see that it is not too slow compared to other 
looping constructs

Not easy and flexible enough. You proved that we can do this already 
with the two-line implementation, but it doesn't have the syntactic 
sugar that the list comprehension fans need. So we might want to 
rethink the API but keep the power. Sometimes I think you're too 
smart for dialect design, Ladislav :)

Sorry, the "not easy and flexible enough" does not make much sense 
to me. There is no more flexible cycle function than this one in 
Rebol at present.

Flexible and powerful isn't enough. I know this is difficult Ladislav, 
but try: Imagine that you're dumb. What would dumb you want?

Just as another perspective: COLLECT + FOREACH is a powerful, easy, 
and flexible list comprehension-like alternative.

I'm having some difficulty imaging dumb you too, Ladislav, so take 
no offence :)

I use COLLECT + FOREACH a lot, as well as COLLECT + PARSE.

Me too.

1) I want less arguments than FOR has as Fork required - done

2) I want to specify the comparison used, not just in case when iterating 
over decimals - done

3) I want to specify as many "cycle variables" as necessary like 
Bo demanded - done

4) I want to specify more complex incrementation rule as Bo demanded 
- done
5) I can use COLLECT with CFOR

- does this list look like something not worth considering?

If MAP-EACH was more powerful I wouldn't need COLLECT. Ditto with 
Gabriele's PARSE extensions.

Ladislav, that's a feature list, not a dialect. It's a great feature 
list, and when we're building the dialect we should take all of that 
into account. But what you suggest in CFOR is not much prettier than 
FOR, and is almost as ugly as C's for loop. It's powerful, but not 
something we can point to and say "Look at how powerful we are!" 
to people who don't understand that surface stuff doesn't matter 
when you're talking about power. Imagine people who haven't heard 
of big-O notation or Turing completeness, but have used Python or 
Ruby. Especially Ruby because of how pretty it is but how much it 
sucks beneath the surface.

I consider CFOR prettier than current FOR. The main use of CFOR I 
see, is to have everything loop-control related kept together and 
lexically before the body (otherwise you can just use plain WHILE).

Ladislav, that's a feature list, not a dialect.

 - sure, feature list is not a dialect. CFOR is a dialect, though, 
 exactly like there is an object specification dialect or function 
 specification dialect. The fact that you do not see it is a dialect 
 does not matter at all

No, I see that, it's just not necessarily a very good dialect in 
the sense of dialect design. It's powerful, but not clean enough.

I can imagine what "clean" means, then. Fortunately enough, I do 
not need to care.