diff options
Diffstat (limited to 'js/scripting-lang/FIXME.md')
| -rw-r--r-- | js/scripting-lang/FIXME.md | 100 |
1 files changed, 0 insertions, 100 deletions
diff --git a/js/scripting-lang/FIXME.md b/js/scripting-lang/FIXME.md deleted file mode 100644 index e93674a..0000000 --- a/js/scripting-lang/FIXME.md +++ /dev/null @@ -1,100 +0,0 @@ -# FIXME: IO Operation Parsing Bug - -## Problem Summary - -- The parser fails with `Unexpected token in parsePrimary: DOT` when processing IO operations like `..out`, `..assert`, or `..in` at the top level in a script. -- This occurs in the comprehensive test suite and any script that uses IO operations as standalone statements. - -## Observations - -- The **lexer** correctly emits `IO_OUT`, `IO_ASSERT`, and `IO_IN` tokens for `..out`, `..assert`, and `..in`. -- The **parser**'s main loop (`walk()`) now delegates to `parsePrimary()`, which only handles IO tokens if they are the first token in a statement. -- If a statement starts with a DOT (as in `..out`), and the parser is not expecting it, it throws an error. -- The bug is not in the lexer (no stray DOT tokens for IO ops), but in the parser's handling of top-level statements. -- The bug manifests after a block of expressions/statements, when the next statement is an IO operation. - -## What We Have in Place - -- Lexer emits correct IO tokens for `..out`, `..assert`, `..in`. -- `parsePrimary()` handles IO tokens if they are the first token in a statement. -- Table access, dot notation, and function calls with table access are all working. -- The parser's main loop is too generic and does not explicitly handle IO tokens at the top level. - -## Step-by-Step Plan to Fix - -1. **Confirm Lexer Output** ✅ **COMPLETED** - - Run the lexer in debug mode on a failing script to confirm that IO operations are tokenized as `IO_OUT`, `IO_ASSERT`, or `IO_IN` (not as DOT tokens). - - **Result:** Lexer correctly emits IO tokens. - -2. **Fix Decimal Number Lexing** ✅ **COMPLETED** - - **Issue Found:** Lexer was incorrectly tokenizing decimal numbers like `3.3333333333333335` as separate tokens: `NUMBER(3)`, `DOT`, `NUMBER(3333333333333335)`. - - **Fix Applied:** Updated lexer to handle decimal numbers as single `NUMBER` tokens with `parseFloat()`. - - **Result:** Decimal numbers are now correctly tokenized. - -3. **Fix Interpreter Number Evaluation** ✅ **COMPLETED** - - **Issue Found:** Interpreter was using `parseInt()` for `NumberLiteral` evaluation, truncating decimal values. - - **Fix Applied:** Changed all three `NumberLiteral` cases to use `parseFloat()` instead of `parseInt()`. - - **Result:** Decimal numbers are now correctly evaluated. - -4. **Patch Parser IO Handling** ✅ **COMPLETED** - - **Issue Found:** Parser's main loop wasn't properly handling IO tokens at the top level. - - **Fix Applied:** Added explicit IO token handling in the `walk()` function before calling `parsePrimary()`. - - **Result:** IO operations are now correctly parsed as standalone statements. - -5. **Test Comprehensive Suite** ❌ **BLOCKED** - - **Issue:** Stack overflow error when running the full comprehensive test suite. - - **Status:** Need to investigate what's causing the stack overflow in the comprehensive test. - -## Current Status - -**Fixed Issues:** -- ✅ IO operation parsing (lexer, parser, interpreter) -- ✅ Decimal number handling (lexer and interpreter) -- ✅ Basic arithmetic operations with floating point -- ✅ IO operations as standalone statements -- ✅ Case expression parsing (including wildcard patterns) -- ✅ Function definitions and calls -- ✅ Wildcard token recognition in lexer - -**Remaining Issues:** -- ❌ Stack overflow in comprehensive test suite -- ❌ Need to identify what specific pattern in the comprehensive test is causing the stack overflow - -## Investigation Results - -**Successfully Isolated and Fixed:** -1. **Case Expression Parsing** - Fixed wildcard token recognition and case expression parsing -2. **Function Definitions** - Confirmed working correctly -3. **Basic Language Features** - All core features (arithmetic, IO, functions, case expressions) work correctly - -**Stack Overflow Analysis:** -- The stack overflow occurs in the comprehensive test suite but not in isolated tests -- All individual language constructs work correctly when tested in isolation -- The issue is likely caused by a specific combination or pattern of constructs in the comprehensive test - -## Next Steps - -1. **Systematic Comprehensive Test Analysis** - - Test the comprehensive test file section by section to identify the exact location of the stack overflow - - Look for patterns that might cause infinite recursion (e.g., complex nested expressions, specific function call patterns) - - Check for any language constructs that might not be handled correctly in combination - -2. **Parser Debugging** - - Add more detailed debugging to identify the exact parsing step that causes the stack overflow - - Check for any circular dependencies or infinite loops in the parser logic - -3. **Complete Testing** - - Once stack overflow is resolved, run the full comprehensive test suite - - Verify all language features work correctly together - ---- - -**Status:** -- Lexer: ✅ Fixed (decimal numbers, IO tokens, wildcards) -- Parser: ✅ Fixed (IO handling, case expressions, wildcards) but has stack overflow issue -- Interpreter: ✅ Fixed (decimal number evaluation, case expressions) -- Test suite: ❌ Blocked by stack overflow in comprehensive test - ---- - -**Next step:** Systematically analyze the comprehensive test to identify the exact cause of the stack overflow. \ No newline at end of file |