World: r4wp

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.

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.