Not particularly related. It's just that every function is either monadic (operand on the right) or dyadic (infix). That makes it a case of not needing to explicitly specify where the function arguments start and end, still without using a stack; it is purely syntactic, and obvious (although you do need context to parse anything that uses user-defined things). Parentheses are still needed for the left operand of a dyadic function if it is to take an expression more complicated than a plain array.
If you had functions of higher arity, then it would become necessary to add parens, delimiters, or a stack.
APL's usage of monad predates its use in conjunction with modern functional programming languages, by the way. It goes back to the 60s, and there are plenty of books and papers where these terms are used that way.
https://en.wikipedia.org/wiki/Monad_(functional_programming)...
I can't say I care too much which terms people use, but in context of APL, I prefer the terms that were used by Iverson and have been in print for more than half a century.
It would be interesting to track down where these terms came from. The typed functional programming usage of the term monad, being identical to the current mathematical usage, apparently comes[1] from Mac Lane’s classic Categories for the working mathematician (1971) and seems to be motivated by the preexisting term monoid (which I dislike, so that’s a bit disappointing). The use of monadic, dyadic, etc. for relations and operations of (what is now usually called) particular arity is, as far as I can tell, mostly obsolete in mathematics post 1960 or so except for the occasional use by logicians (particularly of a philosophical bent). I’ve found it[2] as far back as Russell and Whitehead’s Principia mathematica (1910–13), but don’t know where they got it from. Still, that explains the use in logic (not that it means it’s a good idea: most of notation in Russell and Whitehead[3] is now spectacularly obscure, and parts of it were obscure even at the time).
[1]: https://english.stackexchange.com/a/30661
[2]: https://en.wikisource.org/wiki/Russell_%26_Whitehead%27s_Pri...
List needs parentheses because its parser does not depend on knowledge of operator's arity, it just parses generic abstract syntax tree.
Arity is property of functions, not expressions, so you would need static type system to assigning arity-types to expressions.
Also, you would still need parentheses to express structural data, where no operator arity is relevant.
- Lisp only needs parentheses because its operators have variable arity, that’s about as deep as the “type system” goes.
- The concatenative languages wiki <https://concatenative.org> only lists Om <http://om-language.org> among the (non-reverse) Polish notation concatenative languages, but its semantics are a bit more tricky than those for RPN languages when expressed in terms of left-to-right evaluation (stream processing, not stacks).
- Unrelated, but see XY <http://www.nsl.com/k/xy/xy.htm> for a very elegant RPN semantics.
- I think I’ve heard that the APL semantics is commonly described right to left so might be related?
- The proposed Lisp-2 notation with a syntactic distinction between operators and operands strongly reminds me of how the Self expression syntax <https://handbook.selflanguage.org/2017.1/langref.html#expres...> works (its main difference from Smalltalk).