Syntax / Bracket recovery suggestions

[sancarn]

We just found this library after trying to build a similar expression parsing library. It's great there already exists a package for doing this kind of Mathematical evaluation.

In our parser we created an algorithm for bracket recovery. This allows an expression to be tested e.g:

2*3+2)/4

and viable syntax generated as follows:

(2*3+2)/4
2*(3+2)/4
2*3+2/4

it'd do this by first creating group recovery nodes at the beginning of the expression e.g:

(2*3+2)/4
^
group recovery node

And then iterating through the tree to create all possible variations of the expression. This additionally worked for multiple brackets both opening and closing.

We were wondering whether you'd be interested in having this feature in MathJS, and how we'd go about doing that.

[m93a]

Hey Sancarn, Thanks for reaching out, and sorry for being so late to reply. To me, this sounds like a great feature to have!

@josdejong What's your opinion on this?

[josdejong]

Interesting idea. I think it the biggest challenge is how to go about ambiguities. Often there are multiple cases where the user could have wanted the open or close bracket. So I would be really careful with those cases. Do you have any ideas in that regard?

More on a general note: I have a bit of a precedence over clearly explaining the user what is wrong and how to solve it over magically fixing invalid user input. It could be interesting to see if we can improve the syntax errors with useful extra information: "Error: missing bracket. Did you mean <fixed expression here>?". What do you think?

[NotWearingPants]

I'd like to suggest that for an API there would be an option to try and evaluate the most likely correction (perhaps just the first one in the list of possible corrections).

Also it would be great to have an API that returns all the autocompletions/suggestions. Maybe even go beyond brackets - take in a string and the index of where the user is typing, and autocomplete names of functions in the middle.

#416 is related btw

[josdejong]

Ah, yes, #416 is about the same indeed.

try and evaluate the most likely correction

Yes that could be nice. At least I think it is important that the parser does not silently apply "most likely" corrections, but that it is explicit. Maybe in the form of an explicit API like evaluateAndAutoFix which returns not only the result but also the issues and decisions it took, and/or a list with issues and possible fixes or something like that.

[gwhitney]

As this is essentially a duplicate, closing; further discussion can take place in #2697.