-
Notifications
You must be signed in to change notification settings - Fork 23
Description
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.