Files

Selfhosting Dev 47f4ca0e44 📚 docs: Record field declaration design discussion in papers

## Summary
Documented the "init block vs fields-at-top" design discussion as a valuable example of AI-human collaboration in language design.

## Changes

### Paper G (AI Collaboration)
- Added field-declaration-design.md documenting the entire discussion flow
- Showcased how complex init block proposal evolved to simple "fields at top" rule
- Demonstrates AI's tendency toward complexity vs human intuition for simplicity

### Paper H (AI Practical Patterns)
- Added Pattern #17: "Gradual Refinement Pattern" (段階的洗練型)
- Documents the process: Complex AI proposal → Detailed analysis → Human insight → Convergence
- Field declaration design as a typical example

### Paper K (Explosive Incidents)
- Added Incident #046: "init block vs fields-at-top incident"
- Updated total count to 46 incidents
- Shows how a single human comment redirected entire design approach

## Design Decision
After analysis, decided that BoxIndex should remain a compiler-internal structure, not a core Box:
- Core Boxes: User-instantiable runtime values (String, Integer, Array, Map)
- Compiler internals: BoxIndex for name resolution (compile-time only)
- Clear separation of concerns between language features and compiler tools

## Philosophy
This discussion exemplifies key principles:
- The best design needs no explanation
- Constraints provide clarity, not limitation
- "Everything is Box" doesn't mean "compiler internals are Boxes"
- AI tends toward theoretical completeness; humans toward practical simplicity

🐱 Sometimes the simplest answer is right in front of us\!

2025-09-16 14:57:05 +09:00

3.4 KiB

Raw Blame History

フィールド宣言位置の制約設計（2025-09-15）

概要

Boxのフィールド宣言がメソッドの間に散在できる問題に対する設計相談。AIとの対話を通じて、複雑なinitブロック案から「フィールドは先頭のみ」という単純明快なルールへ収束した事例。

相談の流れ

1. 問題提起（ユーザー）

ところで　今のフィールド変数の書き方
これだと　どこでもかけちゃうのかな

現状の問題：

box MessyBox {
    field1: StringBox
    method1() { }
    field2: IntegerBox  // メソッドの間に散在
    birth() { }
    field3: BoolBox     // さらに散在
}

2. 初期提案（ユーザー）

init
{
    この中に書く　書き方は今のと同じ
}
init文復活させて　この中だけにフィールドを書くというのはありかもしれない

3. AI分析（Claude）

initブロック案の評価

メリット:

明確な構造化
フィールド一覧の固定位置
パース簡略化
将来の拡張性（アノテーション等）

デメリット:

冗長性（小さなBoxでも必須）
Everything is Box哲学との齟齬
学習コスト増加

ハイブリッド提案

// 小さなBoxはそのまま
box SmallBox {
    name: StringBox
    birth(n) { me.name = n }
}

// 大きなBoxはinitで整理
box LargeBox {
    init {
        field1: TypeBox
        field2: TypeBox
    }
    birth() { }
}

4. ユーザーの洞察

それか　フィールドは　boxの先頭だけにかけるというルールはありかもしれにゃい

5. 収束（AI）

「フィールドは先頭のみ」ルールの支持：

box CleanBox {
    // フィールドは必ず先頭にまとめる
    field1: StringBox
    field2: IntegerBox
    
    // ここから下はメソッドのみ
    birth() { }
    method1() { }
}

決定的な利点:

特別な構文不要（initブロック不要）
多くの言語で採用されている標準
パーサー実装が簡潔
Everything is Box哲学と調和

設計哲学の体現

単純性の追求: 複雑な構文（initブロック）より単純なルール
制約による明快さ: 自由度を制限して可読性を向上
段階的移行: 警告→エラーの段階的導入
既存の知見活用: 他言語の標準的アプローチを採用

AI協働パターン：段階的洗練型

複雑な提案から開始（initブロック、ハイブリッド案）
詳細な分析提供（メリット・デメリット・他言語比較）
ユーザーの直感的提案（先頭のみルール）
AIが即座に価値を認識
実装戦略まで具体化

→ AIは複雑に考えがちだが、人間の直感が本質を突く好例

教訓

最良の設計は説明不要な設計
制約は自由度を奪うのではなく、明快さを与える
"Everything is Box"は複雑さの言い訳ではない
AIの分析力と人間の直感の相補性

実装計画

Phase 15.4: 警告モード（NYASH_STRICT_FIELD_ORDER=warn）
Phase 16: エラーモード（NYASH_STRICT_FIELD_ORDER=error）
Phase 17: デフォルト化

3.4 KiB Raw Blame History Unescape Escape