YREA-SLS/human_todos_ideas.md

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<T>`**
```
(Stack<Any> -- Size) depth:    // Full stack reference
(String Stack<Any> --) printf: // String + stack reference
```
- **Pros**: Explicit that it operates on the stack itself, type-safe
- **Cons**: Adds conceptual complexity, what does consuming `Stack<T>` 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