Naming of bitwise OR, AND, XOR


#1

The plain words OR and AND (and XOR, NOR, etc) were frequently desired to be made “conditional”:

CureCode 1879: Conditional Operators

Early on, Ren-C implemented this…as well as the notion that the prefix forms would be the behavior of INTERSECT, UNION, etc. (Then much later, it went down the path of how exactly to handle short-circuiting, which is its own topic…and it’s why you have to parenthesize the second argument of AND and OR.)

But the question came up of what to name the infix bitwise operations. What were chosen were or+ and and*…which were allusions to the symbols for the operations used in boolean arithmetic:

https://www.allaboutcircuits.com/textbook/digital/chpt-7/boolean-arithmetic/

But since that early decision, * has taken on a kind of special meaning…what one might often think of as “/ONLY” or the more “core” or fundamental version of an operation. (e.g. select [a 10 b 20] 'c gives back a BLANK! for convenience, even though that is conflated with select [a 10 b 20 c _]. It is built on top of select* which would give a void in the first case, and a blank in the second.)

select: redescribe [
    {Variant of SELECT* that returns BLANK when not found, instead of void}
](
    chain [:select* | :to-value]
)

This usage of * has become so pervasive in the naming scheme, that it makes and* seem misleading.

Hence I think or+ and and+ may be a better choice to say “the bitwise mathy or” and “the bitwise mathy and”, rather than bow to this kind-of-obscure use of symbolism from boolean math.

Haven’t changed it just yet, but plan to, unless anyone has better ideas.


Unifying bitwise AND/OR with short circuit AND/OR
#2

(1) and&, which is just as confusing as + (which should be v) and therefore perfect
(2) and^, since that is the actual mathematical symbol used for and


#3

We’ve discussed allowing escaping in WORD!, e.g. spaces^-between (I’m an advocate for ^- being space instead of tab, else it would be ^_), which would take away caret as a simple word character.

I’m still partial to moving to & for something, possibly characters to line up with HTML entities. It’s an ugly word character, and this would help with the extreme overloading of meanings for #:

if &c = first "cat" [
   print ["first character in cat" space &RightArrow space "c"]
]

#4

I actually quite like this, it helps you figure out the logic as you read it, but I see your point about * being used elsewhere.

+ makes the most sense to me, to give it a “mathy” look. I think all other characters have either been ruled out (here and in that ticket) or don’t give it that “mathy” feeling.

What about a different word? I think I still like + better, but throwing this out here …

band (bitwise and)
bor (bitwise or)


#5

To make it even more topical we could call them

bitand, bitor

and now to find a use for bitcoin


#6

I like bitand and bitor.
Then bitcoin should flip bits randomly?


#7

+1 for this, I like it.


#8

One of the goals of the change is that essentially:

 and+: enfix tighten :intersect
 or+: enfix tighten :union
 xor+: enfix tighten :difference

That is to say that these operations are the abstract mathematical concepts, like DIFFERENCE is the Symmetric Difference. When applied to scalar numbers, there’s no real other interpretation other than to think you mean it bitwise. But they’re not constrained to that, they work on sets too…

 >> [a b c e g] and+ [b e f]
 == [b e]

So putting “bit” in the name would suggest it’s more limited than it is.

For the moment I’m just switching AND* to AND+, but going ahead and getting the intended change committed, so the issues related to moving plain AND and OR to being conditional can march forward. (And killing the definitely-badly-named AND~, OR~, XOR~.) By all means, people can keep thinking about the relevant issues.


#9

To re-summarize the trick of today for plain AND and OR: achieving short-circuitness requires some kind of array on the right hand side of an AND or an OR. Given that an array needs to be there, the idea was that GROUP! vs. BLOCK! would give different behaviors.

 <left> and (<right>) => #[true] ;-- GROUP! means force result to LOGIC!
 <left> and [<right>] => <right> ;-- BLOCK! means act like `all [<left> <right>]`

…well, here’s something that didn’t come up yet–for some reason–to let the GROUP!'d form be UNION/INTERSECT-like. They work on LOGIC!, and now we have the nice word DID. Even in the worst case scenario that x and y aren’t LOGIC!, and neither of them already needed a NOT on them anyway, you’d have:

flag: did x and (did y) ;-- interpreted as `(did x) and (did y)`

So with this, we might be able to have our cake and eat it too. AND and OR could be synonyms for INTERSECT and UNION when used with a GROUP!, and act like ALL and ANY when used with a BLOCK!.

  • AND+ and OR+ are still kind of ugly and never really settled well
  • I’m not finding a huge need for AND/OR making LOGIC! variables
  • GROUP!s being used for COMPOSE means BLOCK! is often better for conditionals anyway
  • It would be a bit of a nod to historical Rebol

What would be a bit annoying about it is that the blocks have a chunky aesthetic on a conditional line:

if blah blah and [blah blah blah] [
    ...
]

if blah blah and (blah blah blah) [
    ...
]

But as I mention, you’ve got your DID and your NOT to let you use the second form if what you’re testing isn’t LOGIC! already.

I guess one must weigh it all in the balance, and if killing off AND+ and OR+ is worth it. Maybe? I imagine it would be more error-prone, which is probably a good argument against it. But just weird it hadn’t come up yet at all.