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

[PaulG.]

This is a radical step but I'm all for anything that will make programming easier. We are already able to combine loop functions with a conditional terminal in the for loop so this makes logical sense to move in this direction. Kudos.

[dthor]

First of all, very nice job on the visuals in this post. Methinks you used something a little more sophisticated than MSPaint... The Idea as a whole is well thought out and presented.

As for the actual Idea, I really like it. I think the Loop Events is a little far-reaching, but I could see it as something implemented after the core of this is (if it gets implemented, that is).

A few questions / comments:

1. The timed loop: would removing the display cause it to act like a normal loop again, or would it just hide the timing information and still be a timed loop?
   My vote is that it turns back into a normal loop.
2. The N terminal: what is displayed when there is an array constant (size 42 in example) and an unknown-sized array?
   I think there are two options here:
   N: OK and gets the point across - the compiler can't determine the size of the loop at edit time.
   N/42: Tells the user that the loop will run N or 42 times - whichever is smaller.
3. This would have to be rolled out slowly. If NI just went through in 2014 and removed the normal For/While/Timed loops, I think there would be a lot of confusion and possibly code breaking. How do you feel about adding this for a few years and then hiding the old loops deep in the pallets after that?

Overall though, I like it. So, kudos!

[vitoi]

The more I think about it the more I think it's important to maintain the visual cues between the While Loop and the For Loop. They allow quick recognition and help convey the programmer's intent.

I have never had the desire to switch a while loop to a for loop or vice a versa.

I would however not mind seeing the timed loop merged with the while loop. These are intercahangeable both in function and concept.

[Intaris]

OH, I HAVE had the desire to mporph a for loop to a while loop and back.  This side of things I would enjoy.  Certainly a thumbs up for that aspect.

[altenbach]

I often convert between FOR loops, while loops, and timed loops, and this is already easy with a simple right-click. So why do we need this???

The current loop designs have some graphical flaws, for example (1) the FOR loop right and bottom boundary is significantly thicker than the top and left boundary. (2) the boundary of the timed loop is way too thick for my taste. (3) The [N] terminal of a FOR loop is locked to the upper left corner but the [i] terminal can be placed anywhere, etc.

So, Yes! A redesign would be welcome. Each loop flavor should be easily reconizable as we currently have, but there should be more common elements and easier ways to logically switch between them during editing. (See also)

There are a lot of functionalities that don't overlap between the three, e.g. the timed loop can be assigned to a processor, the for loop can (sometimes) be parallelized, etc. The autoindexing default behavior differs between while and for loops, etc. Can these be more uniformly applied to all loops?

WIth this idea, we would simply have a "loop", and the exact flavor can be easily adapted at edit time. For the most part, we already have that.

My Kudos is more along the lines that this all should be discussed. Not necessarily that I fully agree with the current suggestion in all details. (e.g. Most of the time, the array size is only kown at run time, so displaying an iteration number automatically is typically not possible). 😄

[SteenSchmidt]

I can definetely understand the reluctance to move away from such well known entities as the For and While loop structure artwork, but the functionality itself doesn't disappear. I'm in part asking if we really can rely on the For and While graphic to tell us the behavior of the loop? Or do we risk mistaking an actual For-loop implementation disguised as a While-loop and vice versa? In the latter case it might be better with just a single loop structure, and then one common behavior identifer - for instance the counter box (Inf, N, number, conditional glyph etc.).

Ok, I can't force anyone to accept the premise that one solution or the other will be more misleading, that would take a more thorough test group study to uncover. But that aside, a single structure would almost certainly be simpler to maintain for R&D and easier to fine tune for the programmer, than three or four structures that in many ways are similar but then not at all in certain aspects. Just as the different Write File primitives have different performance as a consequence of when they were implemented (IIRC 'TDMS Write' is faster than 'Write Binary' because 'TDMS Write' uses a more efficient algorithm for instance), I'm inclined to believe that some of the common traits of these structures may in fact be very different in implementation, and thus hard to maintain, hard to change, and different in performance. This is speculation though.

