Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[FEATURE] Expression parser #119

Open
2 tasks
tommens opened this issue Jan 1, 2024 · 0 comments
Open
2 tasks

[FEATURE] Expression parser #119

tommens opened this issue Jan 1, 2024 · 0 comments
Labels
enhancement New feature or request

Comments

@tommens
Copy link
Owner

tommens commented Jan 1, 2024

Describe the new functionality you would like to see
In order to easily write expressions as strings, and convert them into abstract syntax trees that can be processed for evaluation, we need an expression parser:

  • In its most basic functionality, the expression parser will only accept as input properly balanced expressions with parentheses in the right places. E.g. "((4 + 5 + 6) * (7 + (5 / 2 / 7)) * 9)". The parser should be able to read expressions in either prefix, infix or postfix notation. E.g. "(+(4,5,6),+(7,/(5,2,7)),9)" for prefix; "((4,5,6)+,(7,(5,2,7)/)+,9)" for postfix. The parser should not be space-sensitive, the presence or absence of spaces, tabs and so on should not make a difference when parsing. Slight variations of the allowed notation could be considered, for example a pre- or postfix notation with spaces instead of commas as separator between arguments. E.g. "(+(4 5 6) +(7 /(5 2 7)) 9)", which incidentally also corresponds to the way of writing expressions in the Schema functional programming language. When implementing this functionality, the "output" of an expression should be consistent with the accepted input. (In other words, any valid string given as input should return an equivalent string after converting it to an Expression and back to a string. Conversely, any string generated as output from an expression should be acceptable as input to the parser without any errors...
  • A more sophisticated functionality should take into account operator precedence to avoid superfluous parentheses. For example, if we know what * and / have precedence over + and -, then we can simplify the expression "((4 + 5 + 6) * (7 + (5 / 2 / 7)) * 9)" to something like "(4+5+ 6)(7 + 5/2/7)*9".

Is your feature request related to a specific need or problem?
Without a proper expression parser, the caclulator is not really practically useful, since creating expressions manually in terms of object trees is very cumbersome, error-prone and time-consuming.

Additional context
Several Java libraries exist for creating parsers, it is recommended to choice the most appropriate one of them rather than to reinvent the wheel from scratch.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
Development

No branches or pull requests

1 participant