Let's get rid of the For-loop, the While-loop, and the Timed loop

[SteenSchmidt]

Hello (again),

Well, this idea has haunted me for a couple of years, and now I think it's time to break it. I feel the For-loop, the While-loop, and the Timed loop are so similar that they are begging for a merger. It would simplify, and with a little thought strengthen, the API, to have a single configurable Loop Structure instead. What's the difference between a While-loop and a For-loop with a conditional terminal anyway? Have you ever wished for iteration timing information being available inside your For-loop (I know I have)? "Oh but those structures have been around forever, we can't touch those"... Well, what happened with the stacked sequence structure? Please read on for a minute or two and tell me if I'm losing my marbles here. And please chip in with your own modifiers, since LabVIEW is growing in (sometimes unnecessary) complexity. Thus:

Instead I propose the Loop Structure which when initially drawn looks like this:

The above is basically a loop running forever (don't worry, you can stop it), but it can be modified to do many many other things, just be patient . One feature of the loop structure is the box in the upper left corner, which is quite similar to what we have in a For-loop today. This will, no matter the configuration of the loop structure, always show the current iteration setting of the structure. By default that is never-ending, but if you drag in a conditinal terminal you change the loop behavior to a While-loop (note that I suggest a simpler way to get to the terminal than via the right-click context menu):

Arrays can be wired to the structure border as usual to give a For-loop like behavior. The count terminal changes from "Inf" to an "N" to indicate that it's a finite albeit at edit-time unknown number of iterations:

You can wire out of the count terminal inside the loop structure as usual to get the count at run-time of course. If the iteration count can be deducted at edit-time a number will appear instead of the "N":

This number is blue to indicate that it is automatically calculated. You can just type in a new number if you wish to run a different number of iterations, in which case all the usual ideas on this Idea Exchange about what should happen to auto-indexed tunnels apply. If you override the count manually the number will be in black text:

You can of course combine different exit conditions, in this case a fixed number of iterations with a conditional terminal wired as well for possible early exit:

The automatically calculated count terminal aids in determining if the loop actually runs the desired number of times:

All the usual stuff about tunnels, shift registers and so on apply to this structure as well, but on top of that it can also be configured as you're only used to within a timed loop. Consider how valuable some of these parameters and settings could be for ordinary loops, for error handling and for timing for instance. But the main feat is that this is still the same loop structure - it will simplify the palette a lot:

And now an additional feature that ties some of the parameters from the timed structure together with ordinary loops: this loop structure is event-enabled! I propose stuff like this (we're only scratching the surface with this image):

It's late where I am now, so I'll stop now, but all of the above makes it extremely easy to do things you simply can't do today - what about a Priority Structure?:

So, is it time to consolidate the ever-evolving loop code of LabVIEW into one structure to rule them all?

Cheers,

Steen

[NickNZ]

Interesting Idea.

But have you considered output tunnels?

One of my issues with For loops is that when N = 0, default data is returned. So if you wire a reference (or any variable) through a For loop, and it executes 0 times, you end up with a NULL ref of the datatype default value. This is a big trap for newbies (I fell for it). In C for example, if a For loop does not run, its doesn't set all variables inside to their defaults. The easiest way around this is a shift register that passes the value though if N=0.

Hence on a For loop I believe that an output tunnel should look like a case structure tunnel's default look. This would remind the programmer that you could get default data if N happens to be 0. Now this is where your suggestion gets tricky - in the case of the current (Do)While loop - it will always be valid without a shift register. However a For loop may not be valid. By merging both loops - it now has to be treated as maybe invalid.

If I can add two suggestions:

1) if you can merge in a case structure to handle the N=0 case - so default values can be wired through or you can add special code to deal with N=0. In the example above I could have a "no files to process" message box.

2) In all suggestions where the for loop replaces "N" with a value I have only ever seen 2 digit values. How about 1000 loops? Your iteration square is now a rectangle.

So what would my two suggestions merged with yours look like?

I am concerned that people might night like 1..N at the top of the loop when the "i" terminal counts from 0. Is this an issue?

The advantage of having a 0 case in the loop, and a compiler that can calculate N, is that the compiler could generate a warning if there is nothing in the 0 case, and there are tunnels leaving the loop.

Nick

[Manzolli]

Liked the idea of having a morph among all flavors repetition structures. The visual difference should be something clear, easy, outstanding like different colors of the border. I never changed the color of any structure. I do think that in BD colors should be used to make understanding easier. No pretty stuff is needed in BD, leave it to the FP. Kudos!

[Teo7]

Sounds like an idea with potential... BUT.... If implemented NI must ensure that the structure variations are visually differentiated better than in the example images above.

