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] >= 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) > 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 < 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] > (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.
