<p>On a different note, it is much more effective to use simulated robot environments when first <em>introducing</em> programming to students.
The addition of the H/W elements in physical robots (along with more complicated software environments) make the combination more difficult. 
This would only be exacerbated with a short time line.</p>

<p>You could even replicate the physical nature of the robots in code before they work directly with them - giving them a sort of preview of the issues they will encounter.</p>

<p>Alternatively there are more user friendly robot development kits available today that you can look into.</p>

CC BY-SA 3.0
2018-02-22T15:51:22.860Z
2018-02-22T15:51:22.860Z
Mr Bradley
<p>What you are looking for is "old style" macintosh like event driven programming. It's still there under the covers in Windows, but the high level libraries tend to hide the implementation.</p>

<p>Your main event loop:</p>

<pre><code>quit = false;
while (!quit) {
    event = getNextEvent();
    dispatchEvent (event);
}
</code></pre>

<p>An event is a data structure that contains what, where, and when, plus supporting data. For example keystroke from USB keyboard at 16:01:00.000, or packet received from network at ... .</p>

<p>getNextEvent () simply pulls the next available event off of a queue.  In the original macintosh I believe they used a circular queue implemented on an array of pointers. </p>

<p>getNextEvent may actually call polling routines, or the event queue may be populated by asynchronously.</p>

<p>dispatchEvent is a wrapper around a big "switch" statement. A typical form would be something like this:</p>

<pre><code>switch (event.source)
{
case KEYBOARD: 
    dispatchKeys(event);
    break;
case MOUSE:
    dispatchMouse(event);
    break;
case ....

}
</code></pre>

CC BY-SA 3.0
2018-02-22T04:26:03.507Z
2018-02-22T04:26:03.507Z
pojo-guy
<p>To add some context from the <a href="https://chat.stackexchange.com/rooms/59174/conversation/about-cseducators-question-4353">chat room conversation</a>: This is part of <a href="https://chat.stackexchange.com/transcript/message/42998617#42998617">a larger course</a> that introduces <a href="https://chat.stackexchange.com/transcript/message/42998616#42998616">technology in an applied fashion</a>. The segment with the <a href="https://chat.stackexchange.com/transcript/message/42998511#42998511">robot is 10 days and the students have not necessarily programmed elsewhere</a>.</p>

<h2>Empty <code>while</code> loops</h2>

<p>I would recommend against beginning with <em>any</em> empty loops for your students.</p>

<p>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 <em>other than</em> what it was designed for. If the loop is being placed so that you can <em>add</em> functionality later, at least replace the comment so that it is clear <em>something</em> is planned for inside the loop later. If you are using the PLTW "Natural Language" module, and start with the function</p>

<pre><code>waitUntilDistanceSensorLessThan(200)
</code></pre>

<p>you can expand the lesson by replaceing that with the loop:</p>

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

<p>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 <em>put</em> something there, even if it just flashes the LED as the robot advances to the target.</p>

<h2><code>while</code> vs <code>until</code></h2>

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

<pre><code>set(testCondition);
while (testCondition == TRUE) {
    doThisFunction();
    doSomeOtherFunction();
    update(testCondition);
}

do {
    doThisFunction();
    doSomeOtherFunction();
    update(testCondition);
} until (testCondition == TRUE)
</code></pre>

<p>Syntactically, the <code>until</code> loop is guaranteed to execute <em>at least once</em> and the <code>while</code> loop may not execute ever.</p>

<p>Many languages which do not have an <code>until</code> 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:</p>

<pre><code>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
}
</code></pre>

<p>and</p>

<pre><code>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:
</code></pre>

<p><sup>Source <a href="http://www.robotc.net/wikiarchive/Control_Structures" rel="noreferrer">RobotC Wiki: Control Structures</a></sup></p>

<p>That still leaves the <code>testCondition</code> 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 <em>not</em> done unless the test is true. "Until" implies that something <em>is</em> done unless the test is true. The <code>while</code> loop exits when the test condition is <strong>false</strong> (fails), the <code>until</code> loop exits when the test condition is <strong>true</strong> (passes). Using that, for a language which lacks the <code>until</code> control statement, the same functionality can be created by using a negative test. Thus <code>until (done)</code> becomes <code>while (notDone)</code>, or if the language uses this syntax, <code>while ( ! done)</code>. Thus <code>until</code>'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 <code>do {} while (! done)</code></p>

