Discussion
bqn add tag
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
# 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.
Answer #2
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 #3
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 #4
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 #5
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

Enter question or answer id or url (and optionally further answer ids/urls from the same question) from

Separate each id/url with a space. No need to list your own answers; they will be imported automatically.