Design a String Calculator with Explicit Grammar and Evaluation Rules

Design a string calculator that evaluates an arithmetic expression supplied as text. Explain the requirements you would clarify and how you would organize tokenization, parsing, and evaluation once those requirements are known. ### Part 1 — Define the Expression Language Identify the numeric forms, operators, precedence, associativity, whitespace, grouping, and error rules that must be specified. Explain why the phrase string calculator does not settle these choices. #### What This Part Should Cover Distinguish required clarifications from any hypothetical language chosen for illustration. Include negative numbers, division semantics if division exists, and malformed input behavior. ### Part 2 — Explain a Conditional Evaluation Design Choose a small, explicitly hypothetical grammar and describe how the calculator would process it. Explain how adding operator precedence or parentheses changes the parsing approach. Discuss correctness, complexity, and useful tests. #### What This Part Should Cover A clear separation of lexical tokens from grammatical structure and numerical evaluation, with an approach appropriate to the stated assumptions. ### Constraints The supported operators, numeric domain, grammar, input-size limits, and error behavior are intentionally unresolved. No particular external problem or calculator variant is assumed. This is a conceptual design exercise; there is no single fixed executable contract or expected numeric output. ### Clarifying Questions - Are values integers, decimals, or another numeric type, and can they be signed? - Which operators are supported, and what are their precedence and associativity rules? - Are parentheses, whitespace, unary operators, and empty input allowed? - How should overflow, division by zero, and invalid syntax be reported? ```hint Distinguish unary and binary operators The same character can mean negation or subtraction depending on where it appears in the grammar. ``` ### What a Strong Answer Covers - The unresolved language and numerical semantics without inventing a definitive contract. - A coherent conditional tokenizer/parser/evaluator design and its invariants. - Tests for precedence, grouping, boundaries, and malformed expressions when those features are in scope. ### Follow-up Questions - How would the parser change if parentheses were introduced? - How would you report the location of an invalid token without evaluating a malformed expression?