<p><strong>Note:</strong> Perl has taken the <code>while</code> vs <code>until</code> concept and extended it into the realm of the <code>if</code> statement by creating an <code>unless</code> test:</p>

<pre><code>unless (testCondition) {
    say "testCondition is FALSE";
}
else {
    say "testCondition is TRUE";
}
</code></pre>

<h2>Limited prior programming exposure</h2>

<p>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.</p>

<p>As made clear in one <a href="https://chat.stackexchange.com/transcript/message/42998470#42998470">comment in chat</a>, the students may not even understand the concept of <em>statement block</em> and there is precious little time to explain all the details of programming, let along all the possible variations. With the objectives of <em>awareness/excitement about career paths</em> 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 <code>waitUntilDistance....</code> line could be replaced with something like this:</p>

<pre><code>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;
</code></pre>

<p>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 <em>not</em> introduce new programming concepts.</p>

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

<pre><code>while (waiting-condition) {
  //empty loop
}
</code></pre>

<p><em>will</em> cause more students to stumble, and not necessarily later. The <em>emptiness</em> might make apprehending the <em>statement block</em> concept more difficult than it already is. I'm also not so sure you should even divert into the infinite loop of <code>while (true) {}</code> 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.</p>

CC BY-SA 3.0
2018-02-22T15:14:58.713Z
I think the 'while' and 'do until' examples need to have the termination condition flipped ...? The first does a task **while** a condition _remains_ true, the other does a task **until** the condition _becomes_ true.
Mr Bradley
CC BY-SA 3.0
2018-02-22T16:41:55.053Z
@MrBradley If the "examples" you refer to involve the motor movement, then they were copied as-is from the referenced web site. If you're referring to a different section, then I don't understand what you think should be "flipped".
Gypsy Spellweaver
CC BY-SA 3.0
2018-02-22T20:03:21.277Z
the first code block following while vs until above.
Mr Bradley
CC BY-SA 3.0
2018-02-22T20:53:39.880Z
@MrBradley with the possible exception of Python, which I don't know, the two loops are correctly written.
Gypsy Spellweaver
CC BY-SA 3.0
2018-02-23T21:56:17.043Z
@philipxy If either one has its test reversed then they they become operationally equivalent except for the timing of the test. The example then looses its demonstration of opposite effects for the same test condition.
Gypsy Spellweaver
CC BY-SA 3.0
2018-02-23T22:45:17.407Z
Thanks. From your comment it seems the intro to the examples does not make clear what is being demonstrated. From the intro one expects them to show the same thing in two ways. I suspect you are trying to show something like 'if we use one structure in a way that would be equivalent, but isn't because it doesn't invert the test, then we don't get something equivalent'. But that's vacuous, tortuous & torturous. Of course maybe that sentence is a straw man, but I'm not sure that an intro that explicitly says what you are trying to demonstrate can be otherwise.
philipxy
CC BY-SA 3.0
2018-02-23T22:50:47.273Z
@philipxy included in the answer is _The while loop exits when the test condition is false (fails), the untilloop exits when the test condition is true (passes)._ Seems explicit to me
Gypsy Spellweaver
CC BY-SA 3.0
2018-02-23T22:59:49.907Z
@philipxy Actually, what that example is _demonstrating_ is the typical syntax of both statements in languages which _do_ have both available.
Gypsy Spellweaver
CC BY-SA 3.0
2018-02-22T08:48:52.810Z
2018-02-22T08:48:52.810Z
Gypsy Spellweaver
<p>This answer will be a bit different, I hope, and more general. </p>

<p>Programming physical robots is inherently different from simple procedural test and command driven programming. It is essentially event driven with events happening outside the program but needing to be handled by it. Some of this sort of thing occurs in, say, Java when you write GUI code that must respond to external events asynchronously. </p>

<p>So, the first bit of advice, given this situation, is to teach them robot programming driven by asynchronous events. The RobotC language, while a small subset of C structurally, has an extensive library to handle such events. So, teach <em>that</em>, rather than trying to teach something else that sort of works. </p>

<p>My advice in general, is that if you have chosen, or been given, a language to teach, then <em>teach that language</em>, not some other thing. For example, don't try to teach Python thinking of it as just Java without braces. It is a different thing. </p>

