Looping Input Tunnels!

[altenbach]

When autoindexing on a WHILE loop input tunnel, we get the default value for the datatype after we run out of elements on the autoindexing array. I can think of several scenarios where it would be useful to simply start over with the input array.

I propose a new input tunnel type (looping) which would do exactly that: index the elements to the end of the array, then start over from the beginning, ad infinitum (or until the loop stops).

(The same would of course also be useful for FOR loops. Here it would not be used to determine the loop count, because it never runs out of elements.)

Here's how it could look like in the code. (On the right, I show explicit functional equivalents).

[altenbach]

> can you enumerate some of the use cases ...

1. A simple signal generator running for long times. Simply "circular index" over an array containing the basic waveform until the loop is stopped. (Could even be useful in FPGA).
2. If we need to alternate between two cases with every iteration (e.g. even/odd) we could simply "circular index" over an array containing two booleans, a true and a false. Simpler and less obscure than ([i]Q/R(2) -> R eq? 0) or (([i] AND 1) eq? 0).
3. Same with three (or more) cases: "circular index" over an array containing three integers [0,1,2] or three enums.
4. ....

The functionally equivalent code on the right is often seen in one form or another, here in the forum and in many of my own programs. 😉

[fabric]

I'm still on the fence as to whether this specific use case warrants a BD syntax change... The explicit code is not exactly unwieldy... What would be more interesting IMO is if *ALL* array primitives had an option for circular indexing. Now THAT is something I would vote for. 🙂

[_Y_]

A great idea. However, such a tunnel could cause a lot of human errors. I suggest making the tunnel larger (size of a shift register) with an obvious symbol.

[Ray.R]

circular indexing gets my vote

[Manzolli]

The "circular indexing" name looks good. I think that a better contrast would make easier to differentiate between the current indexing. Since "circular indexing" is getting a lot of votes, how about this representation:

[sbus]

I initially thought this a good idea; but you can accomplish the same thing by nesting  your loop in an outside loop to repeat the process; visually this is MUCH clearer because the termination condition is now specified in the outside loop and you can have a separate termination condition for the inside loop.

And yes, I can see why this is useful in some cases where separating termination conditions isn't necessary; it saves you from coding the outer loop. If it were implemented, it could simply be a boolean property of autoindexing tunnels: "Repeat?".

[X.]

I would agree with that, but for another reason. Right now, I have a hard time seeing any difference between any of the proposed icon designs and the original one. There is graphical programming and then there is micrographical programming. I'd rather stick to the former.

[_Y_]

I do not agree with last two comments (if I understand them correctly, of course:).

First, any good programming practice dictates avaiding multiple nested control structures.

Second, such a soulution could not be suitable in such a common case where a loop gets two (or more) array inputs: one long loop-controlling and second short with "circular indexing".