I implemented the Apple array system with the aim of tidying up some of the shortcomings of J, with which I am familiar.

Apple is only a research toy (compared to a full-fledged language like BQN)— nevertheless, I suggest these insights, particularly a call to seriously consider static types in the APL cult.

# Static (Shape) Types

Static types are strictly superior to dynamic types. With inference one gets types from inspection of an expression (say, typechecking in an editor); one need not wait til runtime. Types thus calculated can be insightful to the programmer and type signatures supply some of the documentation that one writes in NumPy.

Thus type inference offers far more than simply preventing bugs or improving performance—array languages like APL, J, BQN do not suffer from performance and Iversonian acolytes have ways to avoid bugs that really work, viz. transparent programming and laconic style.

Bob Harper has additional, technically justified comments on dynamic types in this vein.

Moreover, arrays benefit from shape types; one can write

mmul : Arr (m × n) a -> Arr (n × l) a -> Arr (m × l) a

in Futhark, Accelerate, Repa, and Remora. Indices are integers, and integer-indexed types occupy a sweet spot: integer constraints are solvable and so one can have full-fledged dependent types (ATS does this).

# Records, \( n \)-ary Functions

Where Standard ML and mainstream languages use \( n \)-ary functions, APL and J have monadic and dyadic verbs. Thus J implements the hypergeometric function as a conjuction, which is unsatisfying.

Moreover, J does not have tuples and worse, function arguments are passed via boxed arrays by convention. This leads to inelegant code, for instance my implementation of elliptic Fourier series.

I suggest that
all array languages allow \( n \)-ary functions without fuss^{[1]}—the re-rank construct is too sweet to be arbitrarily limited.

# Apple Shortcomings

## Rank Polymorphism

Rank polymorphism in Apple is explicit; one writes

(+)`{0,0}

for element-wise addition. In BQN this is just `+`

. This must be recognized as strictly superior.

Even so, Apple's static typing has panned out in nontrivial examples, such as elliptic Fourier series and a neural network.

Inference for rank-polymorphism is an ongoing area of research (see also recent work on Futhark). Remora and Futhark both intend to be able to express `+`

without fuss.

Amidst all this, Iversonian languages continue to progress—BQN has structural under, which I believe has not been studied by Remora &c. That Uiua also touts under suggests that it deserves attention.

# Futhark &c. Shortcomings

## Interactivity

Futhark can produce code callable from Python but one must recompile, so that if one has loaded an image in Python, a change is burdensome compared to a typical k workflow.

k uses a single ASCII character for important primitives; this has implications for human-computer interactions. J is likewise laconic with quick input.

In fact I initially missed interactivity in Apple, which led me to implement
folds &c. laconically. BQN's `+`

is superior to `(+)`{0,0}`

, being one keypress
where Apple requires nine.

Interactivity is also a deficit of Accelerate and Repa.

Conversely, the inability to inspect type (and thus shape) information with a keypress makes APL descendants less interactive. Insofar as J &c. are already good, they would offer even more with type inference.

# Conclusion

An array language with static (shape) types, rank polymorphism like BQN or Remora, and interactivity à la k or J would establish itself.

[1] Arthur Whitney came to the same conclusion with k.