diff options
Diffstat (limited to 'js/scripting-lang/FIXME.md')
| -rw-r--r-- | js/scripting-lang/FIXME.md | 106 |
1 files changed, 0 insertions, 106 deletions
diff --git a/js/scripting-lang/FIXME.md b/js/scripting-lang/FIXME.md deleted file mode 100644 index b71be48..0000000 --- a/js/scripting-lang/FIXME.md +++ /dev/null @@ -1,106 +0,0 @@ -# FIXME - Issues and Fixes - -## Current Status: 8/13 tests passing - -### ✅ Phase 1: Critical Issues (COMPLETED) -- **Unary Minus Operator**: ✅ Fixed - Added `UnaryMinusExpression` parsing and evaluation -- **Stack Overflow Issues**: ✅ Fixed - Resolved circular dependencies and infinite recursion -- **Test Runner Overconfidence**: ✅ Fixed - Added robust error handling and exit codes -- **IO Operation Parsing**: ✅ Fixed - Moved IO parsing to proper precedence level -- **First-Class Functions**: ✅ Fixed - Added `TokenType.FUNCTION_REF` to function call detection -- **Function Definitions Test**: ✅ Fixed - Corrected assertion and duplicate variable assignment -- **Parser Regression Fix**: ✅ Fixed - Removed overly broad `TokenType.MINUS` check that was breaking binary operations -- **Parser Ambiguity with Unary Minus Arguments**: ✅ Fixed - Added special case in `parseExpression()` to handle `FunctionReference MINUS` pattern - -### 🔄 Phase 2: Medium Priority Issues (IN PROGRESS) - -#### Logical Operator Precedence Issue -- **Issue**: `isEven 10 and isPositive 5` is parsed as `isEven(10 and isPositive(5))` instead of `(isEven 10) and (isPositive 5)` -- **Root Cause**: Logical operators (`and`, `or`, `xor`) have the same precedence as arithmetic operators in `parseExpression()` -- **Impact**: Complex expressions like `add (multiply 3 4) (isEven 10 and isPositive 5)` fail -- **Status**: 🔄 In Progress - Need to implement proper operator precedence hierarchy -- **Solution Plan**: - 1. Create separate precedence levels for logical operators - 2. Ensure function calls have higher precedence than logical operators - 3. Test with integration scenarios - -#### Integration Test Failures -- **Basic Features Integration**: "Assertion failed" - Due to logical operator precedence issue -- **Pattern Matching Integration**: "Expected closing parenthesis" - Related to precedence parsing -- **Functional Programming Integration**: "Assertion failed" - Related to precedence parsing - -#### Unit Test Failures -- **Arithmetic Operations**: "Assertion failed" - Need to investigate specific assertions -- **Case Expressions**: "Expected closing parenthesis" - Related to precedence parsing - -### 🔄 Phase 3: Validation and Documentation (PENDING) -- **Comprehensive Test Suite Validation**: Target: 13/13 tests passing -- **Update Documentation**: README.md and FIXME.md to reflect all resolved issues - -## Recent Fixes - -### ✅ Parser Ambiguity with Unary Minus Arguments (Latest Fix) -- **Issue**: `filter @isPositive -3` was parsed as `filter(@isPositive - 3)` instead of `filter(@isPositive, -3)` -- **Root Cause**: `parseExpression()` was treating `FunctionReference MINUS` as a binary minus operation -- **Solution**: Added special case in `parseExpression()` to detect when left operand is `FunctionReference` and next token is `MINUS`, returning the left operand instead of creating a binary operation -- **Status**: ✅ Resolved - Standard Library test now passes - -### ✅ Parser Regression Fix -- **Issue**: Recent changes introduced regression where binary minus operations were incorrectly parsed as function calls -- **Root Cause**: Overly broad `TokenType.MINUS` check in function call detection logic -- **Solution**: Removed `TokenType.MINUS` from function call detection in `parsePrimary()` -- **Status**: ✅ Resolved - Basic arithmetic operations restored - -## Next Steps - -### Immediate Priority (Phase 2) -1. **🔧 Fix Logical Operator Precedence** - - **Problem**: Logical operators need lower precedence than function calls - - **Current State**: `isEven 10 and isPositive 5` → `isEven(10 and isPositive(5))` ❌ - - **Target State**: `isEven 10 and isPositive 5` → `(isEven 10) and (isPositive 5)` ✅ - - **Approach**: - - Create `parseLogicalExpression()` function with lowest precedence - - Modify `parseExpression()` to handle only arithmetic and comparison operators - - Update function call parsing to use appropriate precedence level - - Test with integration scenarios - -2. **🔧 Fix Parentheses Parsing with Logical Operators** - - **Problem**: `add (multiply 3 4) (isEven 10 and isPositive 5)` fails with "Expected closing parenthesis" - - **Root Cause**: Logical operators inside parentheses not handled correctly - - **Solution**: Ensure parentheses parsing respects operator precedence - -3. **🔧 Investigate Remaining Unit Test Failures** - - **Arithmetic Operations**: Check specific assertions that are failing - - **Case Expressions**: Fix parentheses parsing in case expression contexts - -### Validation Phase (Phase 3) -4. **✅ Run Full Test Suite** - - Target: 13/13 tests passing - - Validate all integration tests work correctly - - Ensure no regressions in previously fixed features - -5. **✅ Update Documentation** - - Update README.md with current status - - Document all fixes and remaining known issues - - Update examples to reflect current syntax - -## Technical Details - -### Operator Precedence Hierarchy (Target) -1. **Function calls** (highest precedence) -2. **Unary operators** (`-`, `not`) -3. **Multiplication/Division** (`*`, `/`, `%`) -4. **Addition/Subtraction** (`+`, `-`) -5. **Comparison operators** (`==`, `!=`, `<`, `>`, `<=`, `>=`) -6. **Logical operators** (`and`, `or`, `xor`) (lowest precedence) - -### Current Implementation Issues -- Logical operators are handled at the same level as arithmetic operators in `parseExpression()` -- Function call detection doesn't respect logical operator boundaries -- Parentheses parsing doesn't properly handle logical expressions - -### Success Metrics -- ✅ All unit tests pass (10/10) -- ✅ All integration tests pass (3/3) -- ✅ Complex expressions like `add (multiply 3 4) (isEven 10 and isPositive 5)` evaluate correctly -- ✅ No regressions in previously working features \ No newline at end of file |