mathjs lacks a notation to enforce function call interpretation rather than scalar multiplication

[gwhitney]

At the moment, suppose you import an object foo into mathjs that has a method .operator() that returns a function, and you want to call that function on the argument 2. You might reasonably write the mathjs expression-language code foo.operator()(2). However, you will be disappointed: that is parsed as multiplying the result of foo.operator() by 2.

As far as I can tell, there is no mathjs expression language notation that makes something like this parse as a function call. Even most workarounds like map([2], foo.operator())[1] or matrixFromFunction([2],foo.operator())[2] don't work -- they complain that foo.operator() has no free variable -- mathjs won't just trust that maybe foo.operator() returns a function and give one of these a shot. You can work around this with something like call(f, x) = f(x); call(foo.operator(), 2) but then you have to deal with ResultSets (see #3355 for some discussion on that).

It seems to me important to have a notation for calling an entity as a function on some arguments. We could have something like call(f, arg1, arg2, ..., argN) so that in this case we would write call(foo.operator(), 2). And/or we could adopt some notation to be unambiguous for function call. For example, we could adopt the Haskell function call notation f $ arg1 arg2... so that in this case we would write foo.operator() $ 2. Or we could say that if the argument list has commas in it, like f(a,b), that's always a function call, and to force a unary function call like this, you would write foo.operator()(2,). Or we could have some special delimiters, like maybe double parentheses, that always mean function call, so you could write foo.operator()((2)).

Of these options, I think I like foo.operator()(2,) the best. But there are likely other ways to address the need to allow calling a function that happens to be returned from an expression (rather than already being a name or a function definition). What are your thoughts? I am happy to do a PR if we can reach a consensus here, as it would be a real help for another project to have such a notation.

[gwhitney]

Interestingly, the HISTORY entry for v3.16.1 shows (f(x) = x^2)(4) as a function call; but currently it errors out. So perhaps at one time this was a notation for a function call. But (x+2)(x+4) should definitely be multiplication, so it doesn't seem like this notation would work well in general.

[gwhitney]

See also #3379 for other ideas on what notation might be used to allow these sorts of "computed" function calls.

[josdejong]

I think we had to drop support for (f(x) = x^2)(4) because of supporting implicit multiplication and splitting parsing from evaluation (which introduced the need to determine function invocations at parse time), introduced in v4.0.0.

This discussion overlaps with #3379 (comment), shall we continue the discussion there?

[gwhitney]

Sure, good to have one place that focuses on this.

[gwhitney]

Should this be closed in favor of #3379, especially since that could itself perhaps be closed in light of the new EXPR?.(arg) notation for function calling? Feel free to just close if you agree.