I think the key idea behind APL and J is that they take one fundamental data structure, namely arrays of arbitrary rank containing characters, numbers or boxes,

I think the key idea behind APL and J is that they take one fundamental data structure, namely arrays of arbitrary rank containing characters, numbers or boxes, and define a number of operations on them, each of which has a natural mathematical definition and satisfies a number of laws. For example APL has at its core combinators ι ρ φ ⊤ , . \ / and a number of binary and unary operators. To give an example, / is like fold in a functional programming language, so +/ would be fold (+) in Haskell, there fold (+) :: Foldable t, Monoid m => m t -> t. However you would have a hard time implementing J like arbitrary rank arrays in Haskell efficiently and supporting all the operations it does. The philosophy of J and K is to isolate the essential operations and laws the data structure you are trying to manipulate has and to implement an interpreter for those operations that is as efficient as possible. This is in contrast to a conventional general purpose language that tries to implement a sufficiently smart compiler and primitives to create new data types from a set of primitives ones. The problem is that it is quite hard and sometimes impossible to teach the compiler retroactively about all the nice properties your newly defined data structure has. I believe several such domain specific interpreters/compilers could be "stitched together" into a general purpose language, maybe integrated by a system specialised in symbolic computation. Instead of compilation to machine code the top level system would compile down to the base operations for each data structure and simplify according to the laws the base operations satisfy. Haskell and many other do that by compiling down to a Core language and then applying a huge number of simplification passes on that intermediate language.