Discussion
There are a few reasons one would want a right-to-left APL.

* Reading order would match execution order.

* The reading would be "… and then …".

* Works better for long lines and wrapping lines and inline multi-line lambdas.
# Names of arguments and operands

### Dfn left and (optional) right arguments: x and y

Thus {x÷2}→f and 10 f gives 5

Thus {x÷y}→f and 10 f 2 gives 5

### Dop primary and secondary: f and g

Thus {x/f}→Reduce

Thus {x f.g y}→Dot
# Positions of operands

Possibilities:

* +/ is what Jelly uses

* /+ reads nicely as "and then fold using plus"

The operand on the right probably works better for monadic application with an array operand, e.g. make every element into a zero:

* array(0⍨¨) (how is this read?)

* array¨⍨0 ― "array, and then map using constant zero"

On the other hand, dyadic application will always need a parenthesis, as a tack won't do:

* x(0⍨¨)y or x(0⍨)¨y or x⊣0⍨¨y

* x(¨⍨0)y or x¨(⍨0)y

Would x¨⍨0∘⊢y or similar work?

Getting rid of space-for-stranding solves the problem too, of course.

Should the operands be swapped?

Probably, at least for some operators, as e.g. in dot product, the × is performed before the +, so x DotProduct y is x×y/+ (for vectors) and thus x×.+y is more natural.

Where one operand is a parameter, like for ⍤ and ⌺ it would probably depend on how monadic operators are done.

E.g. ¨f would imply k⍤f for Rank. On the other hand, k could be seen as a modifier of ⍤ so then it going on the right makes more sense.

⍣ should probably stay as-is to match *
# Expressions

Line continuation would me much more natural, and multiple expressions could naturally follow each other with ⊢ so the need for ⋄ would be much less.

Function assignments are an issue, but maybe all assignments should return an array?
# Assignment

Where should it go? Natural would be to keep the flow from left to right, so →name at the end of the expression, just like in TI-Basic.

An argument against that would be the one cannot easily "spot" definitions by scanning the left margin.

Maybe a solution is to allow line continuation, maybe even implied for a leading → so one can write

apl
expression
→name


The downside of this option is that it takes double amount of vertical space.

A different option is to treat assignment as a syntax (as opposed to a function), and keep it on the left side of an expression as name←expression. This is not affected by the argument against →name, and saves vertical space.
# Positions of arguments

Monadic functions like - and ÷ and * and ⍟ probably can't stay negate, reciprocal, etc.

* × and * could have ¯1 as "default right arg" so negate is x× and reciprocal is x*

* Monadic + and - could be the often requested increment and decrement. (Complex conjugate is a rare operation and we have ○¯10)

* Trig functions don't suffer from having the function selection on their right, and "pi times" can as well be "times pi", i.e. x○

* Adding a constant for *e* solves a much rarer need with *⍨⎕e and ⍟⍨⎕e

* Factorial would end up like in TMN, x!, so that's nice and we finally get n!k reading "n choose k"

* Floor and Ceiling would need to be ⌋ and ⌉.

* Absolute value as postfix x| works fine, and remainder x|y would finally match x÷y

* Order of arguments of ⊥ and ⊤ would be swapped too, which would be very good, as 102~3~ would be 1 0 2⊥3 and 101~2~ could nicely be 1 0 1⊥.

* Indexing works out well, in that x⌷y matches x[y]

* Roll works well as x? and deal becomes n?k matching n!k

* , would be a more natural "append" than the current "prepend" and ditto ⍪
* Added benefit is that relatively cheap operation of appending has a shorter notation ,y compared to prepending ,⍨y

* ∊ and ⍷ probably need to stay the way they are, but should ⍳ and ⍸ be reversed? Should they keep their symbols? Also a problem for /\⌿⍀. Maybe we need to investigate how many times we use ⍨ on these.

* ⊂ and ⊃ (resp. ⊆ and ⊇) will need to swap symbols.

* ⌹ is a problem, but it is really rare.
Bubbler
# Function definitions

A copy of the discussion starting [here](https://topanswers.xyz/transcript?room=1705&id=89127#c89127).

In current APL, the following does not work:

apl
Foo←{
5::z←'count!'
z←4 3 5÷⍵
↑z'done'
}


which should be written like this instead:

apl
Foo←{
z←{
5::'count!'
4 3 5÷⍵
}⍵
↑z'done'
}


which is bad because the order of execution is:

apl
}⍵
5::'count!'
4 3 5÷⍵
z←{
↑z'done'


But in LPA, it’d be

apl
{
x{
5::'count!'
4 3 5÷x
}→z
z'done'↑
}→Foo


which is nice, and then you can even inline it:

apl
{
(x{
5::'count!'
4 3 5÷x
})'done'↑
}→Foo


or

apl
{
x{
5::'count!'
4 3 5÷x
},⍥⊂'done'↑
}→Foo


In the examples above, x was used to denote the primary (left) argument. y can be used for the secondary (right) argument in dyadic functions. This naturally matches the x and y in mathematics.

:For can be replaced with collection¨{block}, :While and :Until can be replaced with {condition}⍣{block} (with better definition of ⍣), and :Repeat n in APLX can be replaced with n⍣{block}. :Select can be replaced with guards without too much problem.

Optionally, we can use explicit return value→. This is needed if we want to call functions for side effects, and for more freedom in control flow.

The features(?) of tradfns not covered yet are:

* Functions returning functions