Actionable: Support direct function application of a result via (expr)(arg), but not yet unary application w/o parens

[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.

[josdejong]

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.

Interesting to think this through, thanks!

I agree that (2) wouldn't work as we want for common cases like x y.

About (3): right now, there is a clear separation between parsing an expression and evaluating it. Ther parser is not aware of which functions and variables are available and parses purely based on the syntax. If this changes to the parser requiring to look up the defined functions, we cannot separate parse/compile/evaluate anymore: the parser must already know the scope and math namespace. I think that would be a serious loss, because right now you can compile once (slow) and evaluate repeately (fast). Besides that, it helps making the behavior of the parser predictable when it is not coupled with defined functions (which can be built-in and user defined). So I think (3) is not a good option because of that.

I like the idea of (4). It's a bit odd but very pragmatic :). So this boils down to adding a signature "function, any" to the multiply function.

I'm not sure if there is an actual use case for expressions like (f(x)=x+2)(5). Just for the sake of readability alone I would prefer not to inline this function defintion but define it on a separate line. Thinking about it: maybe some conditional case like (x > 0 ? f : g)(5). That may be useful, though it still feels like a bit of an edge case, you can also write it like x > 0 ? f(5) : g(5) which is probably better for readability. Can you think of more examples?

[gwhitney]

Yes, we are in complete agreement about (2) and (3), they were just straw men for the discussion.

I don't quite agree that (4) boils down only to a new signature for multiplication. Some syntax can be parsed as definitely multiplication, such as f * 3 or (a + b)7, and you definitely don't want either of those to have any chance of that acting as function application; and conversely, some syntax has been designated as definitely function application, namely f(3), and it would be a breaking change for that to be interpreted sometimes as multiplication. That is why I think a new node type "MultOrFuncNode" -- I could definitely use help with the name -- is needed, to capture those constructs, I think EXPRA EXPRB and (EXPRA)(EXPRB), where it is useful, understandable, and non-breaking for the behavior -- multiplication or function application -- to be determined at evaluation time by the type of the left-hand operand.

I'm not sure if there is an actual use case for expressions like (f(x)=x+2)(5).

On the contrary, it is precisely because of our specific need for such expressions that I filed #3378. I only used f(x)=x+2 because it is one of the few expressions right now that can return a function, but you found another : a ternary conditional. Some detail of our specific use case: We are importing the Chroma.js package into mathjs to allow performing mathematical computations on colors, which is very natural, e.g. c+d is the color you get by overlaying d on top of c, etc. etc. The api of chroma includes many methods that return functions. These are very useful for creating gradients, for example, which are needed in our application. But right now we have literally no way of calling the function returned by one of these methods -- there is no syntax that supports it. Everything you might try is sucked up by implicit multiplication. (Well, I found one intricate esoteric syntax using arrays and indexing but it is practically unreadable.)

But as we get into this, we feel there are many ways it can be useful to compute a function and then apply the result: function composition, partial application of a function, taking a value of a derivative -- it's a window into being able to do some functional-programming-style computations in the mathjs programming language. And even the IIFE you started with, where you said you prefer to define f first and then call it: I agree that you can write f(x)=x+2; f(5) and that is clearer. But if you have a web interface in which the person using your app is allowed to enter a formula and the app will compute the value and use it, well, f(x)=x+2; f(5) does not return 7, it returns ResultSet[7] which crashes your app unless you've complicated your code to deal with ResultSets. The single expression (f(x)=x+2)(5), if it worked, would return just 7.

[So as an aside, I have been thinking of proposing that the pattern expr1; expr2; expr3 should return just the unwrapped value of expr3 after executing expr1 and expr2, since this pattern is guaranteed to have only one value, and a singleton ResultSet typically does not add much value and can be a nuisance.]

[gwhitney]

I suspect that some simple name like JuxtapositionNode would be best: it just captures that syntactically two things have been put side-by-side, and we need to figure out what to do with that situation at evaluation time. That way the name is semantics-neutral and if we ever find that juxtaposition needs to have other values in other contexts, the name won't be out of date the way that "ImplicitMultiplicationOrApplicationNode" would be. (Plus "JuxtapositionNode" is shorter ;-)

Another plausible option that occurs to me: just use an OperatorNode with the empty string as the operator name. After all, in some cases putting things side by side is called something like the "empty operator", and some programming languages even let you overload it. If we provide a way for the evaluation process to look up the correct special (typed-)function to use when the operator is the empty string, this scheme would probably take very little code to implement, and moreover, clients of the library could extend the semantics of juxtaposition just by importing more implementations to that typed-function. So I think this option is definitely worth consideration, and probably what I'd recommend just for ease of implementation.

But if you think it might be confusing when looking at parse trees to see an OperatorNode with an empty string name, and prefer to have a distinct Node type to represent the situation of juxtaposition that syntactically has not been definitely determined between implicit multiplication or function application, then I'm fine with that too, and would suggest a "structural" name like JuxtapositionNode or AdjacentNode.

[josdejong]

Zooming out a bit: because we support implicit multiplication, some other things become impossible (or very hard) to support, like unary functions without parenthesis and directly invoking a function returned by a function. That is unfortunate, but I think we have to accept that and not try to have it both ways. So, let's not go into the direction of a ImplicitMultiplicationOrApplicationNode solution but try to come up with alternatives which at least offer a solution for the different use cases. It may be not as concise as we would like, but at least it will be workable:

1. Unary functions without parenthesis like sin x: I think we simply should not support that. Instead, you can use parenthesis like sin(x), so this is no blocker, just a nice to have.
2. Directly invoking a function returned by a function, like fn(1, 2)(3, 4): we can introduce a function to invoke functions, similar to the JavaScript function methods .apply and .call. For example invoke(fn(1, 2), 3, 4). It may be not ideal, but it is simple and straightforward. Would that address you issue?

[josdejong]

Hmm, what brought about your change of heart? You seemed positive at first on the idea of more flexible function call syntax.

I would love to be able to directly invoke returned functions, that's where I'm positive about. But thinking about it more I don't (yet?) see a clean way to add support for it due to implicit multiplication. Supporting invoking a function returned by function like fn(x)(y, z) is quite similar to invoking a function returned by a property, like myobj.fn(y, z). In both cases, first a function is returned by some operation, and next, the returned function is invoked. Difference is that in the first case, based on the syntax we cannot know whether we're looking at an implicit multiplication or a function invocation. That is what bothers me. However, you're right, this adds a lot of (practical) value to the user, at I think you're right that this outweights the downside of a syntax that is less predictable on it's own.

Ok then you've convinced me, let's work out a solution for invoking functions returned by a function. Something along the lines of a ImplicitMultiplicationOrApplicationNode and a new function applyOrMultiply (good names yet to be determined ;) ). It would be neat indeed if people cannot do stuff like sin*x.

