3
$\begingroup$

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?

$\endgroup$
2
  • $\begingroup$ I think it’s worth noting that && 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$
    – Jon Purdy
    Oct 15, 2023 at 16:19
  • 1
    $\begingroup$ Why not and and or? $\endgroup$
    – Pablo H
    Oct 17, 2023 at 13:50

4 Answers 4

4
$\begingroup$

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.

$\endgroup$
7
  • 3
    $\begingroup$ In the languages you cite (well, most of them, at least), & 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$ Oct 12, 2023 at 10:24
  • 1
    $\begingroup$ @KarlKnechtel They are bitwise when their operands are integers, but it does not make sense to talk about bitwise vs. logical operators when the operands are booleans. C of course doesn't have a specific boolean type, but most of the other languages do, and these operators work on that boolean type. Consider e.g. in Python the result of 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$
    – kaya3
    Oct 12, 2023 at 16:30
  • $\begingroup$ @kaya3 I just tried true & false in the Chrome console and it was 0. $\endgroup$
    – Barmar
    Oct 12, 2023 at 20:39
  • $\begingroup$ @kaya3 Python supports operator overloading, and 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$
    – Barmar
    Oct 12, 2023 at 20:42
  • 1
    $\begingroup$ @Barmar I find there is rarely a need to refer to an operator without reference to what it does, but "the + 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$
    – kaya3
    Oct 12, 2023 at 22:49
2
$\begingroup$

The APL family

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.)

$\endgroup$
0
$\begingroup$

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.

$\endgroup$
0
$\begingroup$

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.)

$\endgroup$
2
  • $\begingroup$ Are you referring to .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$
    – supercat
    Oct 18, 2023 at 18:16
  • $\begingroup$ The FORTRAN logic operators (including .EQ. ) were specifically different to the arithmetic operators, including the assignment operator ( = ). It did not have an extensive set of operators -- but it had a very large set of functions defined as part of the language. $\endgroup$
    – david
    Oct 19, 2023 at 1:24

You must log in to answer this question.