How to avoid misconceptions about while loop when using null loop Is it problematic to teach students to use an empty while loop to create an until loop? If so, what learning progressions avoid the problem? The question is an empirical one, but reasoned hypotheses and evidence would both be welcome.

Background and Context

Several thousand US middle schools and several thousand US high schools have VEX robotics equipment and RobotC licenses as contractual vestiges of Project Lead The Way (PLTW) engineering programs for middle and high schools. RobotC is a proprietary language from an institute associated with Carnegie Mellon University. 

RobotC does not have an until (condition) do {} structure. 
http://www.robotc.net/forums/viewtopic.php?f=55&amp;t=3059 . The PLTW curriculum uses a "Natural Language" module of RobotC that includes wait-until functions like waitUntilDistanceSensorLessThan(200), but these cause the robot to be incapable of responding to input during the wait-until statement. 

In the middle school where I am teaching, my predecessor assembled the VEX kits into  "squareBots," a design suggested by VEX and RobotC. The robot is equipped with two motors driving left and right sides of an eight-inch square chassis, equipped with a set of sensors. The robotics equipment engages kids, but the RobotC language has inherent problems pedagogically; this question is about one such problem in particular because I think the question is more broadly applicable than just RobotC.  

The problem

To implement a wait-until algorithm capable of executing other code while waiting, I've tried teaching the idea to use

while (waiting-condition) {
  //empty loop
}


I have wondered if more students stumble with later more complex programs when I introduce the empty loop as the students' first experience of while statements. I intend to set up an experiment to verify this anecdotal observation and am fishing for ideas about the two treatments to compare. 

One example of a learning progression that seems to do better

For example, I think students do better with later, more complex programs if, before using the empty while as a wait-until, they modify an infinite while loop such as 

sensorValue[LED] = 0; 
//VEX uses LEDs in sensor ports and configures &amp; assigns them as an output
while (true) {
    if (sensorValue[alertButton]) {
        sensorValue[LED] = 1; 
    }
}
To add some context from the chat room conversation: This is part of a larger course that introduces technology in an applied fashion. The segment with the robot is 10 days and the students have not necessarily programmed elsewhere.

Empty while loops

I would recommend against beginning with any empty loops for your students.

All the looping constructs are best understood when presented in manner that fulfills the purpose they were created for. An empty loop, using any of the available constructs, is using the loop for a purpose other than what it was designed for. If the loop is being placed so that you can add functionality later, at least replace the comment so that it is clear something is planned for inside the loop later. If you are using the PLTW "Natural Language" module, and start with the function

waitUntilDistanceSensorLessThan(200)


you can expand the lesson by replaceing that with the loop:

while (sensorValue[distanceSensor] &gt;= 200) {
  // Things to do while the robot moves closer
}


That way you are not presenting an "empty" loop, but one that is planned for a purpose, and that purpose just happens to be "to be determined." Don't leave it that way either, but fill it with something real before executing the program. The comment line is showing the development process of changing the first version into a useful version. The next step is to then put something there, even if it just flashes the LED as the robot advances to the target.

while vs until

Some programming languages have an until control statement, others do not. Many of those which have both a while and an until separate their usage by having the while test the condition before the loop executes, and the until tests its condition after the loop executes. In hypothetical syntax they are commonly like this:

set(testCondition);
while (testCondition == TRUE) {
    doThisFunction();
    doSomeOtherFunction();
    update(testCondition);
}

do {
    doThisFunction();
    doSomeOtherFunction();
    update(testCondition);
} until (testCondition == TRUE)


Syntactically, the until loop is guaranteed to execute at least once and the while loop may not execute ever.

Many languages which do not have an until control statement still provide for testing before or after execution of the loop. In the case or RobotC, the language of this question, the syntax is like this:

while(SensorValue(sonarSensor) &gt; 20)  // while the Sonar Sensor reads data greater than '20':
{
    motor[rightMotor] = 50;               // run 'rightMotor' at power level 50
    motor[leftMotor]  = 50;               // run 'leftMotor' at power level 50
}


and

do
{
    motor[rightMotor] = 50;  // run 'rightMotor' at power level 50
    motor[leftMotor]  = 50;  // run 'leftMotor' at power level 50
    bursts = bursts + 1;     // increment 'bursts' by 1
    wait1Msec(3000);         // wait for 3000 milliseconds before continuing
}while(bursts &lt; 3)         // while 'bursts' is less than 3:


Source RobotC Wiki: Control Structures

That still leaves the testCondition as an issue, however. Based on the English usage, from which most programming languages derive their meaning, "while" and "until" are opposites. "While" implies that something is not done unless the test is true. "Until" implies that something is done unless the test is true. The while loop exits when the test condition is false (fails), the until loop exits when the test condition is true (passes). Using that, for a language which lacks the until control statement, the same functionality can be created by using a negative test. Thus until (done) becomes while (notDone), or if the language uses this syntax, while ( ! done). Thus until's usage can be created when needed. In the case of RobotC it's even possible to create the common version of a tail-test by using do {} while (! done)

Note: Perl has taken the while vs until concept and extended it into the realm of the if statement by creating an unless test:

unless (testCondition) {
    say "testCondition is FALSE";
}
else {
    say "testCondition is TRUE";
}


Limited prior programming exposure

All the above, absent the motor and sensor parts, really applies to any programming related course. It can even help prepare students for what they will encounter "in the wild" with other languages not covered by the course. The specifics of this question, however, with its short duration and unknown, but probably limited, prior programming by the students, creates extra concerns.

As made clear in one comment in chat, the students may not even understand the concept of statement block and there is precious little time to explain all the details of programming, let along all the possible variations. With the objectives of awareness/excitement about career paths in mind, planning ahead and having some of the desired variations pre-built might be helpful. For example, the first two code segments could be saved, and quickly "built" with the students. A third variation, which might be attractive to the students, is to have the LED flash faster as the distance closes with the target. Using guessed numbers for examples here, with numbers found to be useful in the lab replacing mine, the original waitUntilDistance.... line could be replaced with something like this:

int totalDistance = 500;
while (sensorValue[distanceSensor] &gt; (totalDistance/25)) {
  sensorValue[LED] = 1;
  delay(300 * sensorValue[distanceSensor] / totalDistance);
  sensorValue[LED] = 0;
  delay(200 * sensorValue[distanceSensor] / totalDistance);
}
sensorValue[LED] = 1;


That will give a duty-cycle of 60% and an initial frequency of 2 flashes per second, and a final frequency of 50Hz. Another chance to reinforce some math and science, increase the engagement with the robot, and not introduce new programming concepts.

In consideration of the limited time and limited programming exposure before this segment, I think that introducing the empty loop

while (waiting-condition) {
  //empty loop
}


will cause more students to stumble, and not necessarily later. The emptiness might make apprehending the statement block concept more difficult than it already is. I'm also not so sure you should even divert into the infinite loop of while (true) {} at all. If you do use the LED-alertButton combination you presented in the question, modify it to respond as a toggle rather than a one-shot that turns on and then appears to ignore all future button presses. The program might loop forever, but it will look to the students like it turns on the LED and then stops responding.