WIP: feat: define an Ohm.js parser for maje

glen commented

2025-12-19 21:51:45 +00:00

Owner

Adds an Ohm parser for maje, the mathjs expression language. Note the grammar is 200 lines as compared to 1850 for mathjs src/expression/parse.js, although the Ohm grammar does not perform any of the semantic interpretation, it is just a recognizer, whereas mathjs parse.js also produces an AST for the expression.

This is indubitably not fully correct yet, but it appears to be a plausible start that nominally captures every feature of maje per mathjs parse.js. The next step going forward to head toward making this merge-ready is to ensure that every example in mathjs test/unit-tests/expression/parse.test.js either succeeds in parsing or fails in parsing, as appropriate. That should shake out the (probably numerous) grammar bugs. I think the only other ingredient necessary to merge this is to ensure that it's possible to generate good error messages in the failed parsing cases. Semantics, including any kind of AST if we decide to do one on top of the built-in concrete syntax tree produced by Ohm, will be left for future PRs.

Adds an [Ohm](https://ohmjs.org/) parser for maje, the mathjs expression language. Note the grammar is 200 lines as compared to 1850 for mathjs src/expression/parse.js, although the Ohm grammar does not perform any of the semantic interpretation, it is just a recognizer, whereas mathjs parse.js also produces an AST for the expression. This is indubitably not fully correct yet, but it appears to be a plausible start that nominally captures every feature of maje per mathjs parse.js. The next step going forward to head toward making this merge-ready is to ensure that every example in mathjs test/unit-tests/expression/parse.test.js either succeeds in parsing or fails in parsing, as appropriate. That should shake out the (probably numerous) grammar bugs. I think the only other ingredient necessary to merge this is to ensure that it's possible to generate good error messages in the failed parsing cases. Semantics, including any kind of AST if we decide to do one on top of the built-in concrete syntax tree produced by Ohm, will be left for future PRs.

glen added 1 commit

2025-12-19 21:51:46 +00:00

feat: define an Ohm.js parser for maje

/ test (pull_request) Successful in 19s

Details

998e9c80c5

glen referenced this pull request

2025-12-19 21:54:15 +00:00

Possible next direction: Parsing and type-enhanced Node trees #45

glen commented

2025-12-19 22:00:37 +00:00

Author

Owner

Note that the scannerless nature of Ohm coupled with maje's convention of not generally allowing newlines at the "top level" while allowing them inside nested expressions complicates the Ohm grammar: it obliges us to carry a "white" parameter to most of the rules, indicating what kind of whitespace is active. (This parameter effectively produces two "flavors" of every rule, one in which newlines are ordinary whitespace, the other in which newlines are not always allowed.)

Similarly, the fact that we just want to skip the range notation a:b:c in the true branch of the ternary conditional introduces another parameter qRange in all of the rules above range, that indicates whether we are currently skipping range constructions.

It's conceivable there might be another mechanism for ensuring that ranges are not allowed after condition ? ... but that would be a refinement for the future. Best to just get this parsing to work.

Note that the scannerless nature of Ohm coupled with maje's convention of not generally allowing newlines at the "top level" while allowing them inside nested expressions complicates the Ohm grammar: it obliges us to carry a "white" parameter to most of the rules, indicating what kind of whitespace is active. (This parameter effectively produces two "flavors" of every rule, one in which newlines are ordinary whitespace, the other in which newlines are not always allowed.) Similarly, the fact that we just want to skip the range notation `a:b:c` in the true branch of the ternary conditional introduces another parameter `qRange` in all of the rules above `range`, that indicates whether we are currently skipping range constructions. It's conceivable there might be another mechanism for ensuring that ranges are not allowed after `condition ? ...` but that would be a refinement for the future. Best to just get this parsing to work.

glen added 1 commit

2025-12-20 16:27:11 +00:00

test: first set of parse tests

/ test (pull_request) Successful in 18s

Details

45f8f8087a

glen added 1 commit

2025-12-20 17:15:39 +00:00

test: another set of parse tests and associated fixes

/ test (pull_request) Successful in 18s

Details

ae98a750e7