Add support for user declared boolean variables

[cor3ntin]

As discussed in #542 and #782 we need to add a way to declare and manipulate booleans types in the language.

We want to prevent implicit conversion from int to bool

[ypiguet-epfl]

You should be more precise by stating who we are. I'm not one of them. I disagree with the reasons invoked.

[davidjsherman]

To decide whether this is a good idea, it might be helpful to think through some of the consequences.

I am presuming that, for consistency, the intention is that boolean variables mimic integer variables as much as possible. So, a boolean variable can be an array, and the interval addressing notation should be the same. One could write flags[2:5] = [true, false, false].

I expect we would want native functions

1. boolean.any(A, B) sets bool A to true if any B[i] is true.
2. boolean.all(A, B) sets bool A to true if all B[i] are true.
3. boolean.first(I, B) sets integer var I to the smallest index i where B[i] is true.
4. boolean.less_than(A, B, C) sets bool A to the integer comparisons of var B with var C.

Thus to check whether any of the front proximity sensors are activated, one could write

bool levels[5]
bool trigger
boolean.less_than(levels, [400,400,400,400,400], prox.horizontal[0:4])
boolean.any(trigger, levels)
if trigger then
   ...

There are binary bytecode operations for shifting and binary arithmetic, so the compiler could pack boolean variables into 16-bit words.

[davidjsherman]

Furthermore, if boolean values are variables, then they can be communicated. The Aseba protocol specification as well as the DBus and HTTP interfaces specify that a Variable contains a number. If boolean values are encoded as numbers, then there must be type information in the node description so that the client knows how to treat those values. (I don't know whether this is considered a change to the protocol.) Alternatively, a new Boolean variable could be added to the Aseba protocol. (This is definitely a change to the protocol.)

[stephanemagnenat]

I agree with you @davidjsherman . As a rough analysis, adding boolean variables implies the following:

• concept: decide for an encoding for variable arrays, without much thoughts yet I feel that packed into 16-bit words in little endian is good. We might want to give it a little thinking though, as there is a trade-off between memory and opcode size in the question of whether we should pack boolean arrays or not.
• compiler: adding a type flag to the variable description struct.
• compiler: adding support code for boolean, including checking the type of expressions and assignations.
• msg: adding a type flag to the parameters of the natives functions and variable-related messages.
• studio: adding support for visualising and editing arrays of booleans, possibly allowing constants to be boolean.
• switch: add support for boolean over HTTP and DBus.
• msg and dump command line tools: boolean support.

As an additional note, if we add boolean I would be tempted to add explicit angle type as well. I created issue #785 to keep track of that discussion.

[stephanemagnenat]

Another fascinating issue if we bring packed array of booleans: containers. @davidjsherman added some month ago the deque container, and @shilingwang and I have in plan of adding the equivalent of unordered_set and unordered_map, but these would be for integers. This would speak for having unpacked arrays initially, and a bit-mask for every native function argument telling whether it is acceptable to pass a given type for this argument.