I was thinking of Python’s for in loop, and wonder if some of you might like the idea? The benefit I see is that it helps make codes shorter, but a few additional lines of codes is not bad either. The syntax looks like this:
#@cli fooin_test: arg1,....
#@cli : Prints every two arguments using forin loop
#@cli : First argument of forin is step size.
forin_test:
forin 2,$*
e Forward:$>
e Backward:$<
done
This can already be done with things like $=a, repeat $#>>1 {}, and ${a{$>+1}},${a{$>+2}}, but it’s harder for new G’MIC programmers. This is more readable.
Not a big fan of the concept of iterators for writing loops, in general.
For instance, in C++, this has clearly complexified the writing of loops, without clear benefices (to me).
Is this considered as readable ? What would be expect from such a loop ?
Definitely not clear to me.
I read it as in blocks. Similar to my permutation library where numbers args don’t make it apparent. That means seeing every two args as blocks. But, to be fair, that would not be apparent.
I don’t think people would use it like that. And we do number arguments all the time.
And if I remove the first argument, there still would be slight less code to use as $=a would not be as essential. The first parameter makes things a little bit more interesting, as I can do a,b,c=$> instead of a,b,c=${a{$>*3+1}},${a{$>*3+2}},${a{$>*3+3}} or doing the a1,a2,a3+=3 on bottom of loop.
Fair. Sometimes, in Python I use enumerate, and in G’MIC I generally use iteration position too. In some cases, I do not care about iteration position.
Ok, let me explain a bit. In python, there is something like for i in "ABC" . This mean to loop within “ABC” and i is equal to each individual character. The point is to make code shorter.
In context of G’MIC, the proposed equilavent would be looping along arguments.
Python:
for i in "ABC":
print(i)
# A - First, print this char
# B - Next, this one
# C - Finally this
In G’MIC, you have things like $> and $<. So, G’MIC proposed equilavent would be:
That makes sense in Python because, the thing you put after the in can have different types : lists, strings, etc.
In G’MIC, there is not much typed variables. Basically every G’MIC variable is just a string, and other data are stored in images (or math evaluator variables, but those are values or vectors). We already have foreach or repeat to loop over all possible images, and eval to (quickly) loop over image pixels.
For instance, if I take your first example, looping over a sequence. It could written as:
foo :
(1,2,3,4,5,6) # Sequence of numbers
l. {
s x,-2 # Separate data into multiple 'items' of size 2.
foreach { # Loop over those multiple items
e "Forward : "{$>,^}
e "Backward : "{$<,^}
}
}
For a loop over each characters of a string, you can do the same, or use eval for faster operations (if the operations are simple enough to be expressed through the math evaluator).