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

[SteenSchmidt]

One feature I envision not implemented in this structure is a Structure Name. The current Timed Loop does have a Structure Name, but that is a potential bughole as each structure must have a unique name or your application behaves oddly. Instead of functions referring to the structure by name (by reference), those functions should instead accept a structure reference wire (by value) which I have depicted as the Loop Event wire in main article of this idea.

So one could still envision a discrete API consisting of subVIs (like the current 'Synchronize Timed Structure Starts.vi' for instance), but you wouldn't input a Structure Name string to them, but a Structure Refnum (Loop Event) instead.

/Steen

[tst]

Despite my inner programmer screaming "what do you mean, no for and while loops?", I like the idea a lot (and voted for it) and I think I will be able to live without the visual distinction we currently have for the different types of loops (or at least have different distinctions), but I would like to say that the only way I would like to see anyone touching the for loop or while loop is if they can also stay simple. I have no problems with allowing the user to tack on options, but there should always remain the option of dropping a simple clean loop without all the visual noise.

[SteenSchmidt]

Agreed, the loop should be very simple when you drop it, for instance just like this:

That will automatically change into For-loop or While-loop like behavior as soon as you wire something to it, or decide to type something else in the counter box, or drag in the conditional terminal. I might consider having the variant with the conditional terminal already visible in the palette as well, as it might be fifty-fifty which one is used the most:

/Steen

[Intaris]

Hmmm.

I'm currently for and against this at the same time.  I wonder how we'll differentiate between for and while loops at first glance when viewing code?  This is an aspect of the visual differentiation which IMHO should not be overlooked.

I feel that the visual representation of the loop should be CLEARLY indicative of their mode of operation.

[SteenSchmidt]

Shane, that's my point reversed!

Why do we need to destinguish between a For- and a While-loop? What when we abort a For-loop early with the (albeit optional) conditional terminal? Why isn't there both a While and a DoWhile in LabVIEW? Even though the Timed Loop is a While-loop, it's not instantly recognizable as such. Etc.

Since we have all this blending and overlapping of the features, why not take the last step? Let's reduce the number of structures and enable some more features at the same time. Today we're still forced to look more than superficially at the code to determine the logic of any given loop, whether it's wrapped in a For- or a While-loop outline. A For-loop often exhibits While-loop behavior, and some ideas here on the IE travels even further in that direction. And similarly a While-loop can often exhibit For-loop like behvior, for instance when you count a number of unevenly interspersed summands that eventually lead to the exit condition - something that not easily translates into a For-loop without breaking the loop up into two parts.

Let's grab the bull by the horns and move to a single Loop Structure then, and make it easy to identify the termination qualifier (in my idea here that's given in the top left "counter box"). That's what sets the different loops apart, not if they initially started out as a For- or a While-loop.

On top of that new functionality (like event-enabling) would probably be more within reach of a new combined structure than getting the same functionality into several existing LabVIEW structures (less work, less noise, broader user benefit).

Seriously, I think the For-, While- and Timed loops are arbitrary choices. It could/should just as well be something else...

/Steen

[GregSands]

In fact, the While-loop is actually a DoWhile-loop - i.e. it always runs at least once.  Whereas a For-loop may run no times - a common source of questions to the Forums!

My initial thought is not to support this idea - even though there is much overlap functionally, I still think about them differently, and the visual cue helps.  The For-loop suggests a repeated operation over a set of data elements, of which the ability to parallelise is fundamental.  A conditional terminal is only used to stop that repitition early, say in case of an error.  Whereas a While-loop puts the emphasis on the termination test as the criteria to be satisfied, and therefore parallel execution does not make as much sense.

I think I could agree with everything else you said, if there was still the distinction between For and While, though I may have to think a bit longer to get my head around how Loop Events would be useful.

Having said all that, I always like your graphical design, and the elegance that you try to bring to LabVIEW.

[SteenSchmidt]

True about the DoWhile - it's actually While that takes an extra case structure or similar to implement. Sorry about that.

