Ability to get return type(s) of parsed expression

[TheOneTheOnlyJJ]

I've come across math.js a few days ago while researching options to parse and evaluate mathematical user input safely. The library is everything I've hoped for and much more, except one feature.

My use case allows users to define custom JSON schemas for arbitrary "objects" (as in physical items) to be used as database collection schemas. I want to allow for computed fields to be defined with arbitrary user-provided mathematical expressions, using the other defined fields as the expressions' scope. For example, given a user-defined "ball" object type that has the required field radius, I want the user to be able to add a field volume, that is dynamically computed given the object's radius when a new object of that type gets added to the database.

The problem I have, however, is determining the return type of the users' expression input. I need to be able to infer the return type of the mathematical expression's possible results before committing the schema to the database. For example, continuing with the example above, I want to limit the volume field to a number. I must not allow expressions that return booleans, matrices, objects, strings, or function declarations in this particular case.

I could implement a simple type check for the expression result at object addition time, which would not be ideal, as the user would not be notified of the type mismatch while defining the object schema, leading to a very poor UX.

Thus, this requires me to implement the type check at field (expression) declaration time. Besides having no concrete idea how to approach this problem on my own as of now, I have identified a few potential problems here:

1. Expressions can have conditional results, thus requiring me to cover all possible branches.
2. Continuing from point 1, I do not have any data to test the expression result with at the schema definition time (as that data becomes available when the user adds an object instance of that type to the database).

All I can do until now is check the SymbolNodes so that no undefined field names are used in the expression.

Adding to this, I will also have to check for conflicts between user-defined field names and predefined math.js constants/functions. Having a function that returns a list of all the reserved names of predefined constants, variables and functions in the library parser would be of great help, allowing me to restrict the user-defined field names, thus avoiding such conflicts.

I welcome any kind of input, suggestions, and alternatives on this topic.

[josdejong]

Good to hear that mathjs if of help to you.

Determining the output type of an arbitrary expression at compile time requires a typed compiler. The expression parser of mathjs doesn't do types though. Maybe you can require the user to provide the type of the output of an expression manually?

[josdejong]

This is not possible in the current codebase which is JavaScript with handcrafted TypeScript definitions.

We have plans to migrate to TypeScript (we've had a lot of discussions about that already), but even then it is a huge challenge to statically analise the return type of a function due to the dynamic nature: you can dynamically add new signatures at runtime to the same function, and there is logic in place to automatically convert function inputs to find a matching signature (like convert both inputs of add(2i+3, 4) into a complex number and then use the complex implementation of function add). All of that doesn't play nice with TypeScript.

[TheOneTheOnlyJJ]

I understand what you are saying.
I'm not sure I properly worded my perspective clearly enough though. I'll clear up my point a bit.

When referring to these expression return types, I'm referring to basic strings (like the return type of the typeof function), not TypeScript types, as they cannot be determined at runtime in the compiled JavaScript.

Regarding the addition of new signatures to functions at runtime, maybe we could have the signatures (keeping in mind they're just lists of strings) of every function in the lib wrapped in a new object/attribute that can be edited at runtime, thus allowing for dynamic signature changes by the user. This property could either be a global object (maybe this approach would require less codebase rewriting) or alternatively embedded in every function, like a class attribute.

For the example you give with add(2i+3, 4), maybe it would be possible to dynamically get the relevant signature of the relevant implementation at runtime by looking at the expression tree children nodes of the function node of add and choosing the signature to pass up the expression tree to the parent node (that could have similar conditional logic). Here, an input type of complex and number can be mapped to a return type of complex.
Cases where null and undefined could be returned would also need to be taken into account.
The same could be done for operator nodes, and any other node type that can alter the type of the expression output.

[josdejong]

😄 yeah any runtime types will not necessarily tight to TypeScript, but TypeScript is a big part of the options we've been discussing in this regard. I just wanted to briefly give a bit of context. Here a pointer to one of the discussions: josdejong/typed-function#123 in case you're interested.

[TheOneTheOnlyJJ]

I've read around what you pointed me to for the last couple of hours and what's been discussed there is nothing short of impressing.

I've also stumbled across this issue from typed-function which may be worth mentioning here: josdejong/typed-function#124. If a solution to this would be implemented, I see it as approachable to start thinking about dynamically obtaining the possible return types of an expression.

May I also ask if there's any progress on either josdejong/typed-function#123 or josdejong/typed-function#124?

[josdejong]

We still have plans to implement it, but it is be a huge undertaking. Last couple of months we haven't been active on it.