When users write `run main() with {}` at top level instead of
`let _ = run main() with {}`, provide a helpful error message
explaining the correct syntax instead of the generic "Expected
declaration" error.
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
1. String == comparison now uses strcmp instead of pointer comparison
- Added check in emit_expr() for BinaryOp::Eq/Ne on strings
- Also fixed in emit_expr_with_env() for closures
2. Support `let _ = expr` pattern to discard values
- Parser now accepts underscore in let bindings (both blocks and expressions)
- C backend emits (void)expr; for underscore patterns
3. Fix list head/tail/get memory management
- Added lux_incref() when extracting elements from lists
- Prevents use-after-free when original list is freed
4. String.startsWith was already implemented (verified working)
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
- Fix parse_list_expr to skip newlines between list elements
- Add `pub` keyword to all exported functions in stdlib/html.lux
- Change List.foldl to List.fold (matching built-in name)
- Update weaknesses document with fixed issues
The module import system now works correctly. This enables:
- import stdlib/html to work as expected
- html.div(), html.render() etc. to be accessible
- Multi-line list expressions in Lux source files
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
- Add ErrorCode enum with categorized codes (E01xx parse, E02xx type,
E03xx name, E04xx effect, E05xx pattern, E06xx module, E07xx behavioral)
- Extend Diagnostic struct with error code, expected/actual types, and
secondary spans
- Add format_type_diff() for visual type comparison in error messages
- Add help URLs linking to lux-lang.dev/errors/{code}
- Update typechecker, parser, and interpreter to use error codes
- Categorize errors with specific codes and helpful hints
Error messages now show:
- Error code in header: -- ERROR[E0301] ──
- Clear error category title
- Visual type diff for type mismatches
- Context-aware hints
- "Learn more" URL for documentation
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
- Parser and typechecker updates for new features
- Schema evolution refinements
- Type system enhancements
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
- Record equality: add Record case to values_equal in interpreter
- Invalid escapes: error on unknown escape sequences in lexer
- Unknown effects: validate effect names in check_function with suggestions
- Circular types: add DFS cycle detection in check_type_cycles
- Parser: require | for enum variants, enabling proper type alias syntax
All 265 tests pass.
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
- Add string concatenation support to + operator in typechecker
- Register ADT constructors in both type environment and interpreter
- Bind handlers as values so they can be referenced in run...with
- Fix effect checking to use subset instead of exact match
- Add built-in effects (Console, Fail, State) to run block contexts
- Suppress dead code warnings in diagnostics, modules, parser
Update all example programs with:
- Expected output documented in comments
- Proper run...with statements to execute code
Add new example programs:
- behavioral.lux: pure, idempotent, deterministic, commutative functions
- pipelines.lux: pipe operator demonstrations
- statemachine.lux: ADT-based state machines
- tailcall.lux: tail call optimization examples
- traits.lux: type classes and pattern matching
Add documentation:
- docs/IMPLEMENTATION_PLAN.md: feature roadmap and status
- docs/PERFORMANCE_AND_TRADEOFFS.md: performance analysis
Add benchmarks for performance testing.
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
Add support for doc comments (/// syntax) that can be attached to
declarations for documentation purposes. The implementation:
- Adds DocComment token kind to lexer
- Recognizes /// as doc comment syntax (distinct from // regular comments)
- Parses consecutive doc comments and combines them into a single string
- Adds doc field to FunctionDecl, TypeDecl, LetDecl, EffectDecl, TraitDecl
- Passes doc comments through parser to declarations
- Multiple consecutive doc comment lines are joined with newlines
This enables documentation extraction and could be used for generating
API docs, IDE hover information, and REPL help.
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
Add support for type classes (traits) with full parsing, type checking, and
validation. The implementation includes:
- Trait declarations: trait Show { fn show(x: T): String }
- Trait implementations: impl Show for Int { fn show(x: Int) = ... }
- Super traits: trait Ord: Eq { ... }
- Trait constraints in where clauses: where T: Show + Eq
- Type parameters on traits: trait Functor<F> { ... }
- Default method implementations
- Validation of required method implementations
This provides a foundation for ad-hoc polymorphism and enables
more expressive type-safe abstractions.
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
Implement beautiful, informative error messages inspired by Elm:
- Rich diagnostic rendering with source code snippets
- Colored output with proper underlines showing error locations
- Categorized error titles (Type Mismatch, Unknown Name, etc.)
- Contextual hints and suggestions for common errors
- Support for type errors, runtime errors, and parse errors
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
Implement behavioral properties for functions including:
- Property annotations: is pure, is total, is idempotent, is deterministic, is commutative
- Where clause constraints: where F is pure
- Result refinements: where result >= 0 (parsing only, not enforced)
Key changes:
- AST: BehavioralProperty enum, WhereClause enum, updated FunctionDecl
- Lexer: Added keywords (is, pure, total, idempotent, deterministic, commutative, where, assume)
- Parser: parse_behavioral_properties(), parse_where_clauses(), parse_single_property()
- Types: PropertySet for tracking function properties, updated Function type
- Typechecker: Verify pure functions don't have effects, validate where clause type params
Properties are informational/guarantees rather than type constraints - a pure
function can be used anywhere a function is expected. Property requirements
are meant to be enforced via where clauses (future work: call-site checking).
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