<p><strong>However</strong>, if you don't like the language you have then one alternative, assuming you have a bit of time and freedom, is to create a different language that is more to your liking. You can't do this in the next few days, as it takes a while to build the infrastructure, but it isn't impossible. You can define a language and write a compiler for it. The target (output) language could be RobotC so that you get automatic access to the libraries provided. High level to high level compilation is a bit easier, in fact, than high to low level language compilation as you can take advantage of the (higher level) features of the target language in your "code generator". It adds a step to program creation (compiling the resulting RobotC code) but that can be automated. If your language is well defined then you can use standard compiler building tools to make the job easy. Scanners and Parsers are standardized building blocks. </p>

<hr>

<p><strong>However</strong>, (the final however) if you can't make that work for you and you have limited time, then <em>first</em> focus on the language as given, respecting the intent of the creators of the language and teaching students how to use it well. Make sure that they understand the concepts of that language and the environment for which it is intended. But save a day or two at the end for a "beyond the horizon" look at programming. In that final wrap up session, you can talk about the limitations that were imposed by the language you've been using and some ideas (for their future study) that can be used to remove those limitations. So you <em>close</em> by opening another door for them. And this has much less chance of confusing them or burdening them with awkward constructs. </p>

<p>Your students won't be happy with you if they later learn that you were using a given language badly, even if you have good intentions. You can't teach them everything they will need to know in just a few days, but you can do a few things well. KISS = Keep it simple, students. </p>

<hr>

<p>An easy to use compiler builder suite is <a href="http://www.ssw.uni-linz.ac.at/Coco/" rel="nofollow noreferrer">CoCo/R</a>. You define a language as an Attribute Grammar (ATG) and the tool creates a scanner and parser from the ATG. You need to provide a semantic analyzer and code generator, but you can annotate the ATG to simplify this. The input language defined in the ATG needs to be (largely) LL(1), but a learning language should have that characteristic in any case. The tool will give you an analysis of your language as well. I've made extensive use of CoCo/R both in teaching and in building such "bridge" languages. And building your first compiler is a joy beyond joy. </p>

CC BY-SA 3.0
2018-02-22T16:31:05.210Z
2018-02-22T21:49:07.153Z
2018-02-22T21:49:07.153Z
Buffy
<p>Is it problematic to teach students to use an empty <code>while</code> loop to create an <code>until</code> loop? If so, what learning progressions avoid the problem? The question is an empirical one, but reasoned hypotheses and evidence would both be welcome.</p>

<p><strong>Background and Context</strong></p>

<p>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. </p>

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

<p>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.  </p>

<p><strong>The problem</strong></p>

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

<pre><code>while (waiting-condition) {
  //empty loop
}
</code></pre>

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

<p><strong>One example of a learning progression that seems to do better</strong></p>

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

<pre><code>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; 
    }
}
</code></pre>

