On 02/09/2018 06:47 PM, Nicolas Cellier wrote:
We also have a pair of binary messages that already works: ~= or even ~~
This is actually an excellent point.
Perhaps the extra inefficiencies from the proposed new xor: definition that Levente identified are acceptable, given that performance-critical code can just use ~= or ~~?
Being able to accept "a xor: b" as well as "a xor: [b]" seems like a win for consistency with the other spelled-out operators to me.
(We wouldn't need to change any existing usage, either, right? Since true and false both understand #value?)
None of the senders in the trunk image are remotely performance-sensitive, it seems to me, with the possible exception of a use in detecting a word boundary in the regex engine.
Tony