"when" for one or "when" for all

[motib]

One of my simplest VPL programs (likes.aesl) is behaving weirdly. I finally figured out that the change from "if" to "when" had an unexpected consequence. There are four pairs: not detect center -> stop detect center -> move forward detect right -> turn right detect left -> turn left

Consider: I place my hand in front of the right sensor and the Thymio turns right; then, I remove my hand and I expect that it will stop, but it doesn't. Apparently the "when not detect center" means that the Thymio will only fire this event when the center sensor changes from detect to not detect.

It would make things much more intuitive (for me, at least...) if the "when" were checked when a change occurred to any one of a group of events: all front sensors, all rear sensors, all bottom sensors, all buttons.

[ddoak]

Notice (as I just did!) that if you try to test this with the thymio-vpl-tutorial files from https://www.thymio.org/en:visualprogramming it will not work as the files have the old aesl code (i.e. using 'if' rather than 'when'). It is necessary to edit (or delete and replace) the VPL blocks to generate 'when' aesl code.

[motib]

Sorry ... when I have a boring day I'll update the aesl files ....

[ddoak]

This is a tricky issue - the changes introduced to resolve #446 and #452 have made some things more intuitive and some things less so.

One could argue that in this case it is down to the user to explicitly catch the "when not detect xxx" by including all the forward sensors in their event block :

Although this might be seen as slightly less intuitive (for the beginning user) - it doesn't involve implementing a hidden rule (i.e. the 'when' monitoring an extended group of sensors)

I don't know what the right answer is - for VPL beginners it is desirable that their initial experience is as intuitive, predictable and rewarding as possible.

For further discussion, consider this example of counter-intuitive VPL behaviour.

The following VPL code is confusing because although the sound is triggered on pressing the forward button there is no colour change to red (even if the button is held).

The generated aesl code reveals that the top leds are always set to green :

onevent buttons
when button.forward == 1 do
    call leds.top(32,0,0)
    call math.copy(notes[0:5], [440, 524, 440, 370, 311, 370])
    call math.copy(durations[0:5], [7, 7, 14, 7, 7, 14])
    note_index = 1
    note_count = 6
    call sound.freq(notes[0], durations[0])
end
call leds.top(0,32,0)

Perhaps it would be more appropriate if the "empty" button event block was interpreted to mean explicity false for all button states :

onevent buttons 
when button.forward == 1 do
    call leds.top(32,0, 0)
    call math.copy(notes[0:5], [440, 524, 440, 370, 311, 370])
    call math.copy(durations[0:5], [7, 7, 14, 7, 7, 14])
    note_index = 1
    note_count = 6
    call sound.freq(notes[0], durations[0])
end
when ((button.forward == 0) and (button.backward == 0) and (button.left == 0) and (button.right == 0) and (button.center == 0)) do
        call leds.top(0,32,0)
end

[ddoak]

@motib - re. aesl tutorial files

Sorry, my intended point was more that asebastudio should reparse the VPL immediately on loading the file - not that you should have to go round slavishly re-saving all the tutorial examples to update them!

At the moment version changes in asebastudio can have unintended confusing behaviour for legacy files.

Maybe this should be logged as a separate issue?

[stephanemagnenat]

There is a conversion when loading from VPL 1.3 to VPL 1.4, but it does not treat the "if"/"when" change. It is probably not so trivial to handle that. Moreover, Moti's aesl where updated for 1.4 but before the change from "if" to "when" was introduced.

Retrospectively, it seems that it was a bad idea to do this change late in the release cycles. I am sorry for the additional work/stress. @motib do you think you can update the tutorial to have all examples working with "when"?

[motib]

I'll make an effort to find the motivation to do this. Although I think that we will run across many more programs that will suddenly show weird behavior :-(.

[riedo]

Quick feedback i got in a workshop yesterday: A girl programmed her robot to move forward when she put her hand in front of it, and to stop if nothing was detected underneath (to stop at the edge of the table) Then, she said "my robot does not stop at the edge" Indeed when she showed me she would put her hand in front of the robot and try to attract it, but as she moved her hand it went in and out of the detection zone; when reaching the edge the robot would stop briefly but start again because it detected her hand anew, and it fell off the table.

Her impression was that the ground sensor command had lower priority and asked if we could give it a higher priority. I told her we cannot and explained about the when / if, but in her perception it was counter-intuitive.

Then she said "so how can I fix it?" I had an "uuuuuuuuuuuuh" moment and then told her to make Thymio drive backwards when detecting the table edge (phew!).

My conclusion to this little story is that while "when" is well appreciated for the buttons events, the IR sensors are often expected to use "if" conditions by the users I met.

[stephanemagnenat]

While discussing the problem of biased execution in case of ambiguity (see aseba-community/thymio-vpl2#116), we realised that the if/when question becomes less of a problem when multiple events can be used as conjunction and ambiguity is properly handled.

In the case you report, you would have two lines:

• something underneath AND hand => forward
• nothing underneath => stop

This would work both with if and when.