Equivalent to Python's range

[dennis]

I think I would prefer the compiler to DWIM and handle this mathematically instead of my having to remember to handle both cases.

[Charles]

My idea behind the Cobra numeric for loop was to make it every bit as fast as the C# equivalent. Part of this speed comes from having the programmer determine the direction. I felt comfortable with this since most of the time the programmer does know the direction.

I didn't use "to" as in "for i = 0 to n" because "to" is used for typecasting as in "someObj to int". It would be ambiguous to the parser. Once I chose the ".." symbol, and given that a symbol (=) is used after the variable name, I decided to use a symbol for the step too.

Regarding speed, your hunch is correct that using something like Range is a slowdown. Someone tested the speed difference and it was something big like 15 X.

One idea I'm playing with is using the same colons that are used in slicing:

# slicing is left inclusive, right exclusive:
list = list[0:list.count]  # same list
list = list[0:2]  # gets 2 elements, not 3
# since for loop generates indexes with same semantics, reuse colons:
for i = 0 : list.count : 2
    pass

This won't be quite as fast, even when the step is implied. We'll have to see how close it can be. If more speed is desired, we could add the optional dictation of the step direction to get back to C# speed:

for i = 0 : list.count ++ 2
    pass

If any of these changes take place, the current syntax with .. ++ -- will still be supported so your programs don't break.

[dennis]

Here's another idea:

for i = 1 .. 100 by 2

as in "count to a hundred by twos"

counting down would look like:

for i = 10 .. 0 by -2

[khjklujn]

for i = 0 : list.count : 2
    pass

Adds consistency and reduces the token set by one. That's good.

Actually, I don't see any reason why that syntax can't go directly to a C# for-loop, without the need for ++ and -- operators. To generalize:

for i = a : b : +c  # goes up
for i = a : b : -c  # goes down

In either case, c must either be a positive integer literal or contain a positive integer, so the unary operators can be used to indicate the direction of the comparison.

Of course, if slicing is going to perform a run-time evaluation of c, it probably wouldn't be such a good idea, but does slicing have to perform a run-time evaluation of c? Sounds like it might be faster if it didn't, and off the top of my head, I can't remember any cases where I ever used the same statement to slice in more than one direction. Just a thought.

[dennis]

# slicing is left inclusive, right exclusive:
list = list[0:list.count] # same list
list = list[0:2] # gets 2 elements, not 3
# since for loop generates indexes with same semantics, reuse colons:
for i = 0 : list.count : 2
pass

Since slicing is right exclusive:

for i = 1 : 100

would not be the same as:

for i = 1 .. 100

if the colon form of the for statement follows the same convention as lists.

[Charles]

But that's how "for x = 1 .. 100" is implemented in Cobra. It's right exclusive. I played around with the idea of three dots for right inclusive ("for x = 1 ... 100"), but never got to it and don't miss it.

Interestingly, Ruby does the opposite: an extra dot gives you one less element, or in other words, one less dot gives you one more element. Ruby can be a strange one.

Another idea is to reuse "in" in place of "=":

for x in 0 : 100
    print x

for i in list.count
    print i

[dennis]

But that's how "for x = 1 .. 100" is implemented in Cobra. It's right exclusive.

In Pascal and Basic, for is right inclusive. In C, you have a choice by using < or <=. And, as you pointed out, Ruby gives you a choice, too.

[Charles]

These are good observations, but I have to add that in all my Python coding, I never missed having right inclusive. You can always add +1, but I don't even recall doing that very often.

Also, the slice syntax uses colons, so there's not much choice to be had like there is with "<" and "<=".