Adám
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.
Top Answer
Adám
# 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`
Answer #2
Adám
# Positions of operands
## Monadic
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.
## Dyadic
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 `*`
Answer #3
Adám
# 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?
Answer #4
Adám
# 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.
Answer #5
Adám
# 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.
Answer #6
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←{
11::z←'bad!'
5::z←'count!'
z←4 3 5÷⍵
↑z'done'
}
```
which should be written like this instead:
```apl
Foo←{
z←{
11::'bad!'
5::'count!'
4 3 5÷⍵
}⍵
↑z'done'
}
```
which is bad because the order of execution is:
```apl
}⍵
11::'bad!'
5::'count!'
4 3 5÷⍵
z←{
↑z'done'
```
But in LPA, it’d be
```apl
{
x{
11::'bad!'
5::'count!'
4 3 5÷x
}→z
z'done'↑
}→Foo
```
which is nice, and then you can even inline it:
```apl
{
(x{
11::'bad!'
5::'count!'
4 3 5÷x
})'done'↑
}→Foo
```
or
```apl
{
x{
11::'bad!'
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.
We can discard tradfns, and allow control structures in dfns.
`: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:
* Niladic functions
* Functions without return values
* Functions returning functions