jison | Bison in JavaScript.

Good question.

The problem is the \b word boundary assertion. For some reason, javascript's regular expression engine specification does not consider Bangla digits to be word characters. For \w and \b, only ascii letters and digits count as word characters.

Consequently, a Bangla digit followed by a plus sign (which is certainly not a word character) is not considered a word boundary, and thus doesn't match the assertion.

If you just drop the \b, it should work (although I would also drop the ^: Jison patterns are always anchored, so there's no need to insist).

Unlike (f)lex, the jison lexer accepts the first matching pattern, even if it is not the longest matching pattern. You can get the (f)lex behaviour by using

Based on @Sleavely answer (see comment quoted below), and further reading on the topic, mathjs seems the most reasonable solution:

Third-party admins may be the only ones who can edit the code, but where will it actually run? In your backend? On visitors' computers? I strongly recommend you avoid eval(), lest you be blamed for whatever Bitcoin miner visitors end up contracting from your application. With that in mind, I think that you're on the right track with your 2nd option. Evaluating the formula against a set of predefined variables strikes me as safe enough. Looks like mathjs actively avoids eval(): https://github.com/josdejong/mathjs/blob/master/docs/expressions/security.md

Tokens identified in your lexical analyser have a token type, which is the string you return from the scanner action, and the matched text, which the lexical scanner keeps in its yytext property from which the parser initializes the token's semantic value. (This is not very well described by the documentation.)

So in this action:

You moved the json translation files into the wrong directory.

From the docs:

Translation files that use translation strings as keys are stored as JSON files in the resources/lang directory. For example, if your application has a Spanish translation, you should create a resources/lang/es.json file:

I'm not sure what you mean by "work" in your question. That online parser-generator reports shift-reduce conflicts for both the LR(1) and the LALR(1) algorithms, which is not suprising since your grammar includes the exponentially ambiguous

Looking at these these productions:

It's really trivial to add this feature to a parser generated with a parser generator, without much consideration of how the parser generator works. All you need are some extra (fake) terminals, one for each nonterminal you'd like to start the parse with, and one new production for each new terminal.

It also helps if you can inject a lexeme into the lexical stream without jumping through hoops, which is certainly possible with jison because it allows you to insert your own custom lexer which can inject the terminal and then pass through calls to the generated lexer. (If you need to use the generated lexer, then it's still pretty easy if your lexer generator allows for start conditions. You just define a start condition for each injected lexeme, which immediately issues the desired terminal and then resets to the standard start condition in order to parse the actual input. There's lots of variations for this strategy, depending on the interfaces available to you.)

Based on the above, the new grammar will look something like:

It's true; it is not easy to find examples of expression grammars which resolve ambiguity without using precedence declarations. That's probably because precedence declarations, in this particular use case, are extremely convenient and probably more readable than writing out an unambiguous grammar. The resulting parser is usually slightly more efficient, as well, because it avoids the chains of unit reductions imposed by the usual unambiguous grammar style.

The flip side of this convenience is that it does not help the student achieve an understanding of how grammars actually work, and without that understanding it is very difficult to apply precedence declarations to less clear-cut applications. So the exercise which gave rise to this question is certainly worthwhile.

One place you will find unambiguous expression grammars is in the specifications of (some) programming languages, because the unambiguous grammar does not depend on the precise nature of the algorithm used by parser generators to resolve parsing conflicts. These examples tend to be rather complicated, though, because real programming languages usually have a lot of operators. Even so, the sample C grammar in the jison examples directory does show the standard model for arithmetic expression grammars. The following extract is dramatically simplified, but most of the productions were simply copy-and-pasted from the original. (I removed many operators, most of the precedence levels, and some of the complications dealing with things like cast expressions and the idiosyncratic comma operator, which are surely not relevant here.)