Now that it's the future and all, are there any technical obstacles
remaining that would prevent the existence of an APL dialect that
looks like the code from Iverson's 1962 /A Programming Language/?

I'm not sure how to rank the *severity* of these differences, so this
list is in order of how surprising it is (to me):

Variables have one of 4x4 types where the field can be (Logical,
Integral, Numerical, or Arbitrary) and the dimension can be
(Scalar, Vector, Matrix, or Tree).

Instead of using monadic rho to access the dimensions of an
object, there are mu(), nu(), delta(), and lambda() which yield
respectively column dimension, row dimension, degree of a tree
node, and number of leaves in a tree.

Column operations use a doubled symbol. Indexing uses superscripts
and subscripts.

File operations all use the magical Phi doohicky which can take subscript,
superscript, and a pre-subscript and can appear on the left or right of
specification arrow.

So the first major challenge appears to me to be designing an intermediate
representation for the editor/typesetter and interpreter/compiler to
work with. IIRC, this is similar to Algol 68 where the source could be
represented in multiple forms (linear form for entering with terminal
or keypunch, presentation form for putting in books). But here, in order
to make the presentation form pretty, the linear form will need to get
ugly I fear.

Has anyone tried to do something like this or given it more thought in
all these years?

On Sunday, December 26, 2021 at 7:37:03 PM UTC-6, luserdroog wrote:
> Now that it's the future and all, are there any technical obstacles
> remaining that would prevent the existence of an APL dialect that
> looks like the code from Iverson's 1962 /A Programming Language/?
>

I've made a start. I'm using javascript/html/css as an prototyping
environment. So for the forseesable future, postings about this
nascent interpreter will be found in the comp.lang.javascript newsgroup.