Why does unary function application require parentheses?

[gwhitney]

This is a companion discussion to #3358, in that it suggests (an) additional way(s) to invoke functions in mathjs. There is a sort of inconsistency between current implicit multiplication parsing and what one commonly sees in mathematical writing, in that if x is a number, then sin x is what you will typically see for sin(x), and no mathematician would take that for $x\cdot sin$. And while it is true that if a function f has been defined for the moment in some mathematical writing, it would be very unusual to see f 3 for f(3), it's also the case that nobody would ever write f 3 for $3\cdot f$ but they would write 3f for this. So we could consider a couple of different possible extensions/alterations to the parsing and/or evaluation algorithm that would provide more fidelity to common mathematical usage as well as more convenience for formula authors.

In the below concepts, we are just considering parsing EXPRA EXPRB where EXPRA and EXPRB are both unparenthesized and separated by whitespace (critically, because nobody ever writes sinx or cos1 and those would be tokenized as single symbols anyway). So some options of what to do with this construct:

1. Always consider this "whitespace juxtaposition" to be implicit multiplication (current behavior). This interpretation clearly misses some common mathematical usages, and allows some expressions like x 3 that one is very unlikely to see "in the wild". But at least it's clear and explicit.
2. Always consider this function application. This gets sin x correct, for example. And it is just as clear and explicit as the current behavior, just different. However, it removes the possibility of writing x y which is useful in multivariate polynomials, like (x+y)^2 == x^2 + 2 x y + y^2. So this is likely too far in the other direction.
3. If EXPRA can be looked up at parse time as denoting a function (e.g., it is a symbol, and that symbol is defined in the math namespace and its current value is a function) then parse this as function application, otherwise parse it as implicit multiplication. This would get both sin x and x y correct. However, it would be the first example of semantic-directed (or at least type-directed) parsing for mathjs, and those are murky waters that mathjs may well not want to wander into. (But I do think this is how humans are parsing this kind of construct.)
4. Parse this as a new sort of 'implicit-multiplication-or-function-application' node. The evaluation strategy for such a node would be "Look at your two inputs. If multiplication is defined for the two of them (in that order left to right), perform the multiplication. Otherwise, if the left-hand input is a function, attempt to apply it to the value of the right-hand operand. If that succeeds, return the result. Otherwise, throw an error." This option does not require semantic-directed parsing, and seems quite pragmatic: I think it will do what the formula author intended nearly 100% of the time.

In fact, if something in the vicinity of 4 were adopted, it could potentially be extended to many other instances that currently parse just as implicit multiplication: (f(x)=x+2)(5) could be parsed as this "ImFaNode" and would then succeed. In fact, I think any (EXPRA)(EXPRB) could be reasonably parsed to an ImFaNode, and it would generally do what the author intended. And it would eliminate a significant fraction of the need for #3378, especially the part that allows argument lists like (3,). (The only parts that I would suggest be kept are things like (EXPR)() being function invocation with no arguments (what else could it be?) and similarly with something like (EXPR)(2, 3, true).)

Conversely, I would say that (EXPR)blah where blah is unparenthesized should only be parsed as implicit multiplication, because almost nobody (except some group theorists) would ever write function application this way, and that the rules for blah(EXPR) be left exactly as they are.

If these ideas strike a positive chord, I'd be happy to close #3378 and supply an alternate PR with ImFaNodes (perhaps under a better name) and not allowing the dangling comma in argument lists, but allowing function applications like EXPR() and EXPR(x, y) regardless of what sort of expression EXPR is. Or, #3378 can be evaluated on its own merits, accepted/rejected/merged with changes, and the ideas here could percolate for a while or be rejected altogether.

I am just trying to make the mathjs expression language as convenient and powerful as possible, and always looking for ideas from mainstream math-community notation. Thanks for considering.