I definetely agree that there traditionally has been a very sharp destinction between For and While, but I find that destinction blurring a lot over the last couple of years as functionality increases. That slide is much harder to notice in textual programming as the keyword is either "For" or "While", even though a For-loop there could just as easily be a camouflaged While-loop (you could always break out of a For-loop for instance). In a graphical programming language like LV it's much easier to spot that functionality balance is changing, e.g. that a For-loop is looking more and more like a While-loop.

What I see especially changing the game in LV compared to textual languages is stuff like auto-indexed tunnels, i.e. scripted code generation. The equivalence of auto-indexing an array in LV would be auto-generating code with a macro in most textual programming languages, and that way you maybe wouldn't notice if your macro implemented a For- or a While-loop. The influx of ideas over the years of how to make auto-indexing more flexible tells me that LV programmers are looking increasingly for flexibility more than sticking with traditional tools. If we allow ourselves to ignore the For/While mutual exclusivity paradigm I think we can increase code effectiveness. I think For/While is an unnecessary destinction in a graphical programming language. We can obtain the proper level of logic feedback by inspecting the BD much easier than a textual programmer can from a set of linked text files. The textual programmer needs the For/While keywords much more than we do.

Basically I'd rather have very fine control of what terminates my loop, than having to try to adapt my algorithm to live under either a For-loop or a While-loop paradigm. I don't need that destinction, and it disappears (in LV) bit by bit.

About loop events; I run into especially three categories of problems where I would be empowered by having access to loop events:

1) Synchronizing the start of several loops, or programmatically defining when a single loop may start.

2) Remotely telling a loop when to stop, instead of having to implement some other sort of mechanism that typically operates in parallel to what the loop otherwise is operating on.

3) Error condition or "time-out" messaging for instance. Currently this again demands some sort of mechanism implemented that allows me to communicate this data out of the loop.

The above will typically be implemented using a Timed Loop, but sometimes you don't need the time control (just the timing features), and it still doesn't provide the messaging mechanism itself (usually my Timed Loops are born with a two-way queue in it to sort this out).

For sure, events are opposed to dataflow, but they can be a great time (and BD real estate) saver.

Thanks for the kind words about graphics . I for one would love to have the IDE event API opened up so I could improve the workflow on the BD. There are so many operations that demand too many button pushes or mouse movements, and so much info that is hidden. Much could be improved if the IDE was allowed to interact much more freely with the programmer, than the current passive context menu hierarchy + context help window dictates.

Cheers,

Steen

[GregSands]

I've just thought of some words which may make it easy to see why I think there should still be a distinction:

For-loop <=> Simultaneous (and therefore able to be in parallel)

While-loop <=> Sequential

I think retaining - or even enhancing - that difference, when used correctly, can provide hints to the compiler as well as the programmer as to what is intended.  LabVIEW tries to help out, such as determining when For-loop Shift Registers introduce dependence thereby preventing parallel execution, but a stronger distinction could be even more powerful.  I must say I'm guilty of using Shift Registers in For-loops, but hopefully only ever to work on independent slices of data &colon;)

[vitoi]

I think it's important to emphasis whether the programmer is conveying an operation that loops until a certain condition is fulfilled and doing an operation a fixed number of times (even if be can be terminated early). The visual reinforcement provided by the while loop and for loop are important and I think should be maintained.

What's the motiviation for merging them into one (save time, clarity, etc)?

[Intaris]

I agree that they could be merged to a single "structure".

I am strongly the opinion, however, that the visual distinction is a crucial part of the entire LV programming language.  For Loops are understandable with a lot less effort than while loops and the ability when scanning code to be able to say "simple", "simple", "ooh, I need to examine here" is something which would sorely lessen the value of LabVIEW if it should be missing IMHO.

In fact we have three different types of structures here.

Classic FOR-Loop with known and certain number of interations.

While loop with unknown number of iterations and defined stop criterium.

New FOR Loop with the ability to prematurely abort.

I think these represent three completely different intentions on the side of the programmer and it's very important to retain the ease of distinction between them without having to go "into detail" in analyzing the code.

Aside from the graphical representation, I find the rest very interesting.