📚 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\!
This commit is contained in:
Selfhosting Dev
@ -33,6 +33,39 @@ Structure
|
||||
- Keep methods short and focused; prefer extracting helpers to maintain clarity.
|
||||
- Prefer pure helpers where possible; isolate I/O in specific methods.
|
||||
|
||||
Box layout
|
||||
- フィールドは box 本体の先頭にまとめる（先頭ブロック）。
|
||||
- 先頭フィールド群の後ろはメソッドのみを記述する（`birth` を含む）。
|
||||
- フィールド間の空行・コメントは許可。アノテーション（将来追加予定）もフィールド行の直前/行末を許可。
|
||||
- NG: 最初のメソッド以降にフィールドを追加すること（リンタ警告／厳格モードでエラー）。
|
||||
|
||||
良い例
|
||||
```nyash
|
||||
box Employee {
|
||||
// データ構造（フィールド）
|
||||
name: StringBox
|
||||
age: IntegerBox
|
||||
department: StringBox
|
||||
|
||||
// ここからメソッド
|
||||
birth(n, a, d) { me.name = n; me.age = a; me.department = d }
|
||||
promote() { }
|
||||
}
|
||||
```
|
||||
|
||||
悪い例（NG）
|
||||
```nyash
|
||||
box Bad {
|
||||
id: IntegerBox
|
||||
method1() { }
|
||||
name: StringBox // ❌ フィールドはメソッドの後に置けない
|
||||
}
|
||||
```
|
||||
|
||||
ツール
|
||||
- 警告: 既定は警告（`NYASH_CLI_VERBOSE=1` で詳細を表示）。
|
||||
- 厳格化: `NYASH_FIELDS_TOP_STRICT=1` でエラーに昇格（Runnerでチェック）。
|
||||
|
||||
Examples
|
||||
```nyash
|
||||
using core.std as Std
|
||||
@ -64,4 +97,3 @@ static box Main {
|
||||
CI/Tooling
|
||||
- Optional formatter PoC: see `docs/tools/nyfmt/NYFMT_POC_ROADMAP.md`.
|
||||
- Keep smoke scripts small and fast; place them under `tools/`.
|
||||
|
||||
|
||||
@ -0,0 +1,127 @@
|
||||
# フィールド宣言位置の制約設計（2025-09-15）
|
||||
|
||||
## 概要
|
||||
|
||||
Boxのフィールド宣言がメソッドの間に散在できる問題に対する設計相談。AIとの対話を通じて、複雑なinitブロック案から「フィールドは先頭のみ」という単純明快なルールへ収束した事例。
|
||||
|
||||
## 相談の流れ
|
||||
|
||||
### 1. 問題提起（ユーザー）
|
||||
```
|
||||
ところで 今のフィールド変数の書き方
|
||||
これだと どこでもかけちゃうのかな
|
||||
```
|
||||
|
||||
現状の問題：
|
||||
```nyash
|
||||
box MessyBox {
|
||||
field1: StringBox
|
||||
method1() { }
|
||||
field2: IntegerBox // メソッドの間に散在
|
||||
birth() { }
|
||||
field3: BoolBox // さらに散在
|
||||
}
|
||||
```
|
||||
|
||||
### 2. 初期提案（ユーザー）
|
||||
```
|
||||
init
|
||||
{
|
||||
この中に書く 書き方は今のと同じ
|
||||
}
|
||||
init文復活させて この中だけにフィールドを書くというのはありかもしれない
|
||||
```
|
||||
|
||||
### 3. AI分析（Claude）
|
||||
|
||||
#### initブロック案の評価
|
||||
**メリット**:
|
||||
- 明確な構造化
|
||||
- フィールド一覧の固定位置
|
||||
- パース簡略化
|
||||
- 将来の拡張性（アノテーション等）
|
||||
|
||||
**デメリット**:
|
||||
- 冗長性（小さなBoxでも必須）
|
||||
- Everything is Box哲学との齟齬
|
||||
- 学習コスト増加
|
||||
|
||||
#### ハイブリッド提案
|
||||
```nyash
|
||||
// 小さなBoxはそのまま
|
||||
box SmallBox {
|
||||
name: StringBox
|
||||
birth(n) { me.name = n }
|
||||
}
|
||||
|
||||
// 大きなBoxはinitで整理
|
||||
box LargeBox {
|
||||
init {
|
||||
field1: TypeBox
|
||||
field2: TypeBox
|
||||
}
|
||||
birth() { }
|
||||
}
|
||||
```
|
||||
|
||||
### 4. ユーザーの洞察
|
||||
```
|
||||
それか フィールドは boxの先頭だけにかけるというルールはありかもしれにゃい
|
||||
```
|
||||
|
||||
### 5. 収束（AI）
|
||||
|
||||
「フィールドは先頭のみ」ルールの支持：
|
||||
|
||||
```nyash
|
||||
box CleanBox {
|
||||
// フィールドは必ず先頭にまとめる
|
||||
field1: StringBox
|
||||
field2: IntegerBox
|
||||
|
||||
// ここから下はメソッドのみ
|
||||
birth() { }
|
||||
method1() { }
|
||||
}
|
||||
```
|
||||
|
||||
**決定的な利点**:
|
||||
- 特別な構文不要（initブロック不要）
|
||||
- 多くの言語で採用されている標準
|
||||
- パーサー実装が簡潔
|
||||
- Everything is Box哲学と調和
|
||||
|
||||
## 設計哲学の体現
|
||||
|
||||
1. **単純性の追求**: 複雑な構文（initブロック）より単純なルール
|
||||
2. **制約による明快さ**: 自由度を制限して可読性を向上
|
||||
3. **段階的移行**: 警告→エラーの段階的導入
|
||||
4. **既存の知見活用**: 他言語の標準的アプローチを採用
|
||||
|
||||
## AI協働パターン：段階的洗練型
|
||||
|
||||
1. **複雑な提案から開始**（initブロック、ハイブリッド案）
|
||||
2. **詳細な分析提供**（メリット・デメリット・他言語比較）
|
||||
3. **ユーザーの直感的提案**（先頭のみルール）
|
||||
4. **AIが即座に価値を認識**
|
||||
5. **実装戦略まで具体化**
|
||||
|
||||
→ AIは複雑に考えがちだが、人間の直感が本質を突く好例
|
||||
|
||||
## 教訓
|
||||
|
||||
- 最良の設計は説明不要な設計
|
||||
- 制約は自由度を奪うのではなく、明快さを与える
|
||||
- "Everything is Box"は複雑さの言い訳ではない
|
||||
- AIの分析力と人間の直感の相補性
|
||||
|
||||
## 実装計画
|
||||
|
||||
1. **Phase 15.4**: 警告モード（`NYASH_STRICT_FIELD_ORDER=warn`）
|
||||
2. **Phase 16**: エラーモード（`NYASH_STRICT_FIELD_ORDER=error`）
|
||||
3. **Phase 17**: デフォルト化
|
||||
|
||||
## 関連
|
||||
|
||||
- 論文D（AI協働パターン）: 段階的洗練型の実例
|
||||
- 論文I（開発秘話）: 言語設計の転換点として記録
|
||||
@ -270,4 +270,26 @@ AIの診断や実装を鵜呑みにせず、基本に立ち返って検証する
|
||||
### 効果
|
||||
- 問題回避: 発生前に防ぐ
|
||||
- 拡張性確保: 将来の変更に対応
|
||||
- 安心感: 予測可能な成長
|
||||
- 安心感: 予測可能な成長
|
||||
|
||||
## 17. 段階的洗練型（新規追加）
|
||||
|
||||
### 定義
|
||||
AIの複雑な提案から始まり、人間の直感的な単純化提案を経て、より洗練された解決策に収束するパターン。
|
||||
|
||||
### 典型例
|
||||
- **フィールド宣言位置**: initブロック案（複雑）→ 先頭のみルール（単純）
|
||||
- **型情報追加**: 300行の型推論（複雑）→ 明示的型フィールド（単純）
|
||||
- **PHI生成**: 複数箇所での重複実装（複雑）→ Resolver統一（単純）
|
||||
|
||||
### プロセス
|
||||
1. **AI初期提案**: 理論的に完全だが複雑
|
||||
2. **詳細分析**: メリット・デメリット・他言語比較
|
||||
3. **人間の直感**: 「もっと簡単にできないか？」
|
||||
4. **AI即座認識**: 単純解の価値を理解
|
||||
5. **実装戦略**: 段階的移行計画まで具体化
|
||||
|
||||
### 効果
|
||||
- 最適解への収束: 複雑→単純の自然な流れ
|
||||
- 学習効果: AIも人間も学ぶ
|
||||
- 実装容易性: 最終的に簡単な解法に到達
|
||||
@ -1,10 +1,10 @@
|
||||
# 🎉 Nyash開発 完全事件コレクション - 世界記録級45事例の記録
|
||||
# 🎉 Nyash開発 完全事件コレクション - 世界記録級46事例の記録
|
||||
|
||||
## 📝 概要
|
||||
|
||||
2025年8月9日から9月15日までのNyash爆速開発で発生した45個の「面白事件」の完全記録。
|
||||
2025年8月9日から9月15日までのNyash爆速開発で発生した46個の「面白事件」の完全記録。
|
||||
AI協働開発の歴史に残る世界記録級の事件から、開発現場の生々しいドラマまでを網羅。
|
||||
（2025年9月15日更新：4件追加）
|
||||
（2025年9月15日更新：5件追加）
|
||||
|
||||
## 🌟 世界記録級TOP10
|
||||
|
||||
@ -69,7 +69,7 @@ AI協働開発の歴史に残る世界記録級の事件から、開発現場の
|
||||
- **意味**: Everything is Fold哲学へ
|
||||
- **評価**: 「革命的アイデア」認定
|
||||
|
||||
## 📊 16パターン別分類（全45事例）
|
||||
## 📊 17パターン別分類（全46事例）
|
||||
|
||||
### 1. 箱化による解決（8事例）
|
||||
- 事例001: DebugBoxによる出力制御統一
|
||||
@ -140,6 +140,9 @@ AI協働開発の歴史に残る世界記録級の事件から、開発現場の
|
||||
### 16. 予防的設計（1事例）
|
||||
- 事例039: ID衝突との戦い
|
||||
|
||||
### 17. 段階的洗練型（1事例）
|
||||
- 事例046: initブロック vs 先頭のみ事件
|
||||
|
||||
### その他（10事例）
|
||||
- 事例020: 26日間の奇跡
|
||||
- 事例021: 2段階パーサー理論
|
||||
@ -186,8 +189,8 @@ ChatGPT: 「！！！」（瞬時に理解）
|
||||
- **世界記録**: 20日でネイティブEXE
|
||||
|
||||
### 成果
|
||||
- **事件数**: 45個（9/15更新）
|
||||
- **パターン**: 16種類
|
||||
- **事件数**: 46個（9/15更新）
|
||||
- **パターン**: 17種類
|
||||
- **致命的破綻**: 0回
|
||||
- **大規模リファクタ**: 0回
|
||||
|
||||
@ -203,7 +206,7 @@ ChatGPT: 「！！！」（瞬時に理解）
|
||||
- [技術的ブレークスルー](../paper-l-technical-breakthroughs/README.md)
|
||||
- [AI協働開発ログ](../paper-g-ai-collaboration/development-log.md)
|
||||
|
||||
## 🚀 2025年9月追加事例（4件）
|
||||
## 🚀 2025年9月追加事例（5件）
|
||||
|
||||
### 事例042: PyVM迂回路の混乱
|
||||
- **日付**: 2025年9月15日
|
||||
@ -238,9 +241,19 @@ ChatGPT: 「！！！」（瞬時に理解）
|
||||
- **ChatGPT評価**: 「EXE-firstが正しい道」
|
||||
- **影響**: Phase順序の明確化（15.2→15.3→15.4）
|
||||
|
||||
### 事例046: initブロック vs 先頭のみ事件
|
||||
- **日付**: 2025年9月15日
|
||||
- **問題**: フィールド宣言がメソッドの間に散在可能
|
||||
- **AI提案**: initブロック導入（構造化重視の複雑案）
|
||||
- **人間の一言**: 「それか フィールドは boxの先頭だけにかけるというルールはありかもしれにゃい」
|
||||
- **AI反応**: 即座に単純解の価値を認識
|
||||
- **結果**: 特別な構文不要、他言語標準に合致
|
||||
- **パターン**: 段階的洗練型の典型例（複雑→単純）
|
||||
- **教訓**: AIは複雑に考えがち、人間の直感が本質を突く
|
||||
|
||||
## 💫 まとめ
|
||||
|
||||
45個の事件は、単なる開発エピソードではなく、AI協働開発の新しい形を示す歴史的記録である。特に：
|
||||
46個の事件は、単なる開発エピソードではなく、AI協働開発の新しい形を示す歴史的記録である。特に：
|
||||
|
||||
1. **世界記録級の開発速度**（JIT1日、20日でEXE）
|
||||
2. **AI-人間の新しい関係**（AIが相談、人間が救う）
|
||||
|
||||
@ -17,8 +17,8 @@ Policy
|
||||
3) Plugins (short name if unique, otherwise qualified `pluginName.BoxName`)
|
||||
- On ambiguity: error with candidates and remediation (qualify or define alias).
|
||||
- Modes:
|
||||
- Relaxed (default): short names allowed when unique.
|
||||
- Strict: require plugin prefix (env `NYASH_PLUGIN_REQUIRE_PREFIX=1` or nyash.toml `[plugins] require_prefix=true`).
|
||||
- Relaxed (default): short names allowed when unique。
|
||||
- Strict: plugin短名にprefix必須（env `NYASH_PLUGIN_REQUIRE_PREFIX=1` または nyash.toml `[plugins] require_prefix=true`）。
|
||||
- Aliases:
|
||||
- nyash.toml `[imports] HttpClient = "network.HttpClient"`
|
||||
- needs sugar: `needs plugin.network.HttpClient as HttpClient` (file‑scoped alias)
|
||||
@ -27,6 +27,7 @@ Policy
|
||||
- Unified namespace with Boxes. Prefer short names when unique.
|
||||
- Qualified form: `network.HttpClient`
|
||||
- Per‑plugin control (nyash.toml): `prefix`, `require_prefix`, `expose_short_names`
|
||||
- 現状は設定の読み取りのみ（導線）。挙動への反映は段階的に実施予定。
|
||||
|
||||
## `needs` sugar (optional)
|
||||
- Treated as a synonym to `using` on the Runner side; registers aliases only.
|
||||
@ -37,21 +38,11 @@ Policy
|
||||
- `[plugins.<name>]`: `path`, `prefix`, `require_prefix`, `expose_short_names`
|
||||
|
||||
## Index and Cache (Runner)
|
||||
- Build a Box index once per run to make resolution fast and predictable:
|
||||
```
|
||||
struct BoxIndex {
|
||||
local_boxes: HashMap<String, PathBuf>,
|
||||
plugin_boxes: HashMap<String, Vec<PluginBox>>,
|
||||
aliases: HashMap<String, String>,
|
||||
}
|
||||
```
|
||||
- Maintain a small resolve cache per thread:
|
||||
```
|
||||
thread_local! {
|
||||
static RESOLVE_CACHE: RefCell<HashMap<String, ResolvedBox>> = /* ... */;
|
||||
}
|
||||
```
|
||||
- Trace: `NYASH_RESOLVE_TRACE=1` prints resolution steps (for debugging/CI logs).
|
||||
- BoxIndex（グローバル）：プラグインBox一覧とaliasesを集約し、Runner起動時（plugins init後）に構築・更新。
|
||||
- `aliases: HashMap<String,String>`（nyash.toml `[aliases]` と env `NYASH_ALIASES`）
|
||||
- `plugin_boxes: HashSet<String>`（読み取り専用）
|
||||
- 解決キャッシュ：グローバルの小さなキャッシュで同一キーの再解決を回避（キー: `tgt|base|strict|paths`）。
|
||||
- トレース：`NYASH_RESOLVE_TRACE=1` で解決手順やキャッシュヒット、未解決候補を出力。
|
||||
|
||||
Syntax
|
||||
- Namespace: `using core.std` or `using core.std as Std`
|
||||
@ -102,9 +93,14 @@ static box Main {
|
||||
|
||||
Runner Configuration
|
||||
- Enable using pre‑processing: `NYASH_ENABLE_USING=1`
|
||||
- CLI from-the-top registration: `--using "ns as Alias"` or `--using '"apps/foo.nyash" as Foo'` (repeatable)
|
||||
- Strict mode (plugin prefix required): `NYASH_PLUGIN_REQUIRE_PREFIX=1` または `nyash.toml` の `[plugins] require_prefix=true`
|
||||
- Aliases from env: `NYASH_ALIASES="Foo=apps/foo/main.nyash,Bar=lib/bar.nyash"`
|
||||
- Additional search paths: `NYASH_USING_PATH="apps:lib:."`
|
||||
- Selfhost pipeline keeps child stdout quiet and extracts JSON only: `NYASH_JSON_ONLY=1` (set by Runner automatically for child)
|
||||
- Selfhost emits `meta.usings` automatically when present; no additional flags required.
|
||||
|
||||
Notes
|
||||
- Phase 15 keeps resolution in the Runner to minimize parser complexity. Future phases may leverage `meta.usings` for compiler decisions.
|
||||
- Unknown fields in the top‑level JSON (like `meta`) are ignored by the current bridge.
|
||||
- 未解決時（非strict）は実行を継続し、`NYASH_RESOLVE_TRACE=1` で候補を提示。strict時はエラーで候補を表示。
|
||||
|
||||
Reference in New Issue
Block a user