Naming of bitwise OR, AND, XOR

Development Naming
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.

Soliciting Ideas for a BITWISE Dialect
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+: infix tighten :intersect
 or+: infix tighten :union
 xor+: infix 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

7 posts were merged into an existing topic: Unifying bitwise AND/OR with short circuit AND/OR