Swap bitwise with logical operators

[SheepTester]

Proposal

The shorter variants should be used for logical operators rather than bitwise operators as the former is used more often, so

• & | ~ are the logical AND, OR, and NOT operators, respectively.
• && || ! are the bitwise AND, OR, and NOT operators, respectively.

^ should also be reserved for exponentiation, so XOR can be something obscure like ^^.

Rationale

&, |, and ~ have roots that might be more recognizable. For example, & is used in English for "and," and ~ is used for negation in math. | is already used in some syntaxes for multiple options, like regex a|b. ^ is commonly used for exponentiation.

In addition, a single character is easier to type (though admittedly the impact of this is negligible), so it should be used for the operator that is used more often.

Duplicating the symbol for bitwise operators would be in line with the bitwise shift operators, >> and <<. Good thing existing languages don't do it the other way around!

[ky28059]

Add logical xor and xand too

[chop0]

This is a good idea; we could maybe take it one step further and combine some of them.
*& is logical AND in the case of comparing booleans, bitwise in terms of comparing bytes
*| is logical OR in the case of booleans, bitwise for bytes
*~ or ! is logical NOT for booleans, bitwise NOT otherwise

[SheepTester]

Ah, I see, kind of like how + is used for both concatenation and addition

[chop0]

@SheepTester I think types should be able to implement infix operators, like in rust.

[chop0]

test

[SheepTester]

@SheepTester I think types should be able to implement infix operators, like in rust.

Rust docs say that because and and or short-circuit, they don't have traits for them. However, at least for N, I think I'll make short circuiting a trait-defined thing. This has the benefit of not having to have something like or vs or_else for an optional/result monad.

[chop0]

@SheepTester Yeah, I'm going to include that in the next implementation of Aardvark; graal has made me mald too much, so I'm probably switching to rust or just vanilla java, at least for now.

[chop0]

On the other hand, I am a bit conflicted about making || kind of a special form; I'm going to be adding the concept of purity and pure functions to Aardvark, so I might make it so that || must have pure expressions on the left and right.

[SheepTester]

On the other hand, I am a bit conflicted about making || kind of a special form; I'm going to be adding the concept of purity and pure functions to Aardvark, so I might make it so that || must have pure expressions on the left and right.

Hmm, I feel like short circuiting would be rather necessary, especially in cases where it's used in recursion (though I can't think of why it'd be used directly in recursion), unless you're going to make expressions evaluate lazily? 👀

[chop0]

I might evaluate pure functions lazily. What do you mean by recursion?

[SheepTester]

I might evaluate pure functions lazily. What do you mean by recursion?

🙂

(define (any? pred ls)
  (and (not (null? ls))
       (or (pred (car ls)) (any? pred (cdr ls)))))

though admittedly one can just use if for those cases

[chop0]

🤔

[SheepTester]

Ah, explains 2020