Greetings!
While attempting to create a simple “object avoidance” program for the GoPiGo, I ran into several issues that are either enhancement requests or bugs - you decide.
Assume that {. . . .} defines a simple “dimple-nipple” (in-line) block in bloxter and [. . .] is a replaceable value block of some kind.
First:
This is definitely an enhancement request, (though I think it’s a design bug. . . .)
Issue:
There needs to be a simple “return” block for use within a function. At present there is no way to return from within a function, (not counting the end-of-function return), without it being a logical block.
The current implementation within advanced bloxter is of the form:
{if [value] then return [value]} A simple return can be implemented by using “if [true]”
There should be two additional forms that do not include any conditional processing:
- {return} (An unconditional, immediate return which can be defined as {return [null]} if necessary.)
- {return [value]} (An unconditional, immediate return passing [value] as it’s return value.)
Issue:
It is not possible to delete a variable once it is created.
If you inadvertently create a variable in advanced bloxter, and it is not needed, you cannot delete it, despite there being a “delete variable” option if you click on the variable in the tool pane.
Issue:
Similar to the above, it is not possible to delete, (or change the type of), a function after it’s created.
Case 1:
You inadvertently create an unneeded function, perhaps by double-clicking “create function”. It is not possible to remove the superfluous function. Not only that, but it can, and does, appear within your program workspace, even though unused.
Case 2:
You create a function of one type, (for example, not returning a value), and you discover that your function needs an end-of-function value return. You can neither destroy and re-create, nor change the type of, the function once created.
Issue:
There is no way to gracefully “exit” program execution.
Example:
Assume a program like this:
{begin block}
A Bunch
Of Needed
Initialization
Steps Here
// I assume a "forever" loop is defined as a "while [true]" loop internally
While [true] // "forever" loop
do this
do this
do this
if [something]
do this
do this
[implied endif]
if [something else]
do this
do this
do this
[implied endif]
if [something exceptional happens]
break
[implied endif]
[implied endwhile]
[implied target of "break" outside the while-loop]
By definition, “break” exits the loop, but does not necessarily end the program. This is particularly obvious since there are both conditional loops that exit and allow the program to continue and unconditional loops, (“forever” loops) that don’t have a defined target for the loop’s exit point.
If, (for example), breaking out of a “forever” loop is undefined, then there needs to be a way to gracefully stop program execution. Even if this is defined, there will be times when indicating that the program has come to a logical end before the last statement has executed is an important program construct.
Another example is exception handling - a good programming practice that should be taught early on.
If a program can do a number of different things, and there are a number of different logical paths, it is good programming practice to include a “fall through” type of default that handles unknown or unexpected events. Since bloxter cannot throw or catch exceptions, they must be programmed for within the logic itself. Again, the only reasonable way to handle a particular type of exception may be to freeze the robot in it’s tracks and end execution.
Enhancement Request:
Because bloxter is designed to allow younger audiences to learn programming, and advanced bloxter is for programmers who may have outgrown basic bloxter, but aren’t being introduced to the raw power of Pure Python just yet. . .
AND!
Since teaching good programming practices (like program design, commenting code, and planning for exception handling), are essential and should be taught early, I would like to suggest the creation of a special, pre-defined advanced bloxter “function” called “on-exit”.
This function would be called by the program “exit” statement mentioned above, and can be used to gracefully end the program if not done another way.
E.g.
- Stop the robot. (if it is still moving)
- Return actuators (like servos) to a reasonable “neutral” position.
- Send any necessary serial or I2c messages to sensors you’re using to turn them off. (Assuming you had to turn them on in the first place)
- “Close” Dexter’s “eyes” - or set them to a particular end-of-program color pattern to indicate the program’s ending status.
What say ye?
Jim “JR”
