With conditional short circuit operations for AND, OR, and XOR...we've struggled to find a good name for the bitwise operations. Previous thread on the topic: "Naming of bitwise OR, AND, XOR"
On the end of that thread I made a suggestion I want to bring up again, especially because we have a new option to make even the left hand side parameter convention change.
What if GROUP! on the right meant bitwise AND/OR/XOR?
>> #{FF00} and (#{FFFF})
== #{FF00} ;-- e.g. intersect #{FF00} #{FFFF}
>> #{FF00} and [#{FFFF}]
== #{FFFF} ;-- e.g. all [#{FF00} #{FFFF}]
There are competing needs in parameter convention on the left. Using the block form has come to need to let the left hand side complete, for instance to enable:
parse data rules or [...]
But the bitwise operators have historically acted like math ops.
add 1 2 or 3 => add 1 (2 or 3)
Doing both is now possible in the same function, due to "variadic left enfix". This is what facilitates the SHOVE operator
The operator can start running, inspect its quoted right hand side for blockness or groupness, and then decide what convention to use when requesting the left argument. This request can then run an arbitrary amount of evaluation, before returning to let the right hand side run (or not run, if not necessary, in the BLOCK! right hand side case). Since the right side was quoted, this won't run anything out of expected order.
Having the parameter convention vary is kind of a separate issue from whether the GROUP! form is bitwise. But it's worth pointing out that it can be done now.
It would make the GROUP! semantics seem more consistent
Right now the GROUP! on the right merely forces the result to a LOGIC!. It's still conditional and not bitwise.
And it's still a short-circuit operation...that means the right hand clause might not run, based on the left hand side.
Yet in general, when you see a GROUP! as an argument to a function (that isn't QUOTE) you expect it to execute. One thing about the bitwise operators is that they are not short-circuit, they always need to execute both sides to get a result.
Might this make it somewhat easy to explain? If you see a BLOCK! on the right hand side, it's the short-circuit form and might not run that clause...if you see the GROUP! it will run for sure, it's bitwise?
We can duck coming up with other names
I'm not 100% satisfied with and+ or or+. They aren't terrible. But they aren't stellar.
While it's a new idea to be facing, I think and (...) vs. and [...] are pretty easy to see the difference between. People will make mistakes, I'm sure. But of all the things in the language you might have to learn, the subtlety of "use a group if you mean bitwise" isn't the biggest hurdle.
It's weird, but what I kind of like about this "right hand side polymorphism" is that it's a new and uniquely Rebol-enabled idea.
Thoughts?