Tagless encodings help to minimize the space for encoding the arguments to an e-expression. The tagless types in the spec right now focus on encoding values that have an opcode followed by additional data. However, I think boolean values represent an opportunity as well.
Assuming that we can create a macro-shaped parameter using a macro that itself has no parameters, here is an example of how one could create a 2-bit representation of a boolean value.
(macro true_flag () true)
(macro my_configuration (true_flag::$is_foo_enabled?
true_flag::$is_bar_enabled?
true_flag::$is_baz_enabled?
true_flag::$is_quux_enabled?)
{
foo: (if_single $is_foo_enabled true false),
bar: (if_single $is_bar_enabled true false),
baz: (if_single $is_baz_enabled true false),
quux: (if_single $is_quux_enabled true false),
}
)
And then one could invoke this macro in text and binary, respectively:
(:my_configuration () (:) () (:))
00000000 00 01 00 01
\______/ ^ ^ ^ ^
| | | | └ One argument
| | | └ Zero arguments
| | └ One argument
| └ Zero arguments
Opcode 00 - macro with address 0
The text representation is not very human-friendly because we are abusing the absence/presence of an argument to indicate whether the value should be true or false. In binary, we get 4 arguments represented in only 1 byte (via the argument encoding bitmap).
We should consider adding an official, non-hacky way for users to achieve this. Perhaps we could define a special tagless type called bool_flag that can only be used with ? or ! cardinalities. Then, in text, it can accept true and false, and in binary, it can be encoded using the argument encoding bits:
| Bits |
Meaning |
| 00 |
void |
| 01 |
false |
| 10 |
true |
If #330 is adopted, then we could instead say that bool_flag parameters must always be ! and we can simply use 0 for false and 1 for true, which is a truly minimal encoding for boolean values.
Tagless encodings help to minimize the space for encoding the arguments to an e-expression. The tagless types in the spec right now focus on encoding values that have an opcode followed by additional data. However, I think boolean values represent an opportunity as well.
Assuming that we can create a macro-shaped parameter using a macro that itself has no parameters, here is an example of how one could create a 2-bit representation of a boolean value.
And then one could invoke this macro in text and binary, respectively:
The text representation is not very human-friendly because we are abusing the absence/presence of an argument to indicate whether the value should be true or false. In binary, we get 4 arguments represented in only 1 byte (via the argument encoding bitmap).
We should consider adding an official, non-hacky way for users to achieve this. Perhaps we could define a special tagless type called
bool_flagthat can only be used with?or!cardinalities. Then, in text, it can accepttrueandfalse, and in binary, it can be encoded using the argument encoding bits:If #330 is adopted, then we could instead say that
bool_flagparameters must always be!and we can simply use0forfalseand1fortrue, which is a truly minimal encoding for boolean values.