So when I click on a predicate block and when I click on the true/false switch in the result of the block, it switches to the opposite state, but when I try to switch in a variable monitor or speech bubbles from sprites, it doesn't work.
First, as this script reports the Boolean, click on the Boolean result and it should switch. Now hover your mouse over the watcher and click the Boolean in the watcher. It does not switch. Next move the mouse to the bubble the sprite was speaking, and switch the Boolean, it doesn't work.
It makes sense for it yo not allow you to switch it in a speech bubble, however it could be useful to be able to switch it in a variable watcher, maybe it could allow the user to toggle between values, much like the slider variable watcher type that allows the user to specify a variable value.
Currently, you can assign a list to a variable, and make a sprite say the list variable, and if you edit the list in a speech bubble it also affects the variable. So, it should be the same for Booleans too.
There is a difference with lists and booleans. Lists are passed by reference, which basically means that they can be modified anywhere and any instance of the list will also be modified (look up linked lists on the forum). Booleans are different, because they're passed by copy, which means that if you set a variable to a boolean, then set a different variable to the first variable, then modify the second variable, the first variable will not be changed, like numbers and strings (text).
It makes sense as to why you can modify a boolean in a list, because the list has values that can be modified. A speech bubble is not a variable watcher or list item, so they don't usually modify a value (only lists can be modified, because the item is a value in the list). I'm saying it does make sense to be able to toggle a boolean in a variable watcher, because that is representing data that can be read by the code (unlike a speech bubble).
Yes. It's sort of an accident of history that list watchers are mutable. It's something we inherited from Scratch, I think, where mutation is the official programming style for lists, as opposed to our preferred functional style in which you don't mutate them but instead make modified copies (maybe actually sharing some memory, but in functional programming that doesn't matter). Note that table-style list watchers don't allow mutation, which makes it much faster to maintain their displayed value.
One problem with that is that you might have more than one watcher for the same variable, so Snap! would have to chase down all the other ones whenever you change one. This isn't an insuperable problem but it's one reason this hasn't been a high priority for us.
