It's hard to say how exactly to draw the line, but "array language" to an APLer usually means a language whose primary influence is APL. So these scientific languages that throw out most of the syntax are nearby but don't quite belong. From a practical standpoint the APL Wiki is centered on APL and exists to document the kind of niche material Wikipedia wouldn't cover, which is why there's nothing about these more mainstream languages currently.
I’d argue that array languages are far, far more limited than Python, to the point that the only thing you can reasonably do with them is processing array data (but they’re really good at it!)
Sounds like you're generalizing, based on... early APLs? NumPy? You could translate any BASIC code to, say, Dyalog APL easily without significant loss in fidelity. Different languages take different approaches but most modern ones (the ones that aren't just made to be calculators like Ivy) support either a generic functional or imperative style just fine.
K is inspired by Lisp, although you can't adapt that style directly because of the limited scoping rules: variables are either local or global, so a function can't see variables from containing functions. This means no closures, which K implementers consider a feature (I don't).
> This means no closures, which K implementers consider a feature (I don't).
having not touched K in about 15 years, when did this change? in k3:
K 3.2 2004-09-23 Copyright (C) 1993-2004 Kx Systems
LIN32 16CPU 15985MB ubuntu 0 EVAL
f:{a:x+1;{a+x}}
g:f 1
g
{a+x}
g 2
4
a
value error
a
^
parse error
This comes as a surprise to me! I thought none of Whitney's Ks had closures—although I did neglect to mention that kuc and oK add them. Digging around and asking on the K Matrix/Discord I found some posts that suggest that the K3 form is very limited. My read of these is that functions can refer to variables in the immediately surrounding scope (only one level up), and their values will be copied in when the function is reached in the source code. So it would be equivalent to adding extra arguments to g and passing the variable values in that way. And it wouldn't allow the programmer to create object-like things and couldn't create reference loops requiring garbage collection.
> their values will be copied in when the function is reached in the source code. So it would be equivalent to adding extra arguments to g and passing the variable values in that way. And it wouldn't allow the programmer to create object-like things and couldn't create reference loops requiring garbage collection.
That is definitely desirable! K (and kin) are fully referentially transparent and have value semantics. It would be bizarre and inconsistent to break referential transparency for closures.
No closures is one of the biggest pain points of k/q, it's incredibly limiting and frustrating. Besides that though, it's a wonderful language which allows you to solve problems very quickly with pretty good performance, assuming the problem is naturally vectorizable.
