I’m working on a small, dynamic language that isn’t going to include bitwise operators so I was thinking it was a bit unnecessary to use && and || for logical operators when I could just use & and |.
Is there evidence, from empirical studies or the experience of other languages exploring this space, that an unconventional choice of operator is going to confuse users or lead to errors, to simply be irrelevant, or to have flow-on implications for the programmer experience?
Many languages which have && and || (or otherwise) as short-circuiting logical operators also have & and | for the eager operators.
You can see a list here, but some notable languages include C, C#, Java, JavaScript, Objective-C, Perl, PHP, Python, R, Rust and Swift. The same list doesn't show any languages which use & and | as short-circuiting operators, though apparently Oberon has & and OR.
Breaking conventions isn't necessarily bad; but if you do want to have & and | as your short-circuiting operators, then you will have to consider whether you also want eager operators, and if so what they should be ─ and if it is really worth violating expectations by giving your short-circuiting operators the syntax usually used for eager operators.
Also keep in mind when designing a language that you have a limited strangeness budget, which is usually better spent on things which make your language semantically or paradigmatically different to other languages, rather than on syntax.
& and | aren't simply eager, but bitwise rather than logical. If anything, I would say they're defined to be eager simply because it would be impractical, confusing or ill-defined to have a lazy bitwise operator - given that the bits of the operands would be determined "in parallel" by a single operation.
$\endgroup$
Commented
Oct 12, 2023 at 10:24
True & False is False, not 0 - even though in Python bool is a subtype of int and True is equal to 1. Similarly in C#, Java, JavaScript and so on true & false is false.
$\endgroup$
true & false in the Chrome console and it was 0.
$\endgroup$
bool overloads the bitwise operators to return bool when both arguments are bool. But in order to determine the types, it has to evaluate them eagerly.
$\endgroup$
+ operator" or "the & operator" works perfectly fine, or if an English word is needed (e.g. when naming the token in the lexer) it could be "plus" or "ampersand". In most occurrences you know the types of the operands so it is more useful to say "concatenation", "bitwise and", "intersection", etc., even if technically the operator would do something else were the operands different.
$\endgroup$
K and Q use & and | for logical AND and OR (actually, for infix min and max, but that's besides the point).
APL and its derivatives use the proper formal logic symbols ∧ for conjunction and ∨ for disjunction.
J uses *. and +. because it sees AND and OR as the logical equivalents of multiplication (*) and addition (+).
(J and some APLs actually extend AND and OR to LCM and GCD, but that's besides the point.)
Is there evidence, from empirical studies or the experience of other languages exploring this space, that an unconventional choice of operator is going to confuse users or lead to error
To my mind, | and & can be confused with the Unix operators for pipes etc. in shell scripts, which coexist with the logic operators || and && therein. Using || and && avoids this confusion for those who do shell programming a lot.
But you don't have to be compatible with shell scripts. Some languages use # for comments. Others don't.
I've actually seen a programmer confused by & -- he was expecting it to be an arithmetic operator in an "if" condition, and in context it was a string append operator.
It compiled without error -- there was implicit string conversion and a logical test on the result -- and it scanned ok -- there was an & where he expected to see it -- it just didn't evaluate as expected.
Cross-language interference is expected. If anyone other than yourself is going to use the language, I'd try not to make it any more difficult than necessary.
(Personally, if I was designing a language, I'd use the FORTRAN logic operators, not the c or APL operators, but I'm a left-handed touch-typist.)
.AND., .OR., etc.? I think that style of operator, in lower case and with leading and trailing whitespace, would be a very good feature, especially if there were different words for related but different purposes (rounding integer-result division, versus Euclidian, truncating, etc. and of course floating-point-result division).
$\endgroup$
&&and||were added to C as a kind of compromise, because&and|were already taken in BCPL and B, which used them as both logical and arithmetic operators. It’s obviously well established as a convention by now, but apart from familiarity, there’s no strong reason to follow that precedent, especially if bitwise operations aren’t so central to the language. $\endgroup$andandor? $\endgroup$