@GregS: For- and While-loop behavior does not by itself define if the loop can be unrolled or not. A While-loop could just as easily be parallelized in chunks as a For-loop, depending on what it contained (but I don't know if LV unrolls While-loops). This is actually one more artificial destinction. The destinctive trait for possible parallelization is, as you yourself point out, inter-iteration dependency. And I think that that sort of dependency would be better illustrated by the ability to have a P terminal in the loop or not, instead of by the programmer's possibly arbitrary choice of implementing the loop as either a For- or While-loop. Just think "I need a loop, and I'll see if it'll run in parallel, so I attempt to enable the P-terminal":

@Intaris & vitoi: So, maybe we could learn to distinguish the loop behavior just be looking at the counter box (or maybe I should call it Behavior terminal)? Examples:

Infinite loop.

While-loop.

For-loop with iteration count determined at runtime.

For-loop with conditional cop-out (or would you call this a While-loop today, even though it's found in a For-loop structure?).

For-loop with iteration count determined at edit time.

For-loop with conditional cop-out.

For-loop with constant (user specified) iteration count.

One of the pitfalls I've seen with loops is when someone enables auto-indexing on an array tunnel on a While-loop, expecting that to terminate the While-loop when the array runs out of elements. Well, that doesn't happen on a While-loop as we all know of course (right?). That While-loop isn't turned into a For-loop by changing the tunnel behavior. But with my suggestion here it would. And that would be evident by a change in the Behavior terminal. It would of course be possible to have additional visual cues if that seems better, like structure border color changing to emphasize certain behavior - but it's important that this is still one single structure, not different structures:

1) For-loop, 2) While-loop, 3) Loop with timing configured

       

@dthor:

1. Hiding the timing configuration display from a timed loop should keep the timing configuration. Just like parallelism configuration, I see timing configuration being a configuration of the Loop Structure itself - no matter if the configuration values are currently visible/settable by wire or not. I'm not suggesting a new way to turn one loop structure into another (Timed<->While by Showing<->Hiding the timing configuration), but instead I'm suggesting a way to merge the current loop behaviors into a single structure leaving all (most) possibilities/combinations open. Why not being able to configure timing for a For-loop? That'd make it simple to output a binary pattern with a given bitrate for instance.

But maybe we need a visual cue to tell if timing has been enabled or not. If not the changed border color, then perhaps a glyph by the behavior box?:

For-loop with timing specified.

2. Whenever the compiler can't determine the iteration count at edit-time I think it should display N. It would quickly turn into a mess trying to convey too much info here. If it was N/42 some people would probably focus on N seeing simply "some large number" and others might focus on 42 being surprised when the loop stops at 30. If it just says N then stopping at 42 is just as acceptable as any other number (up til 42). I could maybe live with <=42, but I'm not too fond of that really (makes me think of a limit or a test case, and some people would probably balk at a mathematical expression when the idea is that it should be lightning quick to grasp).

3. I agree that a new structure like this should be rolled out slowly, gradually moving the replaced structures out of the limelight.

/Steen

[dthor]

---

SteenSchmidt said:

"But maybe we need a visual cue to tell if timing has been enabled or not. If not the changed border color, then perhaps a glyph by the behavior box?"

---

Yes, that would be sufficient for me. The only thing I'm scared of is someone hiding the timing information and there not being some glyph that yells "Hey, I'm a timed loop guys!"

Border coloring works too, but the colors would need to colorblind-friendly. Personally, I prefer all the same color (you chose a nice blue, I like that blue) and just having the timing glyph

RE my question #2:

Just displaying N works for me.

[SteenSchmidt]

---

@altenbach wrote:

My Kudos is more along the lines that this all should be discussed. Not necessarily that I fully agree with the current suggestion in all details. (e.g. Most of the time, the array size is only kown at run time, so displaying an iteration number automatically is typically not possible).

---

But you still suggested this .

/Steen

[altenbach]

This is a control as opposed to an indicator. 😉

[Ironman99]

I've been the first one kudoing this idea. But more comment I read, more I am with /Steen

I think that the main goal here is "helping LV programmers to focus on what they want to achieve, instead of how to achieve it". This goal may involve changing some habits, but for a better final experience of use (so for a better LV).

Obviously the actual implementation could be very different from the one suggested by the author (and very well explained and showed, I must say).

But, for my personal taste, it seems to me already almost "perfect"...

May I add a second kudos?