Why is array access not an infix operator?

Question

The typical syntax for accessing an array (or list, map and similar data structures) at a specific index is a[i]. I believe C first introduced it as syntax sugar, though I wonder why it has stuck around when an alternative syntax could be a mere infix operator (something like a @ i), yielding back one precious pair of brackets for other use cases, such as generics (angle brackets knowingly being a hassle to parse).

This would intuitively make sense to me, as typically mixfix operators are rarely encountered otherwise in programming languages (exceptions being the function call and ternary operator). Yet I don't know a single language that would permit something along the lines of the following (Java-y):

// cities: Map<String, List<Inhabitant>>
cities @ cityName @ inhabitantIdx = new Inhabitant(...);

The only potential problem I can see is grouping (e.g., for accessing a member: (a @ i).field), though languages like Java already have a similar problem with the binary AND and OR operators (i.e. if ((field & mask) != 0) ...), and people get along with that just fine. What might then be the reason that programming languages throughout the spectrum have consequently stuck to this one single syntax for accessing arrays (AFAIK), when they're showing wild exploration in so many other areas?

Answer 1

The answer to "why" questions is often partly historical - unless there is a good reason to be different, following existing conventions helps limit a new language's "strangeness budget", and makes it more likely to succeed.

Using brackets for array dimensions goes back long past C, at least as far as the hugely influential FORTRAN and ALGOL, both designed in the late 1950s.

In these early languages, arrays were not considered a separate data type, and so accessing elements was not conceived as an operation with an array on one side, and a number on the other. Instead, both languages defined "subscripted variables", which could have multiple dimensions; the brackets contained the comma-separated list of "subscripts" into this multi-dimensional structure.

In the 1958 FORTRAN manual describes it thus:

A variable can be made to represent any member of a 1, 2, or 3-dimensional Subscripted array of quantities by appending to it 1, 2, or 3 subscripts; the variable is then a subscripted variable. The subscripts are fixed point quantities whose values determine which member of the array is being referred to.

And gives examples A(I), K(3), and BETA(5* J-2, K +2,L)

The preliminary report of the ALGOL committee from the same year, says:

3. Subscripted Variables V designate quantities which are components of multidimensional arrays.
   Form: V ~ I [ C ]
   where C ~ E, E, ~. . . . , E is a list of arithmetic expressions as defined below. Each expression E occupies one subscript position of the subscripted variable, and is called a subscript. The complete list of subscripts is enclosed in the subscript brackets [ ].
   The array component referred to by a subscripted variable is specified by the actual numerical value of its subscripts (cf. arithmetic expressions).

In other words, the mathematical notation $x_{a,b,c}$ translated to FORTRAN X(A,B,C) and ALGOL x[a,b,c]

Note also how this fits with using parentheses for function application - in both cases, you have an identifier offset from a list of arguments or subscripts.

It is only in later languages that multi-dimensional arrays are treated as "arrays of arrays" (or, in C's case, as a special case of pointer arithmetic), so that the list of subscripts is replaced by a sequence of operators, x[a][b][c]. By then, "array subscripts appear in brackets" was a well-established convention.

Answer 2

There are a couple of arguments in favour of the x[y] syntax for arrays, over an infix operator.

One is that we want array access to bind the left operand more tightly than the right operand. For example, in x + y[z] we want the access to have higher precedence than +, but in x[y + z] we want the opposite. An infix operator normally has the same precedence on both sides.

Another is that infix operators need to decide on associativity. Neither of x[y][z] or x[y[z]] is clearly a better choice in general for the meaning of x @ y @ z. Probably multidimensional array access x[y][z] is more commonly used, but left-associativity would mean the operator binds slightly looser on the left, contradicting the above. (That is, if @ is left-associative then x @ y binds where y is the right operand, instead of y @ z where y is the left operand.)

Both of these reasons can be summarised by saying that we would often need to use parentheses anyway to disambiguate usages of an infix array access operator; so we might as well make the parentheses part of the syntax, and then we don't need the additional symbol for an infix operator.

---

Another thing to consider is that in some languages, the "index" in an array access is not necessarily an expression. For example, many languages allow access to multidimensional arrays using commas like x[y, z] even when y, z is not a valid expression in those languages. There are also array slices like Python's x[y:z] or x[::-1], where y:z and ::-1 are not expressions.

In such languages, array access cannot be parsed the same way as a binary infix operator which expects expressions for both operands. However, languages which want to use an infix operator could get around this by allowing tuples and slices to be expressions.

Answer 3

it is, sometimes

In Haskell, array access is the binary operator !!.

In APL, one of the ways of doing array access is the dyadic function ⌷.

Answer 4

An single-dimensional array access is syntactically very similar to a single-argument function call; indeed, in some languages the syntax would be identical. The latter doesn't use any actual operator, but merely the juxtaposition of two expressions, the latter of which must be a parenthesized primary expression, without any explicit operator whatsoever. I suspect the use of square brackets in C was probably motivated by their use in earlier languages, but functionally a pair of square brackets behaves like a pair of parentheses preceded by an "add and dereference" infix operator.

In FORTRAN, the requirement that an array subscript appear in parentheses was likely motivated by a couple of considerations:

1. There needed to be a non-alphanumeric character between the array name and the index, because FOO BAR would have been styntactically equivalent to FOOB AR, FO OBAR, FOOBAR, or any other combination of those letters (in order) and intervening spaces.

2. The range of available non-alphanumeric characters was extremely limited: ., ,, *, /, +, -, $, ', =, (, ). I'm not sure what dollar sign was used for, and it might have been possible to have rules for the use of ' that would allow it to be used as an index in some contexts and a quoted string literal in others, but all of the other symbols were needed for other purposes.

Once FORTRAN established the convention of indexing by juxtaposition of an identifier and a parentheses-enclosed primary expression without using an intervening operator other than the opening delimiter, other languages likewise dispensed with the use of an intervening operator.

Answer 5

Another consideration not mentioned so far is that no readily available symbols had the right mnemonic value at the time these subscript syntaxes were devised.

@ (U+0040 at sign) typically meant “each at” or “at a rate of”, that is, a kind of multiplication. You can still find this usage on receipts: 2 apples @ \$1.35 is 2 apples × \$1.35/apple, or \$2.70. The “at a location” sense has become more common because it was repurposed for email addresses, and later Twitter-style username tags.

Likewise, # (U+0023 number sign) was often “pound”, which is still used in contexts like “100# paper” (100 pounds per ream) or the “pound key” on a telephone. If you want “sheep number n”, nowadays sheep # n is a fine choice, but ca. 1960 you would’ve been better off with № (U+2116 numero sign) as your glyph for a “number sign”. (In fact you still might—#X can be highlighted as a hashtag where №X gets left alone.)

Because of reliance on mnemonic value, it may also be unclear which operand order to pick:

• array @ index — in this array, the value at this index
• name @ host — the user by this name, at this host

Whereas an analogy with an existing notation, such as a mathematical subscript, reduces the chance for confusion.

Answer 6

K has both infix functional indexing and bracket indexing:

a: (1 2; (3 4 5; 6 7))  // nested list
a@0  // 1 2
a[0] // 1 2
a@1  // (3 4 5; 6 7)
a[1] // (3 4 5; 6 7)

Infix ops have equal precedence but evaluation is right-to-left, so if you're using @ on a nested structure often requires parens:

(a@0)@1  // 2, equivalent to a[0][1]

But that would be tedious, so K also has a . operator for "deep indexing" with a right array argument:

a.1 0  // 3 4 5, equivalent to a[1][0]