We want to look at a For loop and instantly know it is a For loop! (by it's color and border shape) WITHOUT the need to look at the little square area illustrated above. I hope this makes sense.

[SteenSchmidt]

My idea here was to simplify a lot of stuff with loops - more or less all that is common between a For and a While loop today, while making some stuff possible that isn't today. Some of the latest suggestions here complicates matters unnecessarily.

@NickAct:

Unrelated to my idea, but: Yes, I've considered output tunnels and don't find anything wrong with them as they are today. For me it's completely obvious and intuitive that they act like they do if you run zero iterations of the loop, and that shift registers changes that behavior. LabVIEW behavior is quite equivalent to the C-experience, in as you cannot equalize an output tunnel (wire) with a variable. If you have a variable assignment inside a C-structure (a loop for instance), and skip that structure, the value of your variable doesn't get changed. The same with LabVIEW. If you have a local variable assignment inside your loop, but run zero iterations of that loop, your local variable does not get updated. If you have an output tunnel from a loop in LabVIEW, that's not a variable, that's basically a (new) wire value assignment. Run the loop zero times and the best LabVIEW can do is to assign the data type default value to that wire. The only other alternative would be a runtime error, or perhaps a null value (which there isn't much of in LabVIEW).

There is no logical linking between an input tunnel and an output tunnel. Not even when they are alligned horizontally and share a common data type. Using a shift register instead of tunnels does two things: 1) it makes a 1:1 binding of this input with that output, and 2) it actually refers to the input wire value and uses that memory location to continously update it's value (that's why zero iterations maintain the input value - it didn't get changed). Two completely different beasts. And if inexperienced LabVIEW programmers gets bitten by this, well, that's because they're inexperienced. These things are what turns them into experienced LabVIEW programmers. I like correct solutions, even when they force you to stop and consider how the world works, more than I'd favor a flawed implementation to protect blissful ignorance.

Regarding your case pages they are really overcomplicating things in my view. If you need varying behavior it's much better with a case structure inside the loop structure, instead of being forced to have the case selector on the 99% of loops that execute the same code in each iteration.

@Teo7:

I'd definetely want the loop to just stay a loop, as I'm specifically suggesting not differentiating between a For- and a While-loop anymore. Why force pulling a somewhat useless and maybe even false hood over a structure that's just a loop? Just get used to looking at the "N-box" for a clue to when this loop could be expected to stop. Consider stepping beyond thinking in For- and While-loop terms. You don't gain more information about when a loop really stops by knowing that it started its life as a While-loop. It could run 2 times or it could run forever. Just as a For-loop might do (well, those are usually upper bounded, but they could still run N times or escape much earlier). Today you'd have to examine the code inside the loop to know, no matter if the structure border signals "While" or "For".

The structure border could just be gray of course, and then you should just look for the infinity symbol in the "N-box" to recognize true While-behavior, else it is a For-like loop. Pretty simple.

/Steen

[Intaris]

@Steen, your explicit mention of WANTING to make the different loops look similar I cannot support.

The intentions of the loops are different and hiding this is not an improvement, no matter how aesthetic and elegant you might find the "super loop".

[SteenSchmidt]

So of these two you'd prefer the lower one, even though it's more of a While-flavor operation (in this case there's just two parameters to the 'While' part; two numbers being equal or running out of subjects)?:

/Steen

[AristosQueue (NI)]

Steen: Yes, I would prefer the lower one. Why? Because there is something fundamentally different between a loop that must run at least once and a loop that might run zero times. That difference changes every tunnel interaction, changes entirely the interpretation of what my eyes are telling me when I look at the conditional terminal and color how fast I can scan a function overall to determine what it is doing. An array going into a while loop is more likely doing some sort of random-walk-through data thing and a for loop is more likely doing a linear traversal. And I can pick up really subtle details about your code instantly just by your choice of loops. If I have to sit there and contemplate "is this loop a searcher or a traverser and could it execute zero times?" then I am much less effective at absorbing code I've never seen before.

[SteenSchmidt]

Ok, so it seems there's a majority (at least of those who are vocal here) in favor of keeping two different structure borders. I assume that'd mean the border should automatically change then, when the input/configuration parameters change, to reflect the current execution behavior of a given loop?

I sense that neither the LabVIEW community nor NI is really in a place where such a radical paradigm shift is able to gain much momentum.

/Steen

[Manzolli]

Seem obvious to me, in a graphical language, that any change in the execution behavior must, as much as possible, be reflected in the diagram appearance. One very good example of this are the data type in wires. Reals are orange, integers are blue. But if I want to figure out what kind of integer it is, there is no graphical difference among then. The basic idea of having a morphing loop is great, but the graphical differences are a great help.

I f this come to LV, I think that all current icons (and its graphical representation) should be kept in the tools palette.

Bottom line: liked the concept of a morphing loop, but keep the advantages of the graphical differences.

[Intaris]

I'm with manzoli on this.  Morphing is OK, but visual differentiation must be clear.

In the visual representaitons shown above by Steen, the upper system shouts "Watch out for infinite loops" whereas the lower one says "Chill bro, all is under control".