CC BY-SA 3.0
2018-02-21T17:36:55.077Z
I guess I'm confused. Your first example doesn't seem to allow other robot actions unless "waiting_condition" is quite complex. It reads like a blocking wait. The second example doesn't  seem to have any break at all, unless an exception (or similar) happens elsewhere. Can you clarify? Do I need to get the RobotC specs to understand this?
Buffy
CC BY-SA 3.0
2018-02-21T20:25:32.083Z
I confess that I am also a bit confused about what you're asking.
Ben I.
CC BY-SA 3.0
2018-02-22T00:04:16.773Z
It looks more like you're trying to create event-driven functionality using flow-control statements. It also looks like you are trying to take the vestigial components of one program and extend them into something more than they can do. When the tool no longer serves your purposes, find a better tool.
Gypsy Spellweaver
CC BY-SA 3.0
2018-02-22T03:00:07.293Z
I'm looking for the right example and practice tasks to create a guided inquiry cycle that will optimize student understanding of loop and conditional constructs using this platform. I'm also looking for greater insight (or something in the literature) to understand how this paradigm and context affects students new to CS.
Bennett Brown
CC BY-SA 3.0
2018-02-22T03:00:12.733Z
Gypsy helps me understand what to look for; the tasks that students come up with are state-based and event-driven. An example task might be, "after a button is pushed, drive forward until a line taped on the floor is reached, then follow the line to the right." Students who first learn about loops and conditionals using this approach (I think) conceive of loops and conditional differently than the students who first learn about loop and conditional structures, say, traversing and conditionally altering image pixels.
Bennett Brown
CC BY-SA 3.0
2018-02-22T03:19:10.133Z
@BennettBrown Would you care to join the [chat room](https://chat.stackexchange.com/rooms/59174/the-classroom) to discuss this question some?
Gypsy Spellweaver
CC BY-SA 3.0
2018-02-22T11:45:36.363Z
Some of the stuff in @GypsySpellweaver's answer (from the chat, really) should really be integrated directly into this question.
Ben I.
CC BY-SA 3.0
2018-02-22T15:24:04.980Z
@BennettBrown Typically, instructors set up an exercise scaffold that the students can work with to complete their tasks.  The scaffold allows the students to experience some aspect of the environment without the risk of going off the rails.  Additionally, the instructor can use the scaffolding to focus on the learning objectives and hide distracting details or mechanics.  This can be done by creating a library that is more readily usable by your students to accomplish set tasks.
Mr Bradley
CC BY-SA 3.0
2018-02-22T15:32:31.773Z
@BennettBrown In your example waitUntilDistanceSensorLessThan(200)  the robot is performing an action (moving)  external to the code (that is the software is not continuously sending a move_forward command), and receiving input from the sensor regarding distance that is being continuously checked. You (probably) cannot perform any actions until you arrive at your destination.  If you wish to have some means of controlling the robot while it is travelling you would need to integrate the check for request with the sensor loop.
Mr Bradley
CC BY-SA 3.0
2018-02-22T15:36:36.967Z
@BennettBrown Because your robot is performing asynchronous actions  (moving, sensors, etc.) you are seeing code examples in the form of "do this forever" while(true), as these are common techniques in these kinds of environments.  These ideas are worth exploring with your students as part of your class and will help provide a context for why the code is structured as it is.
Mr Bradley
CC BY-SA 3.0
2018-02-22T15:41:20.347Z
@BennettBrown A good example for the basis the asynchronous nature of the robots is to place a "pit" or "non-detectable obstacle" between it and the sensor limit. The robot will never reach its goal (sensor check) and can't be stopped (motor is running).  Both of these things are happening on H/W circuits that are independent of the S/W instructions. 
It occurs to me that the designers probably already have some form of support for "interrupting" the execution of your running program -- as these kinds of errors are common.
Mr Bradley
CC BY-SA 3.0
2018-02-22T16:53:06.667Z
@MrBradley Maybe you can collect these comments and work them into your answer. I believe that these are good points, and information that apply to the question's objective. Comments _are_ subject to being cleaned up, and the list is often collapsed (I had to expand the list just to see the ones I new were here), while an answer does not suffer from those issues.
Gypsy Spellweaver
CC BY-SA 3.0
2018-02-23T22:04:18.140Z
While & until are sequential control structures orthogonal to concurrent behaviour control. While vs until is a sequential programming semantics issue. Do not teach concurrent programming until sequential programming is understood. "Busy waiting" (your empty loop) is a notion that is part of the complex topic of concurrent execution model semantics & implementation. Learn & use the underlying concurrency model of particular libraries/languages for concurrent behaviour control.
philipxy
<algorithms><robotics><pltw>
How to avoid misconceptions about while loop when using null loop
# How to avoid misconceptions about while loop when using null loop

(Asked by: username_0 on 2018-02-21)

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&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 & assigns them as an output
while (true) {
    if (sensorValue[alertButton]) {
        sensorValue[LED] = 1; 
    }
}

**Tags:** algorithms, robotics, pltw

> **Comments:**
> **username_1**: I guess I'm confused. Your first example doesn't seem to allow other robot actions unless "waiting_condition" is quite complex. It reads like a blocking wait. The second example doesn't  seem to have any break at all, unless an exception (or similar) happens elsewhere. Can you clarify? Do I need to get the RobotC specs to understand this?  
> **username_2**: I confess that I am also a bit confused about what you're asking.  
> **username_3**: It looks more like you're trying to create event-driven functionality using flow-control statements. It also looks like you are trying to take the vestigial components of one program and extend them into something more than they can do. When the tool no longer serves your purposes, find a better tool.  
> **username_0**: I'm looking for the right example and practice tasks to create a guided inquiry cycle that will optimize student understanding of loop and conditional constructs using this platform. I'm also looking for greater insight (or something in the literature) to understand how this paradigm and context affects students new to CS.  
> **username_0**: Gypsy helps me understand what to look for; the tasks that students come up with are state-based and event-driven. An example task might be, "after a button is pushed, drive forward until a line taped on the floor is reached, then follow the line to the right." Students who first learn about loops and conditionals using this approach (I think) conceive of loops and conditional differently than the students who first learn about loop and conditional structures, say, traversing and conditionally altering image pixels.  
> **username_3**: @BennettBrown Would you care to join the [chat room](https://chat.stackexchange.com/rooms/59174/the-classroom) to discuss this question some?  
> **username_2**: Some of the stuff in @GypsySpellweaver's answer (from the chat, really) should really be integrated directly into this question.  
> **username_4**: @BennettBrown Typically, instructors set up an exercise scaffold that the students can work with to complete their tasks.  The scaffold allows the students to experience some aspect of the environment without the risk of going off the rails.  Additionally, the instructor can use the scaffolding to focus on the learning objectives and hide distracting details or mechanics.  This can be done by creating a library that is more readily usable by your students to accomplish set tasks.  
> **username_4**: @BennettBrown In your example waitUntilDistanceSensorLessThan(200)  the robot is performing an action (moving)  external to the code (that is the software is not continuously sending a move_forward command), and receiving input from the sensor regarding distance that is being continuously checked. You (probably) cannot perform any actions until you arrive at your destination.  If you wish to have some means of controlling the robot while it is travelling you would need to integrate the check for request with the sensor loop.  
> **username_4**: @BennettBrown Because your robot is performing asynchronous actions  (moving, sensors, etc.) you are seeing code examples in the form of "do this forever" while(true), as these are common techniques in these kinds of environments.  These ideas are worth exploring with your students as part of your class and will help provide a context for why the code is structured as it is.  
> **username_4**: @BennettBrown A good example for the basis the asynchronous nature of the robots is to place a "pit" or "non-detectable obstacle" between it and the sensor limit. The robot will never reach its goal (sensor check) and can't be stopped (motor is running).  Both of these things are happening on H/W circuits that are independent of the S/W instructions.  It occurs to me that the designers probably already have some form of support for "interrupting" the execution of your running program -- as these kinds of errors are common.  
> **username_3**: @MrBradley Maybe you can collect these comments and work them into your answer. I believe that these are good points, and information that apply to the question's objective. Comments _are_ subject to being cleaned up, and the list is often collapsed (I had to expand the list just to see the ones I new were here), while an answer does not suffer from those issues.  
> **username_5**: While & until are sequential control structures orthogonal to concurrent behaviour control. While vs until is a sequential programming semantics issue. Do not teach concurrent programming until sequential programming is understood. "Busy waiting" (your empty loop) is a notion that is part of the complex topic of concurrent execution model semantics & implementation. Learn & use the underlying concurrency model of particular libraries/languages for concurrent behaviour control.  

---

## 4 answers

### Answer by username_3 on 2018-02-22. Score: 5

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.

> **Comments:**
> **username_4**: I think the 'while' and 'do until' examples need to have the termination condition flipped ...? The first does a task **while** a condition _remains_ true, the other does a task **until** the condition _becomes_ true.  
> **username_3**: @MrBradley If the "examples" you refer to involve the motor movement, then they were copied as-is from the referenced web site. If you're referring to a different section, then I don't understand what you think should be "flipped".  
> **username_4**: the first code block following while vs until above.  
> **username_3**: @MrBradley with the possible exception of Python, which I don't know, the two loops are correctly written.  
> **username_3**: @username_5 If either one has its test reversed then they they become operationally equivalent except for the timing of the test. The example then looses its demonstration of opposite effects for the same test condition.  
> **username_5**: Thanks. From your comment it seems the intro to the examples does not make clear what is being demonstrated. From the intro one expects them to show the same thing in two ways. I suspect you are trying to show something like 'if we use one structure in a way that would be equivalent, but isn't because it doesn't invert the test, then we don't get something equivalent'. But that's vacuous, tortuous & torturous. Of course maybe that sentence is a straw man, but I'm not sure that an intro that explicitly says what you are trying to demonstrate can be otherwise.  
> **username_3**: @username_5 included in the answer is _The while loop exits when the test condition is false (fails), the untilloop exits when the test condition is true (passes)._ Seems explicit to me  
> **username_3**: @username_5 Actually, what that example is _demonstrating_ is the typical syntax of both statements in languages which _do_ have both available.  

---

### Answer by username_1 on 2018-02-22. Score: 2

This answer will be a bit different, I hope, and more general.

Programming physical robots is inherently different from simple procedural test and command driven programming. It is essentially event driven with events happening outside the program but needing to be handled by it. Some of this sort of thing occurs in, say, Java when you write GUI code that must respond to external events asynchronously.

So, the first bit of advice, given this situation, is to teach them robot programming driven by asynchronous events. The RobotC language, while a small subset of C structurally, has an extensive library to handle such events. So, teach *that*, rather than trying to teach something else that sort of works.

My advice in general, is that if you have chosen, or been given, a language to teach, then *teach that language*, not some other thing. For example, don't try to teach Python thinking of it as just Java without braces. It is a different thing.

**However**, if you don't like the language you have then one alternative, assuming you have a bit of time and freedom, is to create a different language that is more to your liking. You can't do this in the next few days, as it takes a while to build the infrastructure, but it isn't impossible. You can define a language and write a compiler for it. The target (output) language could be RobotC so that you get automatic access to the libraries provided. High level to high level compilation is a bit easier, in fact, than high to low level language compilation as you can take advantage of the (higher level) features of the target language in your "code generator". It adds a step to program creation (compiling the resulting RobotC code) but that can be automated. If your language is well defined then you can use standard compiler building tools to make the job easy. Scanners and Parsers are standardized building blocks.

---

**However**, (the final however) if you can't make that work for you and you have limited time, then *first* focus on the language as given, respecting the intent of the creators of the language and teaching students how to use it well. Make sure that they understand the concepts of that language and the environment for which it is intended. But save a day or two at the end for a "beyond the horizon" look at programming. In that final wrap up session, you can talk about the limitations that were imposed by the language you've been using and some ideas (for their future study) that can be used to remove those limitations. So you *close* by opening another door for them. And this has much less chance of confusing them or burdening them with awkward constructs.

Your students won't be happy with you if they later learn that you were using a given language badly, even if you have good intentions. You can't teach them everything they will need to know in just a few days, but you can do a few things well. KISS = Keep it simple, students.

---

An easy to use compiler builder suite is [CoCo/R](http://www.ssw.uni-linz.ac.at/Coco/). You define a language as an Attribute Grammar (ATG) and the tool creates a scanner and parser from the ATG. You need to provide a semantic analyzer and code generator, but you can annotate the ATG to simplify this. The input language defined in the ATG needs to be (largely) LL(1), but a learning language should have that characteristic in any case. The tool will give you an analysis of your language as well. I've made extensive use of CoCo/R both in teaching and in building such "bridge" languages. And building your first compiler is a joy beyond joy.


---

### Answer by username_4 on 2018-02-22. Score: 1

On a different note, it is much more effective to use simulated robot environments when first *introducing* programming to students.
The addition of the H/W elements in physical robots (along with more complicated software environments) make the combination more difficult.
This would only be exacerbated with a short time line.

You could even replicate the physical nature of the robots in code before they work directly with them - giving them a sort of preview of the issues they will encounter.

Alternatively there are more user friendly robot development kits available today that you can look into.


---

### Answer by username_6 on 2018-02-22. Score: 1

What you are looking for is "old style" macintosh like event driven programming. It's still there under the covers in Windows, but the high level libraries tend to hide the implementation.
Your main event loop:
quit = false;
while (!quit) {
    event = getNextEvent();
    dispatchEvent (event);
}

An event is a data structure that contains what, where, and when, plus supporting data. For example keystroke from USB keyboard at 16:01:00.000, or packet received from network at ... .
getNextEvent () simply pulls the next available event off of a queue.  In the original macintosh I believe they used a circular queue implemented on an array of pointers. 
getNextEvent may actually call polling routines, or the event queue may be populated by asynchronously.
dispatchEvent is a wrapper around a big "switch" statement. A typical form would be something like this:
switch (event.source)
{
case KEYBOARD: 
    dispatchKeys(event);
    break;
case MOUSE:
    dispatchMouse(event);
    break;
case ....

}


---