The fact that we perfectly well parse and execute not x shows that we absolutely can have unary functions without parenthesis.

I think the main difference here is that not x is a built-in operator similar to a and b or -x, it is not a function. It is different from a unary function call like sin x because we can only determine whether sin is a known function at evaluation time, not at parse time. I know function calls without parenthesis from PHP for example, but I'm personally not fan of it. But in the case of mathjs, it's different as we also support implicit multiplication. So, when I enter 2 sin 2 x cos y, how will it be interpeted? Even if we can come up with good rules for this, I think it may be better not to go in this direction: it will be confusing for users too, and it is too easy to make mistakes. So, since being able to enter sin x instead of sin(x) is only eye candy and doesn't add new functionality I think it may be best not to go in that direction. What do you think?

[gwhitney]

Alright, I will try to work up an alternative to #3378 more along these lines, focusing on (fn(x))(y) and possibly fn(x)(y) but not worrying about sin x.

(I am convinced there's more going on than I thought with no-parens unary function application by the following examples: currently 2 true in MaJE evaluates to 2, but 2 not false, which I would have thought would evaluate to the same thing, is an "unexpected operator" syntax error. 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.)

[gwhitney]

Oh indeed, if we ever really wanted to get the unary function application without parentheses working, it can be done without a multi-ary juxtapose operator, keeping everything associating to the left. To see how, say a and b currently happen to mean non-functions and f and g mean unary functions. There are four cases:

a b: interpret as a*b

f a: interpret as f(a)

a f: interpret as the unary function h(x) = a*f(x) -- except of course it's an anonymous function.

f g: interpret as function composition of f and g, i.e. the function k(x) = f(g(x))

With these conventions and current ordinary parsing of juxtaposition, 2 not false would evaluate to 2*true, or 2, as expected, and 2 sin 2 x cos y would evaluate to ((2*sin(2))*x)*cos(y), which is also perfectly reasonable. Parenthesis-free unary function application can only apply to the very next more-tightly-bound subexpression because of left-to-right associativity, so if you want the x inside the sin you have to write e.g. 2sin(2x)cos y which would then evaluate to the expected value with the above 4 rules. But just note that it does it in a slightly roundabout way: it calculates 2*sin(2*x) to get a number w, then makes a temp function that takes t to w*cos(t), and finally applies that to y. So under this solution that allows associating at parse time rather than evaluation time, long implicit expressions with unary function applications will be less efficient than the explicitly grouped one 2sin(2x)cos(y). Anyhow, as I said in my last comment, not worth messing with at the moment because even when treating not syntactically as a function, we're currently not parsing 2 not false

[josdejong]

Alright, I will try to work up an alternative to #3378 more along these lines, focusing on (fn(x))(y) and possibly fn(x)(y) but not worrying about sin x.

Thanks Glen! Let's indeed focus on working out a solution for directly invoking functions returned by functions, and park unary function calls without parenthesis for now👍.

[gwhitney]

It occurs to me that with the release of v15.1, we now have a working function application notation: if EXPR is any expression that might possibly return a function, then EXPR?.(arg1) calls the result of EXPR on the argument arg1. It also happens to test if EXPR is undefined, and if so returns undefined, and it throws an error otherwise if the value of EXPR is not a function, but those characteristics are icing on the cake.

So given that, do you want to contemplate:

(A) Just closing this discussion altogether, possibly along with a small PR that points out in the appropriate point in the documentation that the way to call a computed function is with the ?. operator? The fact is given everything going on and all of the possible mathjs projects, I for one would be unlikely to pursue implementing (EXPR)(x, y) as another way of calling a function that would differ only in not checking whether the result of EXPR is undefined, which was otherwise the outcome of this discussion. Or we could let this discussion lie fallow indefinitely, since if someone did come along and want to implement its final outcome, I certainly wouldn't have any objection even with ?. available. It's just the motivation is now much less: saving two characters.

(B) The conceivable possibility that the LHS of ?. is another context like the final argument of map in which an implicit compiled inline function should be allowed, so that for example (2*x)?.(3) would be a roundabout way to calculate 2 * 3 = 6. That's really a separate issue, so if it is of potential interest I will file it as one. The notation is in some sense available, as it currently just errors with undefined variable x. And lest you think it is a useless sort of expression (why not just write 2*3), consider if you want to evaluate a short polynomial on an input value that is very long to write out. Then

(x^2 + x - 2)?.(arcsin(tan(tau/6)) + zeta(sqrt(3)) reads a whole lot better than

(arcsin(tan(tau/6)) + zeta(sqrt(3))^2 + (arcsin(tan(tau/6)) + zeta(sqrt(3)) -2.

In particular you don't have to worry/wonder whether the expression inside the square is or is not exactly the same as the one in the next summand.

I realize you can write x = arcsin(tan(tau/6)) + zeta(sqrt(3); x^2 + x -2 but that evaluates to the hard-to-use ResultSet rather than a number (I've written elsewhere about that design decision and whether we might change it).