Revive possibility of parenthesis-free unary function application

[gwhitney]

There is quite some discussion of the interaction between implicit multiplication and function application in #3379, especially in this comment, the bulk of which is

So I withdraw my claim that we are currently perfectly well parsing not x. Any attempt to handle sin x would first have to get the parsing of not x more robust, and that's not worth the effort at the moment. And there is a real obstruction, illustrated by f g h. If these are all numbers, that's (f*g)*h but if just g were a unary function and the other are numbers we would want it to be f*g(h). The key difficulty is that the direction of association of multiplication and of unary function application differs. So if you really want to handle it in mathjs, you'd have no choice but to parse this to something like juxtapose(f, g, h) and associate it at evaluation time. I don't think it's worth going down that road at the moment, although I think we could ultimately get it to work in a comfortable way.)

The eventual conclusion in #3379 was that we would not take any action toward this, in large part because the new chaining operator ?. allows you to force function-application interpretation any place you really want it, so we don't really "need" additional ways to call functions.

Nevertheless, I would like to revive the proposal, based on the following three points:

1. As observed, we currently fail at parsing not correctly: 2 not x is a syntax error ("unexpected operator not") as opposed to parsing as 2*(not x) as it should under the designation of not as a spelled-out unary operator.
2. It is completely standard and natural for people writing formulas to write 2 sin x to mean 2*(sin x). Indeed, this is what we teach in algebra class, at least in the U.S. but I suspect in other areas as well.
3. Finally, re-reading the above quoted comment with an open mind shows how to proceed without difficulty, preserving the the current semantics, but adding useful cases of function application.

The key source of all of the difficulties has been the poor interaction between implicit multiplication and function application. And the key observation promised by (3) above is that the difficulty goes away if one designates implicit multiplication as right-associative, as opposed to explicit multiplication, which is left-associative. If you combine this decision with an operator that multiplies two operands when possible, but if not, attempts to apply the left as a function to the right, you get many new successful cases. Examples:

• sin x applies the sine function to x
• 2 sin x parses as 2*(sin x), as we would want, because of the new right-associativity.
• Therefore 2 not x will work as desired, simply by dropping the special handling of not as an operator, and letting it be an ordinary unary function. This change will both simplify the parser and fix the current bug.
• It's not a panacea: 2 sin x cos x would parse as 2*(sin(x*cos(x))) which is not what is intended. (One would actually like the function applications to bind more tightly -- i.e. have higher precedence -- but there's no way to tell at the time you parse f x g x y which of 'f', 'g', and 'x' are going to turn out to be functions: if it happens that 'f', 'g', and 'y' are numbers and 'x' is a function, you want this to be f*x(g)*x(y), whereas if 'f' and 'g' are functions and 'x' and 'y' are numbers, you want f(x)*g(x*y). ) So you would still have to write 2 (sin x) cos x, or as you do now 2 sin(x) cos(x), or other similar options.

So to summarize, I would propose:

1. Leaving (a+b)x (i.e. (EXPR1)EXPR2) as only multiplication, as it is now, and f(a+b) (i.e., ACCESSOR(EXPR2)) as only function call, as it is now. (Note LITERAL(EXPR2), e.g. 2(x*y), is only multiplication, and that should stay that way as well.)
2. Interpreting (f(x)=x^2+x-1/x)(7) (i.e. (EXPR1)(EXPR2)) and f x (i.e. EXPR1 EXPR2) as ambiguous between implicit multiplication and function call, to be determined at execution time. Right now these two constructions are only interpreted as implicit multiplication, but this change will not break any existing implicit multiplications, because multiplication will always be tried first, and only if it is not possible will function application be tried.
3. Implicit multiplication be changed to associate right-to-left. This could in rare circumstances be a breaking change, but only with expressions that have side effects, since multiplication is commutative and associative. The value of any implicit-multiplication expression that worked before will remain the same.
4. Interpret (EXPR)() as zero-ary function application -- non-breaking as this expression is currently a syntax error.
5. Interpret (EXPR)(ARG1,ARG2,...,ARGn) (and similarly for more arguments) as n-ary function application for n >= 2. This change is non-breaking and I have PR'ed it before, but it was not merged due to inconsistency with the unary case, which this proposal would remove.
6. Optionally we could try to find a way for x 3 to error when 'x' is a number, since this is likely a typo in which an operator has been left out or an accidental space has been inserted, since nobody ever writes x 3 to mean 3x. But this desire to make this construct an error is a bit tricky, since under (1)-(3), we would like sqrt 3 to work, and such a change is also tangential to the main point of allowing "implicit unary function application" as well as implicit multiplication. I bring it up only in the quest for mathjs to match "natural" expressions that people write; I am not really pushing for this item.

I look forward to any comments.

[gwhitney]

To be honest with myself, once 2 sin x is working and if it becomes customary, 2 sin x cos x is potentially a "gotcha" situation creating tricky-to-see bugs in mathjs formulas. Hence we should try to find some guardrail against this "gotcha." But I would hope it wouldn't mean that the entire proposal would have to be scrapped, as it would be a nice way to fix the not bug and allow lots of familiar expressions that are currently errors.

[gwhitney]

OK, here's one possible guardrail. I would recommend

6. Make it an error for both implicit multiplication and implicit unary function call to occur inside an implicit unary function call. In other words sin acos t (nested function call) and sin x y (which is sin(x*y), implicit multiplication as a function argument) would be OK, but sin x cos x (which is sin(x*cos(x))) would throw an error, saying that mixed function call and implicit multiplication must be explicitly disambiguated. (Unfortunately the error would be at execution time, though.) Also note that very pleasantly since implicit multiplication is higher precedence than explicit multiplication, sin x * cos x would parse and execute as sin(x)*cos(x) as desired, so that would be one recommended way to disambiguate.

[gwhitney]

Hmm, but there is another possible gotcha: sin x*y would under 1-6 parse as sin(x)*y, but someone who didn't carefully read the precedence table might think that this expression should be sin(x*y). This isn't really new, though: sin x*y currently parses as (sin x)*y, just the sin x part is an execution-time error since multiplying a function and the value of x is not defined. Since it is a straightforward issue of precedence, and could be fixed by the expression writer via any of sin x y, sin(x*y), or sin(x y), I think this one is a lot less bad than sin x cos y and I'd be perfectly happy to live with it for the other benefits of the proposal, especially fixing the not bugs (which I don't really know how to do independently).

[gwhitney]

Note this feature was requested also in #2298, so I'm not the only one ;-)