Yes, almost all current interpreters and compilers do materialize the results and making whole passes through the array in such a case. In practice, since the p

Yes, almost all current interpreters and compilers do materialize the results and making whole passes through the array in such a case. In practice, since the primitives (e.g. “=“) are implemented in tight, predictable, branch free, often SIMD code, it ends up faster than the obvious branching C-like routine despite the interpreter overhead - especially since any strung under 16K is essentially guaranteed to be in L1 for the 2nd pass (and even if it’s not - it’s predictable linear prefetched access even in the first pass, almost as good). When was the last time you wrote prefetching branchless SIMD code for any task other than your inner loop? In APL/K you pay interpreter and GC overhead, but often get those perks for your whole program “for free”. Indeed, k/APl make use of your visual pattern matching in ways that no other language does (or can, with standard practices, due to code density). Some APl compilers identify idioms and replace them with a faster implementation (e.g. sum which is +/ is done by essentially all, more complicated things like “average” by some); but the cognitive load is independent of that - you don’t need a manual because a semantically equivalent implementation is in front of your eyes.