From e19a068ba3c9a4a22c0b20a427b7249eb0d2c64e Mon Sep 17 00:00:00 2001 From: Kyler Date: Sun, 26 Oct 2025 00:27:33 -0600 Subject: [PATCH] v0.6.1 ideas --- human_todos_ideas.md | 289 +++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 289 insertions(+) create mode 100644 human_todos_ideas.md diff --git a/human_todos_ideas.md b/human_todos_ideas.md new file mode 100644 index 0000000..2db4764 --- /dev/null +++ b/human_todos_ideas.md @@ -0,0 +1,289 @@ +Perfect! I've completed all the non-human TODOs. Now let me discuss the human TODOs with detailed suggestions: + +--- + +## Human TODOs - Discussion & Recommendations + +### 1. **How to identify an unspecified number of arguments?** + +**The Problem**: Some operations need variable numbers of arguments: +- `depth` consumes the entire stack to count it +- `printf` might take a format string + arbitrary values + +**Options:** + +**A) Ellipsis notation: `...`** +``` +(... -- Size) depth: // Entire stack +(String ... --) printf: // String + any number of args +``` +- **Pros**: Common in many languages, intuitive, clear intent +- **Cons**: Ambiguous about types, makes type checking harder + +**B) Array-based variadic: `[T]`** +``` +([T] -- Size) depth: // Takes array of any type +(String [T] --) printf: // String + array of values +``` +- **Pros**: Type-safe, forces bundling arguments, easier to implement +- **Cons**: Requires wrapping args in array syntax, less ergonomic + +**C) Special stack type: `Stack`** +``` +(Stack -- Size) depth: // Full stack reference +(String Stack --) printf: // String + stack reference +``` +- **Pros**: Explicit that it operates on the stack itself, type-safe +- **Cons**: Adds conceptual complexity, what does consuming `Stack` mean? + +**D) Constraint-based: `T...` (typed variadic)** +``` +(T... -- Size) depth: // Homogeneous variadics +(String Stringifiable... --) printf: // Constrained variadics +``` +- **Pros**: Type-safe, clear constraints, flexible +- **Cons**: More complex type system, harder to implement + +**E) Just use current system (no variadic syntax)** +``` +// For depth: it actually just returns depth, doesn't consume +(-- Size) depth: // Just pushes depth + +// For printf: use array +(String [Stringifiable] --) printf: +"x=%d y=%d" [x y] printf +``` +- **Pros**: Simplest, no language changes needed +- **Cons**: `depth` semantics unclear, printf less ergonomic + +**My Recommendation**: **Option E + D (hybrid)** +- For now, don't add variadic syntax - use arrays +- Document that `depth` is a special zero-argument operator that just pushes depth +- If variadics become essential later, add **Option D** (typed variadics with `T...`) + +### 2. **Do all inheritances need to be defined before the trait is?** + +**Options:** + +**A) Yes, inheritance must be before trait** +``` +[ ::Addable ::Multiplyable ] ::Number inher +{ } ::Number trait +``` +- **Pros**: Clear declaration order, simpler parser, inheritance is explicit +- **Cons**: Separates related declarations, two statements needed + +**B) No, allow inline inheritance** +``` +{ } ::Number<::Addable ::Multiplyable> trait +``` +- **Pros**: Single statement, more compact +- **Cons**: Confusing syntax, inheritance looks like generics + +**C) Inheritance in trait body** +``` +{ + inherits: Addable Multiplyable + // methods here +} ::Number trait +``` +- **Pros**: Single statement, clear syntax +- **Cons**: Breaks postfix philosophy, special syntax inside trait body + +**My Recommendation**: **Option A (current design)** +- Keeps declarations explicit and ordered +- Maintains postfix consistency +- Parser knows about inheritance before processing trait body + +### 3. **Is the `inher` operator required?** + +**The Question**: Can empty inheritance work without `inher`? + +**Options:** + +**A) Yes, `inher` is required** (current) +``` +[ ::Addable ::Multiplyable ] ::Number inher +{ } ::Number trait +``` +- **Pros**: Explicit, clear intent, separates inheritance declaration +- **Cons**: Extra operator, more verbose + +**B) No, merge into `trait` operator** +``` +[ ::Addable ::Multiplyable ] { } ::Number trait +``` +- **Pros**: More concise, fewer operators, still clear +- **Cons**: Array prefix becomes ambiguous - is it inheritance or something else? + +**My Recommendation**: **Option A (keep `inher`)** +- Makes inheritance explicit and unambiguous +- Allows future extensions (diamond inheritance rules, conflict resolution) +- Parser can validate inheritance separately from trait definition + +### 4. **Consider removing `inher` and replacing with `impl`?** +### 4. **Consider removing `inher` and replacing with `impl`?** + +**The Idea**: Could trait inheritance use the same mechanism as trait implementation? + +**Current System**: +``` +// Inheritance +[ ::Addable ::Multiplyable ] ::Number inher +{ } ::Number trait + +// Implementation +::Addable { ... } ::i32 impl +``` + +**Options:** + +**A) Keep separate `inher` and `impl`** (current) +- **Pros**: + - Clear distinction between "is-a" (inheritance) and "implements" relationships + - Inheritance affects trait definition itself, impl affects types + - Easier to reason about: traits inherit, types implement + - Can have different rules and semantics for each +- **Cons**: + - Two operators with similar-sounding purposes + - More language constructs to learn + +**B) Use `impl` for both** +``` +// Trait inherits from other traits +::Addable { } ::Number impl +::Multiplyable { } ::Number impl + +// Type implements trait +::Addable { ... } ::i32 impl +``` +- **Pros**: + - Fewer operators + - Unified concept: "X implements Y" + - Simpler mental model +- **Cons**: + - Ambiguous: does `::Addable { } ::Number impl` mean Number implements Addable or inherits from it? + - Can't declare multiple inheritance in one statement + - Would need different semantics based on whether target is a trait or type + - Loses the clear "combine these traits" semantics + +**C) Use `impl` with array syntax** +``` +// Multiple inheritance +[ ::Addable ::Multiplyable ] { } ::Number impl + +// Single inheritance +::Drawable { } ::GameObject impl + +// Type implementation (unchanged) +::Addable { ... } ::i32 impl +``` +- **Pros**: + - Unified operator, but array syntax distinguishes inheritance + - Still allows single-statement multiple inheritance + - Semantics clear from syntax +- **Cons**: + - Array prefix is overloaded (sometimes inheritance, sometimes not) + - Potential ambiguity: is `[::Trait1 ::Trait2]` always inheritance? + +**D) Different syntax entirely** +``` +// Inheritance with "extends" +::Number extends [ ::Addable ::Multiplyable ] { } trait + +// Keep impl for implementations +::Addable { ... } ::i32 impl +``` +- **Pros**: + - Very explicit and clear + - Familiar to OOP programmers + - No ambiguity +- **Cons**: + - Breaks postfix notation (extends comes before trait) + - Adds keyword/operator that's not fully postfix + +**My Recommendation**: **Option A (keep separate)** + +Here's why: +1. **Semantic Clarity**: Inheritance and implementation are fundamentally different: + - Inheritance: `Number` **is composed of** `Addable` + `Multiplyable` + more + - Implementation: `i32` **provides behavior for** `Addable` operations + +2. **Different Use Cases**: + - `inher`: Declares trait relationships at trait definition time + - `impl`: Provides implementations for types (or default implementations for traits) + +3. **Implementation Flexibility**: Keeping them separate allows: + - Different resolution rules for inherited methods + - Diamond inheritance handling + - Multiple inheritance from many traits in one statement + +4. **Parser Benefits**: The `inher` operator clearly signals "the next trait declaration will inherit from these" + +--- + +## Summary of Recommendations + +| TODO | Recommendation | Rationale | +|------|---------------|-----------| +| **Variadic arguments** | **Don't add special syntax yet**. Use arrays for now, document `depth` as zero-arg. Consider `T...` syntax only if truly needed later. | Keeps language simple, arrays work for most cases, can add later if needed | +| **Inheritance before trait?** | **Yes, keep current requirement**. `inher` must come before `trait` definition. | Clear ordering, simpler parser, explicit dependencies | +| **Is `inher` required?** | **Yes, keep `inher` operator**. It makes inheritance explicit and unambiguous. | Clear intent, allows future extensions, parser can validate separately | +| **Replace `inher` with `impl`?** | **No, keep them separate**. They represent different relationships with different semantics. | Semantic clarity, different use cases, better tooling support | + +--- + +## Additional Considerations + +### For Variadic Arguments + +If you later decide you *do* need variadic syntax, I'd suggest this progression: + +**Phase 1 (Current)**: No variadic syntax +``` +(-- Size) depth: // Just returns depth +(String [Stringifiable] --) printf: // Use arrays +``` + +**Phase 2 (If needed)**: Add typed variadics +``` +(String Stringifiable... --) printf: // Zero or more Stringifiable values +``` + +This gives you a simple starting point with a clear upgrade path. + +### For Inheritance Syntax + +The current design is actually quite elegant: + +``` +[ ::Trait1 ::Trait2 ::Trait3 ] ::NewTrait inher +{ + // Additional methods +} ::NewTrait trait +``` + +This clearly shows: +1. What we're inheriting from (the array) +2. That we're declaring inheritance (the `inher` operator) +3. The trait being defined (the `trait` operator) + +It's verbose but crystal clear, which is good for a systems language. + +--- + +Would you like me to add any of these design discussions to the specification document itself, or would you like to explore any of these options in more detail? + +--- + +--- + +My choices for 0.6.1: +Following your suggestions: +- **Variadic arguments** - Don't add special syntax *yet* +- **Inheritance before trait?** - Yes, keep current requirement +- **Replace `inher` with `impl`?** - No, keep them separate +My own choice: +- **Is `inher` required?** - No, merge into trait operator + +And for Variadic arguments do add the array of stuff that will be the current system