Is there a way to create a not typed function in the parser?

[dvd101x]

Hi

In the parser if I use the function typed it works as expected getting a typed function.

myTypedFunction = typed({"number": f(x) = x})
typed.isTypedFunction(myTypedFunction) # true

If I try to make a not typed function I also get a typed function.

myFunction(x) = x
typed.isTypedFunction(myFunction)  # true

Even the function defined in the typed function is typed

let myTypedFunction = math.evaluate("typed({'number': f(x)=x})")
math.typed.isTypedFunction(myTypedFunction.signatures.number) // true

Is this behavior expected?
Is there a way to make functions inside the parser that are not typed?

[gwhitney]

Well, it turns out the ability to have non-trivial signatures in a (typed) function defined in the parser is essentially just a stub:

• There is no code anywhere to ever have more than one signature, i.e., there is no way in the parser to denote a function that does one thing on number and something else on Fraction, say.
• There is code to handle a FunctionNode that has a type annotations for one or more of its parameters, but there is no code that ever creates such a FunctionNode (they all just have the list of parameter names, no type annotations), except for a few tests in FunctionAssignmentNode.test.js.
• So that means in the code as it stands, every function created in the parser has just a single signature, (any, any, etc. for however many parametrs it has). In other words, at the moment, using typed-function instead of plain javascript functions for the functions defined in the parser is just useless overhead.

Therefore, short of someone submitting a PR that allows type annotations in the expression languages and/or adding further signatures to a function (e.g. after evaluating

f(x: number) = sqrt(x)
f(r: Fraction) = fraction(sqrt(number(r)))

then f is a typed-function with two signatures (number) and (Fraction).), I would be happy to do any of the following:

• Rip out the typed-function code in FunctionAssignmentNode in favor of ordinary JavaScript functions, on the presumption that mathjs is already so polymorphic that there's no need for functions defined on top of the mathjs layer to be explicitly polymorphic (clearly no burning need has yet come up, at least)
• Make the default (in case of only one, non-type-annotated signature) be to use plain JavaScript functions, and only use typed-function when there is type annotation and/or multiple signatures (which at the moment can't happen)
• Add a configuration parameter config.compute.function.defaultType which would default to Function (meaning a plain JavaScript function) but could also be typed-function to restore the current behavior.

Thoughts?

[gwhitney]

"pocomath" is just a handy reference to a series of prototypes for a new dispatcher/import mechanism at the heart of a revamped mathjs. There's a big speedup because in the internal typed-function calls made in one implementation of a typed-function, it attempts ("at compile time," so to speak) to arrange an ordinary javascript function call to the correct signature of the called typed function. The problem is that progress on the prototype keeps stalling as I get busy with other projects, so the termination condition of the prototyping is unclear. Anyhow, you can see the latest one in progress at https://code.studioinfinity.org/StudioInfinity/nanomath

[josdejong]

There is logic in place in FunctionAssignmentNode to define parameters with their type, see code. However, it is not possible right now to define types via the expression parser. So, it would be nice if some day we can implement support for that.

It is not strictly necessary to create functions defined via the expression parser as typed functions from a functional point of view. There is one positive side: unlike plain JavaScript functions, it does check the number of arguments. So if you create f(x,y) = x^y it will throw an error when you try to use it like f(2). Maybe we can keep this guardrail, by creating a little wrapper function which just checks the number of arguments instead of creating a typed function.

[gwhitney]

It does seem that just accessing arguments.length does not create an undue burden in a function, inferring from this StackExchange. So I think it would not be hard to create an automatic 'correct-number-of-arguments' convention in the functions created by an expression-language function assignment.

On the other hand, x^undefined already throws an error. Is that not enough? And if someone writes a function body that does execute without error when y is undefined, are we sure they didn't want to allow just f(2) as an abbreviation for f(2, undefined)? Just wondering aloud...

[josdejong]

Agree, just checking for the right number of arguments has limited value. Still, I think such a check is better than nothing and worth keeping. Especially in larger expressions or "workbooks" or "scripts" it can be helpful to have more explicit and direct error messages, and it helps prevent having too many arguments that are silently ignored.

[gwhitney]

OK, for anyone interested in this point and able to make the effort, sounds like Jos would positively entertain a PR that instead of generating a typed-function from f(x,y) = x^y + xy , for example, would just generate a regular JavaScript function that checks that arguments.length has the expected value (in this case, 2), and then forwards to evaluating the expression in a context in which x is set to the first argument and y is set to the second.